Common Weakness Enumeration
CWE-703
DiscouragedImproper Check or Handling of Exceptional Conditions
Abstraction: Pillar · Status: Incomplete
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
212 vulnerabilities reference this CWE, most recent first.
GHSA-53RV-HCVM-RPP9
Vulnerability from github – Published: 2025-01-14 22:03 – Updated: 2025-01-14 22:03
VLAI
Summary
Lodestar snappy decompression issue
Details
Impact
Unintended permanent chain split affecting greater than or equal to 25% of the network, requiring hard fork (network partition requiring hard fork)
Description
Lodestar client may fail to decode snappy framing compressed messages.
Vulnerability Details
In Req/Resp protocol the message are encoded by using ssz_snappy encoding, which is basically snappy framing compression over ssz encoded message.
It's mentioned here - https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md
The token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction. Only one value is possible at this time:
ssz_snappy: The contents are first SSZ-encoded and then compressed with Snappy frames compression. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the BeaconBlocksByRoot request is an SSZ-encoded list of Root's. This encoding type MUST be supported by all clients.
In snappy framing format there a few types of chunks. We are interested in so called reserved skippable chunks. These are chunks with chunk type in range [0x80, 0xfd] Let's see how rust snappy handles them https://github.com/BurntSushi/rust-snappy/blob/master/src/read.rs#L137
impl<R: io::Read> io::Read for FrameDecoder<R> {
fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> {
...
...
let len = len64 as usize;
match ty {
Err(b) if 0x02 <= b && b <= 0x7F => {
// Spec says that chunk types 0x02-0x7F are reserved and
// conformant decoders must return an error.
fail!(Error::UnsupportedChunkType { byte: b });
}
Err(b) if 0x80 <= b && b <= 0xFD => {
// Spec says that chunk types 0x80-0xFD are reserved but
// skippable.
self.r.read_exact(&mut self.src[0..len])?;
}
Similar code can be found in golang implementation - https://github.com/golang/snappy/blob/master/decode.go#L221
func (r *Reader) fill() error {
...
if chunkType <= 0x7f {
// Section 4.5. Reserved unskippable chunks (chunk types 0x02-0x7f).
r.err = ErrUnsupported
return r.err
}
// Section 4.4 Padding (chunk type 0xfe).
// Section 4.6. Reserved skippable chunks (chunk types 0x80-0xfd).
if !r.readFull(r.buf[:chunkLen], false) {
return r.err
}
Now let's see how lodestar handles such chunks https://github.com/ChainSafe/lodestar/blob/unstable/packages/reqresp/src/encodingStrategies/sszSnappy/snappyFrames/uncompress.ts#L17
uncompress(chunk: Uint8ArrayList): Uint8ArrayList | null {
this.buffer.append(chunk);
const result = new Uint8ArrayList();
while (this.buffer.length > 0) {
if (this.buffer.length < 4) break;
const type = getChunkType(this.buffer.get(0));
const frameSize = getFrameSize(this.buffer, 1);
if (this.buffer.length - 4 < frameSize) {
break;
}
const data = this.buffer.subarray(4, 4 + frameSize);
this.buffer.consume(4 + frameSize);
if (!this.state.foundIdentifier && type !== ChunkType.IDENTIFIER) {
throw "malformed input: must begin with an identifier";
}
if (type === ChunkType.IDENTIFIER) {
if (!Buffer.prototype.equals.call(data, IDENTIFIER)) {
throw "malformed input: bad identifier";
}
this.state.foundIdentifier = true;
continue;
}
if (type === ChunkType.COMPRESSED) {
result.append(uncompress(data.subarray(4)));
}
if (type === ChunkType.UNCOMPRESSED) {
result.append(data.subarray(4));
}
}
if (result.length === 0) {
return null;
}
return result;
}
function getChunkType(value: number): ChunkType {
switch (value) {
case ChunkType.IDENTIFIER:
return ChunkType.IDENTIFIER;
case ChunkType.COMPRESSED:
return ChunkType.COMPRESSED;
case ChunkType.UNCOMPRESSED:
return ChunkType.UNCOMPRESSED;
case ChunkType.PADDING:
return ChunkType.PADDING;
default:
throw new Error("Unsupported snappy chunk type");
}
As you can see, lodestar does not recognize such chunks.
If it sees such chunk, function getChunkType() throws an exception and decoding fails.
Impact Details
Faulty nodes may trigger chain stall by sending messages which lodestar fails to parse, while other clients will be able to handle.
Proof of Concept
How to reproduce:
- get archive (via provided gist link), decode and unpack it:
$ base64 -d poc.txt > poc.tgz
$ tar zxf poc.tgz
- run dec1.go to verify that our snappy file decompressed successfully
$ go run dec1.go
reading 1.snappy...
read 124 bytes, err <nil>
- run dec1.mjs to verify that lodestar fails to decode such file
checking chunk type=255
checking chunk type=1
got uncompressed chunk..
checking chunk type=129
file:///../poc/dec1.mjs:74
throw new Error("Unsupported snappy chunk type");
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@lodestar/reqresp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-14T22:03:59Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nUnintended permanent chain split affecting greater than or equal to 25% of the network, requiring hard fork (network partition requiring hard fork)\n\n### Description\nLodestar client may fail to decode snappy framing compressed messages.\n\n### Vulnerability Details\nIn Req/Resp protocol the message are encoded by using ssz_snappy encoding, which is basically snappy framing compression over ssz encoded message.\n\nIt\u0027s mentioned here - https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md\n\n```\nThe token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction. Only one value is possible at this time:\n\nssz_snappy: The contents are first SSZ-encoded and then compressed with Snappy frames compression. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the BeaconBlocksByRoot request is an SSZ-encoded list of Root\u0027s. This encoding type MUST be supported by all clients.\n```\n\nIn snappy framing format there a few types of chunks.\nWe are interested in so called reserved skippable chunks. These are chunks with chunk type in range [0x80, 0xfd]\nLet\u0027s see how rust snappy handles them https://github.com/BurntSushi/rust-snappy/blob/master/src/read.rs#L137\n\n```\nimpl\u003cR: io::Read\u003e io::Read for FrameDecoder\u003cR\u003e {\n fn read(\u0026mut self, buf: \u0026mut [u8]) -\u003e io::Result\u003cusize\u003e {\n \t\t ... \n ...\n \t\t let len = len64 as usize;\n match ty {\n Err(b) if 0x02 \u003c= b \u0026\u0026 b \u003c= 0x7F =\u003e {\n // Spec says that chunk types 0x02-0x7F are reserved and\n // conformant decoders must return an error.\n fail!(Error::UnsupportedChunkType { byte: b });\n }\n Err(b) if 0x80 \u003c= b \u0026\u0026 b \u003c= 0xFD =\u003e {\n // Spec says that chunk types 0x80-0xFD are reserved but\n // skippable.\n self.r.read_exact(\u0026mut self.src[0..len])?;\n }\n```\n\nSimilar code can be found in golang implementation - https://github.com/golang/snappy/blob/master/decode.go#L221\n\n```\nfunc (r *Reader) fill() error {\n\t...\n\tif chunkType \u003c= 0x7f {\n\t\t\t// Section 4.5. Reserved unskippable chunks (chunk types 0x02-0x7f).\n\t\t\tr.err = ErrUnsupported\n\t\t\treturn r.err\n\t\t}\n\t\t// Section 4.4 Padding (chunk type 0xfe).\n\t\t// Section 4.6. Reserved skippable chunks (chunk types 0x80-0xfd).\n\t\tif !r.readFull(r.buf[:chunkLen], false) {\n\t\t\treturn r.err\n\t\t}\n```\n\nNow let\u0027s see how lodestar handles such chunks https://github.com/ChainSafe/lodestar/blob/unstable/packages/reqresp/src/encodingStrategies/sszSnappy/snappyFrames/uncompress.ts#L17\n\n```\nuncompress(chunk: Uint8ArrayList): Uint8ArrayList | null {\n this.buffer.append(chunk);\n const result = new Uint8ArrayList();\n while (this.buffer.length \u003e 0) {\n if (this.buffer.length \u003c 4) break;\n\n const type = getChunkType(this.buffer.get(0));\n const frameSize = getFrameSize(this.buffer, 1);\n\n if (this.buffer.length - 4 \u003c frameSize) {\n break;\n }\n\n const data = this.buffer.subarray(4, 4 + frameSize);\n this.buffer.consume(4 + frameSize);\n\n if (!this.state.foundIdentifier \u0026\u0026 type !== ChunkType.IDENTIFIER) {\n throw \"malformed input: must begin with an identifier\";\n }\n\n if (type === ChunkType.IDENTIFIER) {\n if (!Buffer.prototype.equals.call(data, IDENTIFIER)) {\n throw \"malformed input: bad identifier\";\n }\n this.state.foundIdentifier = true;\n continue;\n }\n\n if (type === ChunkType.COMPRESSED) {\n result.append(uncompress(data.subarray(4)));\n }\n if (type === ChunkType.UNCOMPRESSED) {\n result.append(data.subarray(4));\n }\n }\n if (result.length === 0) {\n return null;\n }\n return result;\n }\n\n function getChunkType(value: number): ChunkType {\n switch (value) {\n case ChunkType.IDENTIFIER:\n return ChunkType.IDENTIFIER;\n case ChunkType.COMPRESSED:\n return ChunkType.COMPRESSED;\n case ChunkType.UNCOMPRESSED:\n return ChunkType.UNCOMPRESSED;\n case ChunkType.PADDING:\n return ChunkType.PADDING;\n default:\n throw new Error(\"Unsupported snappy chunk type\");\n }\n```\n\nAs you can see, lodestar does not recognize such chunks.\n\nIf it sees such chunk, function getChunkType() throws an exception and decoding fails.\n\n### Impact Details\n\nFaulty nodes may trigger chain stall by sending messages which lodestar fails to parse, while other clients will be able to handle.\n\n### Proof of Concept\n\nHow to reproduce:\n\n1. get archive (via provided [gist link](https://gist.github.com/gln7/bdde7f4e0bdf9d47bf810a015796867a)), decode and unpack it:\n```\n$ base64 -d poc.txt \u003e poc.tgz\n$ tar zxf poc.tgz\n```\n\n2. run dec1.go to verify that our snappy file decompressed successfully\n```\n$ go run dec1.go\n\nreading 1.snappy...\nread 124 bytes, err \u003cnil\u003e\n```\n\n3. run dec1.mjs to verify that lodestar fails to decode such file\n```\nchecking chunk type=255\nchecking chunk type=1\ngot uncompressed chunk..\nchecking chunk type=129\nfile:///../poc/dec1.mjs:74\n throw new Error(\"Unsupported snappy chunk type\");\n```\n",
"id": "GHSA-53rv-hcvm-rpp9",
"modified": "2025-01-14T22:03:59Z",
"published": "2025-01-14T22:03:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ChainSafe/lodestar/security/advisories/GHSA-53rv-hcvm-rpp9"
},
{
"type": "WEB",
"url": "https://github.com/ChainSafe/lodestar/commit/18a0d681dbcc51fb2ac9456f31e91f4e31a18300"
},
{
"type": "PACKAGE",
"url": "https://github.com/ChainSafe/lodestar"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Lodestar snappy decompression issue"
}
GHSA-54Q9-GW6J-4H5C
Vulnerability from github – Published: 2024-05-14 18:31 – Updated: 2024-05-14 18:31
VLAI
Details
An improper check or handling of exceptional conditions vulnerability [CWE-703] in Fortinet FortiOS version 7.4.1 allows an unauthenticated attacker to provoke a denial of service on the administrative interface via crafted HTTP requests.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-26007"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T17:15:40Z",
"severity": "MODERATE"
},
"details": "An improper check or handling of exceptional conditions vulnerability [CWE-703] in Fortinet FortiOS version 7.4.1 allows an unauthenticated attacker to provoke a denial of service on the administrative interface via crafted HTTP requests.",
"id": "GHSA-54q9-gw6j-4h5c",
"modified": "2024-05-14T18:31:03Z",
"published": "2024-05-14T18:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26007"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-24-017"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-5RW8-2RRX-MF5M
Vulnerability from github – Published: 2024-04-04 21:30 – Updated: 2024-04-04 21:30
VLAI
Details
A null pointer dereference vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2024-22052"
],
"database_specific": {
"cwe_ids": [
"CWE-476",
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T20:15:08Z",
"severity": "HIGH"
},
"details": "A null pointer dereference vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack ",
"id": "GHSA-5rw8-2rrx-mf5m",
"modified": "2024-04-04T21:30:30Z",
"published": "2024-04-04T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22052"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/New-CVE-2024-21894-Heap-Overflow-CVE-2024-22052-Null-Pointer-Dereference-CVE-2024-22053-Heap-Overflow-and-CVE-2024-22023-XML-entity-expansion-or-XXE-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-63QQ-765J-587X
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-19 21:31
VLAI
Details
Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2025-13026"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T16:15:39Z",
"severity": "CRITICAL"
},
"details": "Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox \u003c 145.",
"id": "GHSA-63qq-765j-587x",
"modified": "2025-11-19T21:31:18Z",
"published": "2025-11-11T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13026"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1994441"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-87"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-90"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6PG9-3WF4-7W8V
Vulnerability from github – Published: 2026-04-21 00:32 – Updated: 2026-04-21 21:31
VLAI
Details
XiangShan (Open-source high-performance RISC-V processor) commit edb1dfaf7d290ae99724594507dc46c2c2125384 (2024-11-28) contains an improper exceptional-condition handling flaw in its CSR subsystem (NewCSR). On affected versions, certain sequences of CSR operations targeting non-existent/custom CSR addresses may trigger an illegal-instruction exception but fail to reliably transfer control to the configured trap handler (mtvec), causing control-flow disruption and potentially leaving the core in a hung or unrecoverable state. This can be exploited by a local attacker able to execute code on the processor to cause a denial of service and potentially inconsistent architectural state.
Severity
7.1 (High)
{
"affected": [],
"aliases": [
"CVE-2026-29643"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-20T22:16:23Z",
"severity": "HIGH"
},
"details": "XiangShan (Open-source high-performance RISC-V processor) commit edb1dfaf7d290ae99724594507dc46c2c2125384 (2024-11-28) contains an improper exceptional-condition handling flaw in its CSR subsystem (NewCSR). On affected versions, certain sequences of CSR operations targeting non-existent/custom CSR addresses may trigger an illegal-instruction exception but fail to reliably transfer control to the configured trap handler (mtvec), causing control-flow disruption and potentially leaving the core in a hung or unrecoverable state. This can be exploited by a local attacker able to execute code on the processor to cause a denial of service and potentially inconsistent architectural state.",
"id": "GHSA-6pg9-3wf4-7w8v",
"modified": "2026-04-21T21:31:22Z",
"published": "2026-04-21T00:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29643"
},
{
"type": "WEB",
"url": "https://github.com/OpenXiangShan/XiangShan/issues/3959"
},
{
"type": "WEB",
"url": "https://github.com/OpenXiangShan/XiangShan/pull/3966"
},
{
"type": "WEB",
"url": "https://docs.riscv.org/reference/isa/priv/machine.html"
},
{
"type": "WEB",
"url": "https://docs.riscv.org/reference/isa/priv/priv-csrs.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-735R-HV67-G38F
Vulnerability from github – Published: 2023-04-11 21:12 – Updated: 2024-05-20 21:51
VLAI
Summary
vitess allows users to create keyspaces that can deny access to already existing keyspaces
Details
Impact
Users can either intentionally or inadvertently create a keyspace containing / characters such that from that point on, anyone who tries to view keyspaces from VTAdmin will receive an error. Trying to list all the keyspaces using vtctldclient GetKeyspaces will also return an error.
Note that all other keyspaces can still be administered using the CLI (vtctldclient).
Patches
v16.0.1 (corresponding to 0.16.1 on pkg.go.dev)
Workarounds
Delete the offending keyspace using a CLI client (vtctldclient)
vtctldclient --server ... DeleteKeyspace a/b
Found during a security audit sponsored by the CNCF and facilitated by OSTIF.
Severity
4.1 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "vitess.io/vitess"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29194"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-11T21:12:42Z",
"nvd_published_at": "2023-04-14T19:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nUsers can either intentionally or inadvertently create a keyspace containing `/` characters such that from that point on, anyone who tries to view keyspaces from VTAdmin will receive an error. Trying to list all the keyspaces using `vtctldclient GetKeyspaces` will also return an error.\nNote that all other keyspaces can still be administered using the CLI (vtctldclient).\n\n### Patches\nv16.0.1 (corresponding to 0.16.1 on pkg.go.dev)\n\n### Workarounds\nDelete the offending keyspace using a CLI client (vtctldclient) \n```\nvtctldclient --server ... DeleteKeyspace a/b\n```\n\nFound during a security audit sponsored by the [CNCF](https://cncf.io) and facilitated by [OSTIF](https://ostif.org).",
"id": "GHSA-735r-hv67-g38f",
"modified": "2024-05-20T21:51:28Z",
"published": "2023-04-11T21:12:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vitessio/vitess/security/advisories/GHSA-735r-hv67-g38f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29194"
},
{
"type": "WEB",
"url": "https://github.com/vitessio/vitess/commit/adf10196760ad0b3991a7aa7a8580a544e6ddf88"
},
{
"type": "PACKAGE",
"url": "https://github.com/vitessio/vitess"
},
{
"type": "WEB",
"url": "https://github.com/vitessio/vitess/commits/v0.16.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "vitess allows users to create keyspaces that can deny access to already existing keyspaces"
}
GHSA-7587-4WV6-M68M
Vulnerability from github – Published: 2026-02-13 20:54 – Updated: 2026-02-13 20:54
VLAI
Summary
rPGP vulnerable to parser crash on crafted RSA secret key packets through CVE-2026-21895
Details
Summary
It was possible to trigger an unhandled edge case in the Rust Crypto rsa crate through rPGP packet parsing functionality, and crash the process that runs rPGP. This problem has been patched in a new rsa version. The new release of rPGP ensures a patched version of the rsa crate is in use, which prevents this issue.
Details
While parsing a special RSA secret key packet, rPGP calls the rsa crate with the provided key. On vulnerable versions, this results in a Rust "panic" during key construction. Note that an attacker can trigger this situation even in places where applications don't expect to handle foreign key material, for example while attempting to receive a message.
For more information on the rsa crate vulnerability, see https://github.com/RustCrypto/RSA/security/advisories/GHSA-9c48-w39g-hm26 and https://github.com/RustCrypto/RSA/pull/624. In rPGP, this has been fixed via https://github.com/rpgp/rpgp/pull/698.
Impact
This issue impacts availability (i.e. applications can crash).
Affected rPGP versions: rPGP 0.16.0-alpha.0 to 0.18.0 Vulnerable rsa versions: all before version 0.9.10
Workaround
The issue depends on the combination of affected rPGP and rsa versions. Users of affected rPGP versions can pin the patched rsa 0.9.10 via a cargo lockfile to mitigate the issue.
Attribution
Discovered by Christian Reitter from Radically Open Security during a security review for Proton AG.
Severity
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "pgp"
},
"ranges": [
{
"events": [
{
"introduced": "0.16.0-alpha.0"
},
{
"fixed": "0.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-13T20:54:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nIt was possible to trigger an unhandled edge case in the Rust Crypto rsa crate through rPGP packet parsing functionality, and crash the process that runs rPGP. This problem has been patched in a new rsa version. The new release of rPGP ensures a patched version of the rsa crate is in use, which prevents this issue.\n\n### Details\nWhile parsing a special RSA secret key packet, rPGP calls the rsa crate with the provided key. On vulnerable versions, this results in a Rust \"panic\" during key construction. Note that an attacker can trigger this situation even in places where applications don\u0027t expect to handle foreign key material, for example while attempting to receive a message.\n\nFor more information on the rsa crate vulnerability, see https://github.com/RustCrypto/RSA/security/advisories/GHSA-9c48-w39g-hm26 and https://github.com/RustCrypto/RSA/pull/624.\nIn rPGP, this has been fixed via https://github.com/rpgp/rpgp/pull/698.\n\n### Impact\nThis issue impacts availability (i.e. applications can crash).\n\nAffected rPGP versions: rPGP 0.16.0-alpha.0 to 0.18.0\nVulnerable rsa versions: all before version 0.9.10\n\n### Workaround\nThe issue depends on the combination of affected rPGP and rsa versions. Users of affected rPGP versions can pin the patched rsa 0.9.10 via a cargo lockfile to mitigate the issue.\n\n### Attribution\nDiscovered by Christian Reitter from Radically Open Security during a security review for Proton AG.",
"id": "GHSA-7587-4wv6-m68m",
"modified": "2026-02-13T20:54:19Z",
"published": "2026-02-13T20:54:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rpgp/rpgp/security/advisories/GHSA-7587-4wv6-m68m"
},
{
"type": "WEB",
"url": "https://github.com/rpgp/rpgp/pull/698"
},
{
"type": "WEB",
"url": "https://github.com/rpgp/rpgp/commit/38efa49ce18b3821649de9cd8dea88a959b833a5"
},
{
"type": "PACKAGE",
"url": "https://github.com/rpgp/rpgp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "rPGP vulnerable to parser crash on crafted RSA secret key packets through CVE-2026-21895"
}
GHSA-75J9-XW79-QXQV
Vulnerability from github – Published: 2025-04-01 12:30 – Updated: 2025-04-01 12:30
VLAI
Details
When run on commands with certain arguments set, explain may fail to validate these arguments before using them. This can lead to crashes in router servers. This affects MongoDB Server v5.0 prior to 5.0.31, MongoDB Server v6.0 prior to 6.0.20, MongoDB Server v7.0 prior to 7.0.16 and MongoDB Server v8.0 prior to 8.0.4
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-3084"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T12:15:16Z",
"severity": "MODERATE"
},
"details": "When run on commands with certain arguments set, explain may fail to validate these arguments before using them. This can lead to crashes in router servers. This affects MongoDB Server v5.0 prior to 5.0.31, MongoDB Server v6.0 prior to 6.0.20, MongoDB Server v7.0 prior to 7.0.16 and MongoDB Server v8.0 prior to 8.0.4",
"id": "GHSA-75j9-xw79-qxqv",
"modified": "2025-04-01T12:30:35Z",
"published": "2025-04-01T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3084"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-103153"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-75P5-W5J4-V8QJ
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-19 21:31
VLAI
Details
Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2025-13021"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T16:15:39Z",
"severity": "CRITICAL"
},
"details": "Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox \u003c 145.",
"id": "GHSA-75p5-w5j4-v8qj",
"modified": "2025-11-19T21:31:17Z",
"published": "2025-11-11T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13021"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1986431"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-87"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-90"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7J85-MWFJ-2GR8
Vulnerability from github – Published: 2023-07-28 03:30 – Updated: 2023-07-28 03:30
VLAI
Details
An unhandled error in Vault Enterprise's namespace creation may cause the Vault process to crash, potentially resulting in denial of service. Fixed in 1.14.1, 1.13.5, and 1.12.9.
Severity
4.9 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-3774"
],
"database_specific": {
"cwe_ids": [
"CWE-703",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-28T01:15:09Z",
"severity": null
},
"details": "An unhandled error in Vault Enterprise\u0027s namespace creation may cause the Vault process to crash, potentially resulting in denial of service. Fixed in 1.14.1, 1.13.5, and 1.12.9.",
"id": "GHSA-7j85-mwfj-2gr8",
"modified": "2023-07-28T03:30:12Z",
"published": "2023-07-28T03:30:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3774"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2023-23-vault-enterprise-namespace-creation-may-lead-to-denial-of-service/56617"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.