CVE-2026-33151: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33151 is a Denial of Service vulnerability in the socket.io-parser npm package (used by Socket.IO) that allows unauthenticated remote attackers to exhaust server memory by sending specially crafted packets with an unbounded number of binary attachments. It affects socket.io-parser versions prior to 3.3.5, versions 3.4.0–3.4.3, and versions 4.0.0–4.2.5. The vulnerability was disclosed on March 17, 2026, via a GitHub Security Advisory and published to the NVD on March 20, 2026. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is improper input validation (CWE-20) combined with allocation of resources without limits or throttling (CWE-770) in the Socket.IO binary packet parser. When a binary packet is received, the parser reads the declared number of binary attachments from the packet header and buffers incoming frames until all attachments arrive. Prior to the fix, the parser accepted any arbitrarily large attachment count without validation, allowing an attacker to craft a packet declaring millions of attachments and force the server to allocate and hold memory indefinitely while waiting for frames that never arrive. The fix introduces a default maxAttachments limit of 10 in the Decoder class, rejecting packets that declare more than this threshold (GitHub Advisory, Patch Commit).

Successful exploitation causes the targeted Socket.IO server process to exhaust available memory, resulting in a denial of service — the server becomes unresponsive or crashes. No authentication or user interaction is required, and the attack has low complexity, making it trivially automatable against any internet-exposed Socket.IO endpoint. There is no confidentiality or integrity impact; the vulnerability is purely an availability concern affecting the vulnerable server instance (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation as of the time of reporting (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.085% (16th percentile), indicating a low near-term exploitation probability. The attack requires no privileges or user interaction and is network-accessible with low complexity, meaning exploitation would be straightforward if an attacker chose to target it (GitHub Advisory).

1. Reconnaissance: Identify internet-facing services using Socket.IO (e.g., via Shodan, Censys, or HTTP response fingerprinting for Socket.IO handshake endpoints such as /socket.io/). Confirm the target is running a vulnerable version of socket.io-parser (< 3.3.5, 3.4.0–3.4.3, or 4.0.0–4.2.5).
2. Establish WebSocket connection: Connect to the target Socket.IO server using a standard WebSocket client or the Socket.IO client library to initiate a session.
3. Craft malicious packet: Construct a binary Socket.IO packet with an extremely large attachment count declared in the header. For example, a packet string of the form 5<N>-["event",{"_placeholder":true,"num":0}] where <N> is a very large integer (e.g., 5999999-[...]), declaring millions of expected binary frames.
4. Send the packet: Transmit the crafted packet to the server over the established WebSocket connection. The server's parser reads the declared attachment count and begins buffering, waiting for the promised binary frames.
5. Sustain the attack: Optionally open multiple connections and repeat the process to accelerate memory exhaustion. Since no actual binary frames need to be sent, the server holds the allocated buffer state indefinitely.
6. Achieve DoS: The server process exhausts available memory, causing it to become unresponsive or crash, denying service to legitimate users (GitHub Advisory, Patch Commit).

• Network: High volume of WebSocket connections to the Socket.IO endpoint from a single or small set of source IPs; connections that remain open without completing binary frame delivery.
• Process/Memory: Rapid, sustained growth in Node.js process memory (RSS/heap) on the Socket.IO server without a corresponding increase in legitimate traffic; out-of-memory (OOM) kills of the Node.js process.
• Logs: Server-side logs showing a large number of open socket sessions in a pending/buffering state; application errors such as Error: too many attachments (post-patch) or unexpected process crashes in pre-patch deployments.
• Application Metrics: Spike in active socket connections without corresponding event processing; degraded response times or timeouts on the Socket.IO endpoint.

Upgrade socket.io-parser to one of the patched versions: 3.3.5 (for socket.io-client@2.x), 3.4.4 (for socket.io@2.x), or 4.2.6 (for socket.io@4.x and socket.io-client@4.x). There is no known configuration-based workaround — upgrading to a patched version is the only remediation. As a defense-in-depth measure, implement rate limiting and connection throttling at the network or application layer to limit the number of concurrent WebSocket connections per client, and monitor server memory usage for anomalies. IBM has issued advisories for multiple affected products (Maximo Application Suite, Watsonx BI Assistant, App Connect Enterprise, Transformation Advisor, and others) and should be consulted for product-specific guidance (GitHub Advisory, IBM Maximo Advisory).

The vulnerability was reported by researcher x4cc3 and patched by Socket.IO maintainer darrachequesne (GitHub Advisory). Red Hat tracked the issue via Bugzilla and assessed it as medium severity for their products (Red Hat Bugzilla). IBM issued multiple security bulletins covering a wide range of affected enterprise products including Maximo Application Suite, Watsonx, App Connect Enterprise, and QRadar EDR (IBM Maximo Advisory). Community reaction has been measured, with standard vulnerability tracking activity across CVE databases and scanner plugins (Nessus, Qualys) but no notable public controversy or widespread alarm.