CWE-754
Allowed-with-ReviewImproper Check for Unusual or Exceptional Conditions
Abstraction: Class · Status: Incomplete
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
993 vulnerabilities reference this CWE, most recent first.
GHSA-63MC-HW7G-86RR
Vulnerability from github – Published: 2026-09-03 20:30 – Updated: 2026-09-03 20:30Summary
The Phoenix JavaScript presence client (assets/js/phoenix/presence.js) tests whether a presence already exists using a bare truthiness check (state[key]) rather than an own-property check. Because applications commonly track presences under a client-supplied username or id, the presence key can be attacker-controlled. A user who joins a channel and picks a key that names an Object.prototype member (__proto__, constructor, toString, hasOwnProperty, and similar) makes the lookup return the inherited Object.prototype object instead of undefined, which is truthy. The code then reads .metas.map(...) off it and throws an uncaught TypeError, breaking presence sync for every viewer of that channel topic. Any authenticated channel participant can trigger it.
Details
The victim is any browser subscribed to a presence channel. When it receives the server's presence_state message, it invokes Presence.syncState, which iterates the incoming presences and checks whether each one already exists locally via let currentPresence = state[key]. state is a plain object inheriting from Object.prototype. For an ordinary key like alice, state["alice"] is undefined (falsy) and the safe path runs. For the key __proto__ (or constructor, toString, etc.), state["__proto__"] does not resolve to a tracked presence but to JavaScript's built-in Object.prototype, which is truthy. The if(currentPresence) guard passes, and the code evaluates currentPresence.metas.map(m => m.phx_ref). Since Object.prototype.metas is undefined, calling .map on it throws a TypeError.
Phoenix wraps no try/catch around channel binding callbacks, so the TypeError propagates out of the message handler: this.state is never updated and onSync() never fires. The malicious key is tracked server-side, so it is re-pushed on every presence update and keeps re-throwing, leaving presence permanently broken until the attacker leaves. Presence.syncDiff uses the same unsafe state[key] existence-check pattern, so presence diffs fail identically.
Two scoping points matter. The impact is per channel topic, not global: presence state is per-topic on the server and per-Presence-instance in the browser, so only viewers of the topic carrying the malicious key are affected. The bug is a read-time confusion of the prototype object, not prototype pollution: the crash occurs on the state["__proto__"] read in syncState, before any state[key] = ... write is reached, so Object.prototype is never mutated and nothing leaks across channels. The fix builds the state and accumulator objects with Object.create(null) (or a Map) and gates existence checks with Object.prototype.hasOwnProperty.call(obj, key).
If an application does not pass a client-controlled key to Presence.track, it is not affected.
PoC
- Connect to an application that uses
Phoenix.Presenceand tracks presences under a client-chosen key (e.g. a username). - Join a presence channel choosing the key
__proto__(orconstructor,toString,hasOwnProperty). - The server tracks the presence and pushes
presence_state/presence_diffto every subscriber of that topic. - Each viewer's
Presence.syncState(orsyncDiff) readsstate["__proto__"], gets the truthyObject.prototype, and throws an uncaughtTypeError. - Presence sync stays broken for all viewers of the topic until the attacker leaves the channel.
Impact
An attacker with ordinary channel access can cause a persistent, stored client-side denial of service against every browser viewing a presence channel topic, freezing presence updates for all of them until the attacker disconnects. Any application driving the Phoenix JavaScript presence client with user-influenced presence keys is affected.
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-rc.0"
},
{
"fixed": "1.5.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-rc.0"
},
{
"fixed": "1.6.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-rc.0"
},
{
"fixed": "1.7.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.0"
},
{
"fixed": "1.8.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-rc.0"
},
{
"fixed": "1.5.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-rc.0"
},
{
"fixed": "1.6.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-rc.0"
},
{
"fixed": "1.7.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.0"
},
{
"fixed": "1.8.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56812"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T20:30:33Z",
"nvd_published_at": "2026-07-07T16:16:40Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Phoenix JavaScript presence client (`assets/js/phoenix/presence.js`) tests whether a presence already exists using a bare truthiness check (`state[key]`) rather than an own-property check. Because applications commonly track presences under a client-supplied username or id, the presence key can be attacker-controlled. A user who joins a channel and picks a key that names an `Object.prototype` member (`__proto__`, `constructor`, `toString`, `hasOwnProperty`, and similar) makes the lookup return the inherited `Object.prototype` object instead of `undefined`, which is truthy. The code then reads `.metas.map(...)` off it and throws an uncaught `TypeError`, breaking presence sync for every viewer of that channel topic. Any authenticated channel participant can trigger it.\n\n### Details\n\nThe victim is any browser subscribed to a presence channel. When it receives the server\u0027s `presence_state` message, it invokes `Presence.syncState`, which iterates the incoming presences and checks whether each one already exists locally via `let currentPresence = state[key]`. `state` is a plain object inheriting from `Object.prototype`. For an ordinary key like `alice`, `state[\"alice\"]` is `undefined` (falsy) and the safe path runs. For the key `__proto__` (or `constructor`, `toString`, etc.), `state[\"__proto__\"]` does not resolve to a tracked presence but to JavaScript\u0027s built-in `Object.prototype`, which is truthy. The `if(currentPresence)` guard passes, and the code evaluates `currentPresence.metas.map(m =\u003e m.phx_ref)`. Since `Object.prototype.metas` is `undefined`, calling `.map` on it throws a `TypeError`.\n\nPhoenix wraps no try/catch around channel binding callbacks, so the `TypeError` propagates out of the message handler: `this.state` is never updated and `onSync()` never fires. The malicious key is tracked server-side, so it is re-pushed on every presence update and keeps re-throwing, leaving presence permanently broken until the attacker leaves. `Presence.syncDiff` uses the same unsafe `state[key]` existence-check pattern, so presence diffs fail identically.\n\nTwo scoping points matter. The impact is per channel topic, not global: presence state is per-topic on the server and per-`Presence`-instance in the browser, so only viewers of the topic carrying the malicious key are affected. The bug is a read-time confusion of the prototype object, not prototype pollution: the crash occurs on the `state[\"__proto__\"]` read in `syncState`, before any `state[key] = ...` write is reached, so `Object.prototype` is never mutated and nothing leaks across channels. The fix builds the state and accumulator objects with `Object.create(null)` (or a `Map`) and gates existence checks with `Object.prototype.hasOwnProperty.call(obj, key)`.\n\nIf an application does not pass a client-controlled key to `Presence.track`, it is **not** affected.\n\n### PoC\n\n1. Connect to an application that uses `Phoenix.Presence` and tracks presences under a client-chosen key (e.g. a username).\n2. Join a presence channel choosing the key `__proto__` (or `constructor`, `toString`, `hasOwnProperty`).\n3. The server tracks the presence and pushes `presence_state` / `presence_diff` to every subscriber of that topic.\n4. Each viewer\u0027s `Presence.syncState` (or `syncDiff`) reads `state[\"__proto__\"]`, gets the truthy `Object.prototype`, and throws an uncaught `TypeError`.\n5. Presence sync stays broken for all viewers of the topic until the attacker leaves the channel.\n\n### Impact\n\nAn attacker with ordinary channel access can cause a persistent, stored client-side denial of service against every browser viewing a presence channel topic, freezing presence updates for all of them until the attacker disconnects. Any application driving the Phoenix JavaScript presence client with user-influenced presence keys is affected.",
"id": "GHSA-63mc-hw7g-86rr",
"modified": "2026-09-03T20:30:33Z",
"published": "2026-09-03T20:30:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/security/advisories/GHSA-63mc-hw7g-86rr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56812"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/7f7b971c1ea0994e3fbd1c11ddb05e780bd38ad8"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/89a1c4be161e436241e12b2378a719904b9bd96f"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/b90b22521465ece00eb5a19d5aa2b9465b209c85"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/beffc4da1e787e572121f68902c63daf4fe7d9c2"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-56812.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/phoenixframework/phoenix"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-56812"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Phoenix: Presence keys colliding with `Object.prototype` members break existence checks"
}
GHSA-63V2-9QJR-CCX3
Vulnerability from github – Published: 2022-04-15 00:00 – Updated: 2022-04-22 00:00A vulnerability in Juniper Networks Junos OS on SRX Series, allows a network-based unauthenticated attacker to cause a Denial of Service (DoS) by sending a specific fragmented packet to the device, resulting in a flowd process crash, which is responsible for packet forwarding. Continued receipt and processing of this specific packet will create a sustained DoS condition. This issue only affects SRX Series when 'preserve-incoming-fragment-size' feature is enabled. This issue affects Juniper Networks Junos OS on SRX Series: 18.3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S7; 19.2 versions prior to 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R2. This issue does not affect Juniper Networks Junos OS prior to 17.3R1.
{
"affected": [],
"aliases": [
"CVE-2022-22185"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-14T16:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in Juniper Networks Junos OS on SRX Series, allows a network-based unauthenticated attacker to cause a Denial of Service (DoS) by sending a specific fragmented packet to the device, resulting in a flowd process crash, which is responsible for packet forwarding. Continued receipt and processing of this specific packet will create a sustained DoS condition. This issue only affects SRX Series when \u0027preserve-incoming-fragment-size\u0027 feature is enabled. This issue affects Juniper Networks Junos OS on SRX Series: 18.3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S7; 19.2 versions prior to 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R2. This issue does not affect Juniper Networks Junos OS prior to 17.3R1.",
"id": "GHSA-63v2-9qjr-ccx3",
"modified": "2022-04-22T00:00:57Z",
"published": "2022-04-15T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22185"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA69493"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-64H2-GCQJ-XWFC
Vulnerability from github – Published: 2024-10-11 18:32 – Updated: 2024-10-11 18:32An Improper Check for Unusual or Exceptional Conditions vulnerability in the routing protocol daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network based attacker to cause a Denial of Service (DoS).
In a scenario where BGP Monitoring Protocol (BMP) is configured with rib-in pre-policy monitoring, receiving a BGP update with a specifically malformed AS PATH attribute over an established BGP session, can cause an RPD crash and restart.
This issue affects:
Junos OS:
- All versions before 21.2R3-S8,
- 21.4 versions before 21.4R3-S8,
- 22.2 versions before 22.2R3-S4,
- 22.3 versions before 22.3R3-S3,
- 22.4 versions before 22.4R3-S2,
- 23.2 versions before 23.2R2-S1,
- 23.4 versions before 23.4R1-S2, 23.4R2;
Junos OS Evolved:
- All versions before 21.2R3-S8-EVO,
- 21.4 versions before 21.4R3-S8-EVO,
- 22.2 versions before 22.2R3-S4-EVO,
- 22.3 versions before 22.3R3-S3-EVO,
- 22.4 versions before 22.4R3-S2-EVO,
- 23.2 versions before 23.2R2-S1-EVO,
- 23.4 versions before 23.4R1-S2-EVO, 23.4R2-EVO.
{
"affected": [],
"aliases": [
"CVE-2024-47499"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T16:15:10Z",
"severity": "HIGH"
},
"details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the routing protocol daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network based attacker to cause a Denial of Service (DoS).\u00a0\n\nIn a scenario where BGP Monitoring Protocol (BMP) is configured with rib-in pre-policy monitoring, receiving a BGP update with a specifically malformed AS PATH attribute over an established BGP session, can cause an RPD crash and restart.\n\nThis issue affects:\n\nJunos OS:\u00a0\n\n\n\n * All versions before 21.2R3-S8,\n * 21.4 versions before 21.4R3-S8,\n * 22.2 versions before 22.2R3-S4,\n * 22.3 versions before 22.3R3-S3,\n * 22.4 versions before 22.4R3-S2,\n * 23.2 versions before 23.2R2-S1,\n * 23.4 versions before 23.4R1-S2, 23.4R2;\n\n\n\n\n\n\n\nJunos OS Evolved:\n\n\n\n\n * All versions before 21.2R3-S8-EVO,\n * 21.4 versions before 21.4R3-S8-EVO,\n * 22.2 versions before 22.2R3-S4-EVO,\n * 22.3 versions before 22.3R3-S3-EVO,\n * 22.4 versions before 22.4R3-S2-EVO,\n * 23.2 versions before 23.2R2-S1-EVO,\n * 23.4 versions before 23.4R1-S2-EVO, 23.4R2-EVO.",
"id": "GHSA-64h2-gcqj-xwfc",
"modified": "2024-10-11T18:32:49Z",
"published": "2024-10-11T18:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47499"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA88129"
}
],
"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:H",
"type": "CVSS_V3"
},
{
"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:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:A/V:X/RE:M/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-64HP-5254-Q6PC
Vulnerability from github – Published: 2025-08-19 18:31 – Updated: 2025-11-26 18:30In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix handling of server side tls alerts
Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec..
kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer.
This patch proposes to rework how control messages are setup and used by sock_recvmsg().
If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.
{
"affected": [],
"aliases": [
"CVE-2025-38566"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T17:15:33Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix handling of server side tls alerts\n\nScott Mayhew discovered a security exploit in NFS over TLS in\ntls_alert_recv() due to its assumption it can read data from\nthe msg iterator\u0027s kvec..\n\nkTLS implementation splits TLS non-data record payload between\nthe control message buffer (which includes the type such as TLS\naler or TLS cipher change) and the rest of the payload (say TLS\nalert\u0027s level/description) which goes into the msg payload buffer.\n\nThis patch proposes to rework how control messages are setup and\nused by sock_recvmsg().\n\nIf no control message structure is setup, kTLS layer will read and\nprocess TLS data record types. As soon as it encounters a TLS control\nmessage, it would return an error. At that point, NFS can setup a\nkvec backed msg buffer and read in the control message such as a\nTLS alert. Msg iterator can advance the kvec pointer as a part of\nthe copy process thus we need to revert the iterator before calling\ninto the tls_alert_recv.",
"id": "GHSA-64hp-5254-q6pc",
"modified": "2025-11-26T18:30:57Z",
"published": "2025-08-19T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38566"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25bb3647d30a20486b5fe7cff2b0e503c16c9692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b549da875414989f480b66835d514be80a0bd9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b33c31cc788073bfbed9297e1f4486ed73d87da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1df394621710b312f0393e3f240fdac0764f968"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bee47cb026e762841f3faece47b51f985e215edb"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-66FW-43H8-F8P3
Vulnerability from github – Published: 2024-07-26 21:14 – Updated: 2025-05-15 21:23Affected versions of the crate failed to catch C++ exceptions raised within the XmpFile::close function. If such an exception occurred, it would trigger undefined behavior, typically a process abort.
This is best demonstrated in issue #230, where a race condition causes the close call to fail due to file I/O errors.
This was fixed in PR #232 (released as crate version 1.9.0), which now safely handles the exception.
For backward compatibility, the existing API ignores the error. A new API XmpFile::try_close was added to allow callers to receive and process the error result.
Users of all prior versions of xmp_toolkit are encouraged to update to version 1.9.0 to avoid undefined behavior.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "xmp_toolkit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-26T21:14:54Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "Affected versions of the crate failed to catch C++ exceptions raised within the `XmpFile::close` function. If such an exception occurred, it would trigger undefined behavior, typically a process abort.\n\nThis is best demonstrated in [issue #230](https://github.com/adobe/xmp-toolkit-rs/issues/230), where a race condition causes the `close` call to fail due to file I/O errors.\n\nThis was fixed in [PR #232](https://github.com/adobe/xmp-toolkit-rs/pull/232) (released as crate version 1.9.0), which now safely handles the exception.\n\nFor backward compatibility, the existing API ignores the error. A new API `XmpFile::try_close` was added to allow callers to receive and process the error result.\n\nUsers of all prior versions of `xmp_toolkit` are encouraged to update to version 1.9.0 to avoid undefined behavior.",
"id": "GHSA-66fw-43h8-f8p3",
"modified": "2025-05-15T21:23:42Z",
"published": "2024-07-26T21:14:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/adobe/xmp-toolkit-rs/issues/230"
},
{
"type": "WEB",
"url": "https://github.com/adobe/xmp-toolkit-rs/issues/233"
},
{
"type": "WEB",
"url": "https://github.com/adobe/xmp-toolkit-rs/pull/232"
},
{
"type": "PACKAGE",
"url": "https://github.com/adobe/xmp-toolkit-rs"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0360.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "XMP Toolkit\u0027s `XmpFile::close` can trigger undefined behavior"
}
GHSA-677M-J7P3-52F9
Vulnerability from github – Published: 2026-03-18 17:26 – Updated: 2026-03-20 21:33Impact
A specially crafted Socket.IO packet can make the server wait for a large number of binary attachments and buffer them, which can be exploited to make the server run out of memory.
Patches
| Version range | Used by | Fixed version |
|---|---|---|
>=4.0.0 <4.2.6 |
socket.io@4.x and socket.io-client@4.x |
4.2.6 |
>=3.4.0 <3.4.4 |
socket.io@2.x |
3.4.4 |
<3.3.5 |
socket.io-client@2.x |
3.3.5 |
Workarounds
There is no known workaround except upgrading to a safe version.
For more information
If you have any questions or comments about this advisory:
- Open a discussion here
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "3.4.0"
},
{
"fixed": "3.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "socket.io-parser"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33151"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T17:26:14Z",
"nvd_published_at": "2026-03-20T21:17:15Z",
"severity": "HIGH"
},
"details": "### Impact\n\nA specially crafted Socket.IO packet can make the server wait for a large number of binary attachments and buffer them, which can be exploited to make the server run out of memory.\n\n### Patches\n\n| Version range | Used by | Fixed version |\n|------------------|--------------------------------------------|---------------|\n| `\u003e=4.0.0 \u003c4.2.6` | `socket.io@4.x` and `socket.io-client@4.x` | `4.2.6` |\n| `\u003e=3.4.0 \u003c3.4.4` | `socket.io@2.x` | `3.4.4` |\n| `\u003c3.3.5` | `socket.io-client@2.x` | `3.3.5` |\n\n### Workarounds\n\nThere is no known workaround except upgrading to a safe version.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Open a discussion [here](https://github.com/socketio/socket.io/discussions)",
"id": "GHSA-677m-j7p3-52f9",
"modified": "2026-03-20T21:33:51Z",
"published": "2026-03-18T17:26:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io/security/advisories/GHSA-677m-j7p3-52f9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33151"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io/commit/719f9ebab0772ffb882bd614b387e585c1aa75d4"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io/commit/9d39f1f080510f036782f2177fac701cc041faaf"
},
{
"type": "WEB",
"url": "https://github.com/socketio/socket.io/commit/b25738c416c4e32fbff62ee182afa8f6d0dacf78"
},
{
"type": "PACKAGE",
"url": "https://github.com/socketio/socket.io"
}
],
"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": "socket.io allows an unbounded number of binary attachments"
}
GHSA-684G-6HHV-XRR6
Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31Dell Device Management Agent (DDMA), versions prior to 26.02, contain an Improper Check for Unusual or Exceptional Conditions vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2026-22760"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T17:16:18Z",
"severity": "LOW"
},
"details": "Dell Device Management Agent (DDMA), versions prior to 26.02, contain an Improper Check for Unusual or Exceptional Conditions vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Denial of Service.",
"id": "GHSA-684g-6hhv-xrr6",
"modified": "2026-03-04T18:31:53Z",
"published": "2026-03-04T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22760"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000429177/dsa-2026-105"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-6876-43RC-GJMQ
Vulnerability from github – Published: 2026-02-02 09:30 – Updated: 2026-02-03 00:30In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01726634; Issue ID: MSV-5728.
{
"affected": [],
"aliases": [
"CVE-2026-20406"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-02T09:15:55Z",
"severity": "HIGH"
},
"details": "In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01726634; Issue ID: MSV-5728.",
"id": "GHSA-6876-43rc-gjmq",
"modified": "2026-02-03T00:30:18Z",
"published": "2026-02-02T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20406"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2026"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-6956-6R33-F8XW
Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-06-30 03:35Incorrect boundary conditions in the Audio/Video: Playback component. This vulnerability affects Firefox < 149, Firefox ESR < 115.34, and Firefox ESR < 140.9.
{
"affected": [],
"aliases": [
"CVE-2026-4693"
],
"database_specific": {
"cwe_ids": [
"CWE-754",
"CWE-823"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T13:16:05Z",
"severity": "HIGH"
},
"details": "Incorrect boundary conditions in the Audio/Video: Playback component. This vulnerability affects Firefox \u003c 149, Firefox ESR \u003c 115.34, and Firefox ESR \u003c 140.9.",
"id": "GHSA-6956-6r33-f8xw",
"modified": "2026-06-30T03:35:58Z",
"published": "2026-03-24T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4693"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5930"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8287"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8288"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8289"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8290"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8315"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8427"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-4693"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2018102"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450741"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4693.json"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-21"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-22"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-23"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-24"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5931"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:5932"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6188"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6342"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:6917"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7837"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7838"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7839"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7840"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7841"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7842"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7843"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7845"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7858"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8284"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8285"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:8286"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-69V8-V8V7-VV42
Vulnerability from github – Published: 2024-02-12 03:30 – Updated: 2026-05-12 12:31create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.
{
"affected": [],
"aliases": [
"CVE-2024-25739"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-12T03:15:32Z",
"severity": "MODERATE"
},
"details": "create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi-\u003eleb_size.",
"id": "GHSA-69v8-v8v7-vv42",
"modified": "2026-05-12T12:31:34Z",
"published": "2024-02-12T03:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25739"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/syzkaller/c/Xl97YcQA4hg"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
},
{
"type": "WEB",
"url": "https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/ubi/vtbl.c?h=v6.6.24\u0026id=d1b505c988b7"
},
{
"type": "WEB",
"url": "https://www.spinics.net/lists/kernel/msg5074816.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Check the results of all functions that return a value and verify that the value is expected.
Mitigation
If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Mitigation
Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
No CAPEC attack patterns related to this CWE.