CVE-2026-48804

The fix for CVE-2026-48804 in python-socketio 5.16.4 addresses a memory exhaustion vulnerability in the binary attachment protocol by requiring authentication before the server allocates space for incoming attachments. This is the right short-term fix, but it masks a deeper architectural problem: the Socket.IO binary protocol commits memory optimistically, telling the server "I expect N attachments" and allocating space before data arrives, then waiting indefinitely with no timeout or resource limit governing that commitment. The core issue isn't that unauthenticated clients could trigger this — it's that the protocol design allows the server to hold memory in promise of future I/O with no backpressure signal to the client and no time-bound reclamation. An authenticated client who sends a partial binary message and then goes silent still holds that memory until disconnect. You need to verify whether 5.16.4 implements timeout-based cleanup for partial binary messages or only cleanup-on-disconnect. For long-lived connections with intermittent activity, the distinction is significant — if a client stays connected but stops sending attachments, disconnect-only cleanup provides no protection. The CVSS of 7.5 paired with an EPSS of only 0.00279 is a useful signal. The narrow EPSS suggests the exploitability is constrained — weaponizing this requires maintaining authenticated sessions while withholding data, which is harder to scale than a simple flood. However, this creates an asymmetry: the fix now affects every deployment using binary attachments, while only a fraction were genuinely exposed to the original attack. You're changing the threat model silently for the entire user base. There's also a second-order risk. By gating binary attachments behind authentication, you've moved the DoS vector to the auth path itself. Your authentication endpoint now becomes the pressure point under adversarial load, and it may not be hardened for that role. Organizations using Socket.IO for binary transfers need to assess whether their auth layer can withstand the request patterns that binary attachment handling will now generate. Prioritize verifying the cleanup mechanism in 5.16.4, understanding your per-client memory limits for held binary messages, and stress-testing your auth layer under load before deploying this patch to production.

Reviewed through automated stages and approved by a human before publication.