CVE-2026-73665

The Socket.IO 4 upgrade that introduced CVE-2026-73665 exemplifies a systemic failure mode that security teams need to defend against proactively: dependency versions changing security-relevant defaults without explicit migration requirements. In Socket.IO 3, authentication middleware applied consistently across all namespaces. In version 4, it applies only to the default namespace, requiring explicit re-application to custom namespaces. This behavioral shift was not surfaced as a security-critical breaking change—it was documented (if at all) in changelog sections alongside renamed methods and removed parameters, contexts where developers hunt for functional regressions, not security disconnects. The FreePBX team had implemented correct authentication middleware; what they lacked was a mechanism to verify that their dependency honored that architectural assumption. This is not developer negligence—it is information asymmetry that current tooling cannot close. The second failure layer compounds the problem: the AMI action path in asterisk-manager-patch.js contained CRLF injection vulnerability that predates this CVE. The Socket.IO change merely demolished the authentication wall that was keeping it latent. This is the pattern to recognize: individually documented, individually low-severity flaws that achieve CVSS 9.3 when infrastructure changes expose their intersection. Your defensive posture should include three measures: first, audit your Socket.IO implementations to confirm authentication middleware explicitly covers every namespace, treating version 4's behavior as the insecure default; second, treat any AMI action path that accepts user-supplied input as CRLF-injection-vulnerable regardless of what access controls surround it—the class of vulnerability has been known since HTTP response splitting was documented in the early 2000s; third, establish dependency upgrade security regression tests that verify authentication and input validation assumptions hold after dependency changes, not just that functional behavior is correct. The deeper pattern across Django, Flask, Express, and Socket.IO confirms: high-level libraries promising security guarantees that depend on implementation-defined behavior across versions represent a known architectural anti-pattern. Assume nothing about security defaults across major library versions—verify explicitly, every time.

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