CVE-2026-69185

Socket.IO: Zero-attachment Memory Exhaustion

Published Aug 3, 2026 CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Description
Socket.IO enables bidirectional and low-latency communication for every platform. Prior to 4.2.7, 3.4.5, and 3.3.6, 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. This vulnerability is fixed in 4.2.7, 3.4.5, and 3.3.6.

Analysis

AI-generated

Technical impact

Socket.IO, a library used for real‑time bidirectional communication, contains a flaw that allows an attacker to send an exploit packet with an unusually large number of binary attachments. The server will allocate memory to buffer each attachment, causing it to exhaust system memory and potentially crash or become unresponsive. The weakness stems from insufficient input validation (CWE‑20), improper handling of large data sets (CWE‑754), and memory management errors (CWE‑770).

Affected Systems

This flaw affects Socket.IO versions older than 4.2.7, 3.4.5, and 3.3.6. Any deployment that continues to use one of those legacy releases is vulnerable. The vulnerability is present in the main Socket.IO library and does not require additional plugins.

Risk and Exploitability

The CVSS base score of 7.5 indicates a high impact level, while the EPSS score of less than 1% suggests that the likelihood of exploitation is low. It is also not listed in the CISA KEV catalog, indicating no known widespread active exploitation. The attack vector would be a network‑based, unauthenticated client that initiates a Socket.IO connection and sends a malicious packet with many binary attachments, causing the server to run out of memory and become unresponsive, which affects the availability of the affected service.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Socket.IO package to at least version 4.2.7, 3.4.5, or 3.3.6 depending on your current major release, and redeploy the application.
  • If an immediate upgrade is not feasible, configure the Socket.IO server to enforce stricter limits on the number and size of binary attachments (for example, set the `maxHttpBufferSize` option or implement custom request throttling).
  • Use proper memory management practices to guard against CWE‑770: ensure that attachment buffering is bounded, checked, and cleansed to prevent unchecked allocation. If the server language allows, enable guardrails such as runtime limits or OOM protection for large payloads. Implement memory‑usage monitoring and alerts for the Socket.IO process so that any unexpected spikes due to abuse can be quickly detected and remedied.

Generated by OpenCVE AI on August 7, 2026 at 02:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Github GHSA Github GHSA GHSA-2m8v-j782-fhvr Socket.IO: Zero-attachment Memory Exhaustion
History
Type Values Removed Values Added
First Time appeared Socket
Socket socket.io
Vendors & Products Socket
Socket socket.io
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Description Socket.IO enables bidirectional and low-latency communication for every platform. Prior to 4.2.7, 3.4.5, and 3.3.6, 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. This vulnerability is fixed in 4.2.7, 3.4.5, and 3.3.6.
Title Socket.IO: Zero-attachment Memory Exhaustion
Weaknesses CWE-20
CWE-754
References
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

Weaknesses
  • CWE-20

    Improper Input Validation

  • CWE-754

    Improper Check for Unusual or Exceptional Conditions

  • CWE-770

    Allocation of Resources Without Limits or Throttling

Sources

Status
PUBLISHED
Assigner
GitHub_M
Published
Updated
Aug 3, 2026, 8:31 PM
Reserved
Aug 3, 2026, 4:00 PM
Status
Awaiting Analysis
Published
Aug 3, 2026, 8:17 PM
Modified
Oct 23, 2026, 9:10 PM
Severity
Important
Public date
Aug 3, 2026, 7:09 PM