CVE-2026-48809 in python-engineio
Summary
by MITRE • 08/11/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The python-engineio library presents a critical memory exhaustion vulnerability affecting versions prior to 4.13.2 through improper input validation and resource management. This vulnerability stems from the server implementation's failure to enforce message size limits during the processing of incoming data, creating opportunities for malicious actors to consume excessive system resources through carefully crafted requests. The flaw manifests in two distinct operational contexts: when utilizing ASGI with long polling transport and when employing Aiohttp with WebSocket transport, both scenarios presenting unique attack vectors that exploit the same underlying memory allocation weakness.
The technical implementation of this vulnerability resides in the server's message handling logic where incoming payloads are loaded into memory without size verification. In ASGI environments, requests are processed by loading full request bodies into memory before confirming client authentication status and validating payload dimensions against configured limits. Similarly, Aiohttp implementations fail to properly configure underlying WebSocket layers to reject oversized messages before they reach the python-engineio processing pipeline. This architectural oversight creates a window where unauthenticated or oversized requests can trigger unnecessary memory allocations that gradually consume available system resources.
The operational impact of this vulnerability extends beyond simple resource exhaustion to potentially enable denial-of-service attacks against applications using vulnerable versions of python-engineio. Attackers can systematically send large payloads through either POST requests with ASGI long polling or WebSocket messages with Aiohttp, causing progressive memory consumption that may lead to application crashes, service unavailability, or system instability. The vulnerability affects any application server implementation that relies on these specific transport mechanisms and configuration patterns, making it particularly concerning for high-traffic applications where resource management is critical.
The mitigation implemented in version 4.13.2 addresses the core issue through two distinct approaches tailored to each affected transport mechanism. ASGI servers now enforce authentication verification before loading request bodies into memory, ensuring that only confirmed legitimate clients can trigger memory allocation operations while simultaneously validating payload sizes against configured maximum limits. Aiohttp implementations integrate with the underlying WebSocket layer's built-in payload size limiting capabilities, allowing Aiohttp to reject oversized messages at the transport level before they reach python-engineio processing components. This dual-layer approach effectively prevents resource exhaustion attacks while maintaining backward compatibility and normal operational functionality.
This vulnerability aligns with CWE-400, which specifically addresses "Uncontrolled Resource Consumption" and represents a classic example of insufficient input validation leading to memory allocation abuse. The attack pattern follows ATT&CK technique T1499.004 for "Endpoint Denial of Service" where adversaries consume system resources to prevent legitimate use. The security implications extend beyond immediate resource exhaustion to potential cascading failures in applications that depend on stable memory allocation patterns, particularly in containerized environments where resource limits are strictly enforced and violations can trigger automatic termination policies.