Description

python-engineio is a Python implementation of the Engine.IO realtime client and server. Versions prior to 4.13.2 have two specific configurations of the python-engineio server in which the size of incoming messages is not checked before the messages are loaded into memory. An attacker can take advantage of these to cause unnecessary memory allocations in the python-engineio server. The two cases are POST requests, when using ASGI with the long polling transport and WebSocket messages, when using Aiohttp with the WebSocket transport. Version 4.13.2 addresses this issue. ASGI severs now only load the body of incoming requests into memory after the client is confirmed to be known and authenticated, and the payload size is below the maximum allowed size. Requests that do not comply with these requirements are discarded. Aiohttp servers configure the maximum payload size in the underlying WebSocket layer from Aiohttp, so that large messages are discarded by Aiohttp before they are delivered to python-engineio.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-11T19:17:37.267Z",
  "pubdate": "2026-08-11T19:17:37.267Z",
  "executiveSummary": "A memory exhaustion vulnerability exists in python-engineio prior to version 4.13.2, impacting specific server configurations where incoming message sizes are not validated prior to memory allocation.\nThe vulnerability allows an unauthenticated remote attacker to trigger excessive memory consumption by sending oversized payloads via HTTP POST requests using ASGI with long polling, or via WebSocket messages using Aiohttp.\nSuccessful exploitation leads to resource exhaustion and potential denial of service (DoS) conditions on the affected python-engineio server.\nThe flaw stems from missing payload size validation checks prior to loading request bodies and WebSocket frames into application memory.\nMitigation requires upgrading python-engineio to version 4.13.2 or later, which enforces strict payload size limits and authentication state checks before memory allocation occurs.",
  "technicalDetails": "The vulnerability resides in the python-engineio server implementation for specific transport and asynchronous framework combinations, specifically affecting ASGI with long polling transport and Aiohttp with WebSocket transport in versions prior to 4.13.2.\nThe root cause is the absence of pre-allocation size validation checks for incoming HTTP POST request bodies and WebSocket messages. When clients send data, the server loads the raw message payloads directly into memory before validating whether the data complies with configured size limitations.\nIn the ASGI long polling transport scenario, incoming POST requests containing large bodies are ingested into memory prior to validating client authentication status and payload boundaries. An attacker can transmit excessively large HTTP POST payloads to force the server to allocate significant heap memory.\nIn the Aiohttp WebSocket transport scenario, incoming WebSocket messages are processed without enforcing maximum payload size constraints at the underlying network layer, allowing unvalidated oversized frames to be passed directly into python-engineio for processing and memory buffering.\nAttack flow involves a remote, unauthenticated attacker establishing a connection to the exposed python-engineio server endpoints using either the vulnerable ASGI long polling transport or the Aiohttp WebSocket transport.\nThe attacker crafts and transmits a payload that exceeds standard operational parameters. Because the vulnerable configurations fail to check the Content-Length or the incoming frame size prior to ingestion, the server consumes system memory to buffer the incoming stream.\nRepeated transmission of such payloads rapidly exhausts available memory resources, causing application instability, memory exhaustion crashes, or denial of service for legitimate users.\nNo special privileges or prior authentication are required to initiate the attack vectors, as the memory allocation occurs before authentication and authorization checks are fully enforced in the affected code paths."
}