python-engineio EUVD-2026-56854

Exploitation requires the python-engineio server to be running one of two specific configurations: (1) ASGI deployment using the long-polling transport, exploited via oversized POST requests, or (2) Aiohttp deployment using the WebSocket transport, exploited via oversized WebSocket messages. Deployments using other server backends or transports are not affected, which is the primary limiting factor. The CVSS vector indicates AV:N/AC:L/PR:N/UI:N (network-reachable, low complexity, no privileges, no user interaction); note the ASGI patch description implies pre-auth buffering, supporting unauthenticated triggering for that path, while authentication requirements for the Aiohttp path are not separately confirmed from the available data. Impact is limited to availability (memory exhaustion / denial of service) with no confidentiality or integrity effect.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) reflects a network-reachable, low-complexity, unauthenticated availability-only impact - consistent with a resource-exhaustion DoS rather than data compromise (C:N/I:N). No EPSS score, KEV listing, POC, or SSVC decision data was supplied, so exploitation likelihood cannot be quantified from the inputs; the absence of public exploit code and KEV status suggests this is not currently under active or widespread exploitation. Note a partial tension worth verifying: the CVSS marks PR:N (unauthenticated), but the ASGI fix specifically references loading the body only after the client is 'known and authenticated,' implying that in the ASGI case the pre-check buffering happens before auth - so unauthenticated triggering is plausible for at least the ASGI path. Real-world priority is moderate: a genuine remote DoS in a widely-used real-time library, but impact is limited to availability and is contingent on running one of two specific transport configurations.

An attacker identifies a service built on python-engineio running an affected transport (ASGI long-polling or Aiohttp WebSocket) and repeatedly sends very large POST bodies or WebSocket messages. Each oversized message is buffered into memory before the size limit is applied, and a sustained flood drives memory consumption up until the process is exhausted or OOM-killed, denying service to legitimate users. No public exploit code is identified, but the attack requires only crafted oversized requests and low complexity.