CVE-2026-45538

The CVSS 9.8 rating for this OpenSIPS vulnerability is technically justified — an unbounded memcpy from a 65000-byte SIP header into a 255-byte stack buffer is textbook stack smashing that can overwrite saved return addresses. But the 'single unauthenticated UDP packet yields RCE' framing is analytically incomplete in a way that should change how you prioritize this CVE. The critical detail: exploitation requires the routing script to invoke sip_to_json(). This is not a default-path vulnerability. The malformed SIP header hits the parser regardless of your configuration, but the overflow only detonates when that specific function processes the oversized header name. Here's what shifts the risk calculus. First, the RCE is conditional — if your deployment never calls sip_to_json(), the vulnerable code path is dead code. But second, and more importantly, the DoS is unconditional. Any packet reaching the SIP parser can trigger a crash even if it never invokes the vulnerable function path. For most organizations running OpenSIPS as part of a VoIP infrastructure stack — fronting Asterisk, sitting behind load balancers, feeding billing systems — the availability impact cascades through dependent services regardless of whether RCE is achievable. Your registrar crashes, call setup fails, billing anomalies surface, customer escalations follow. The CVE score captures neither this cascade effect nor the fact that a process crash is trivially achievable by any attacker. For detection and response, the gap is whether your OpenSIPS instance logs or emits signals when it encounters oversized header names before they reach the vulnerable memcpy. If the overflow occurs silently without stack protections, successful exploitation leaves minimal forensic trace beyond a crash. You need network-level detection for malformed SIP headers and correlation between header parsing events and process instability. The architectural failure — a parser permitting 65000-byte inputs feeding into a 255-byte fixed buffer with no validation layer — suggests this is likely a class of vulnerability rather than an isolated bug. Check whether other functions consuming SIP parser output have similar buffer-size assumptions that never got validated against the parser's actual limits.

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