EUVD-2026-52979Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Transport-layer parsing requires no authentication or interaction; Content-Length overflow enables arbitrary SIP injection (high integrity) with no confidentiality or availability impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
OpenSIPS is a Session Initiation Protocol (SIP) server implementation. In versions prior to 3.6.6 and 4.0.0-rc1, the TCP message framing layer parses the Content-Length header using unsigned int arithmetic with no overflow check. When an attacker sends a Content-Length value that overflows unsigned int (e.g., 4294967296), the framing layer computes a wrapped-around value (e.g., 0) and splits the TCP stream at the wrong boundary, causing the body of the first SIP message to be processed as a separate message and enabling SIP message smuggling. Because Content-Length is parsed in the transport layer before authentication, an unauthenticated, network-based attacker can smuggle arbitrary SIP messages over any TCP-based transport (proto_tcp, proto_tls, proto_ws, proto_wss) on any instance with TCP enabled, with no routing-script preconditions. This allows smuggled messages to bypass front-end SBC/proxy security policies, inherit the connection's authentication context, and evade rate limiting. This issue has been fixed in versions 3.6.6 and 4.0.0-rc1.
AnalysisAI
SIP message smuggling in OpenSIPS via unsigned integer overflow in TCP Content-Length parsing enables unauthenticated remote attackers to inject arbitrary SIP messages that bypass front-end SBC and proxy security policies, inherit connection authentication context, and evade rate limiting. All OpenSIPS instances with any TCP-based transport enabled (proto_tcp, proto_tls, proto_ws, proto_wss) running versions prior to 3.6.6 or 4.0.0-rc1 are affected, with no routing-script preconditions required. No public exploit code or CISA KEV listing has been identified at time of analysis, but the attack requires only a single malformed packet against a default TCP-enabled configuration.
Technical ContextAI
OpenSIPS is an open-source SIP (Session Initiation Protocol) server widely deployed in VoIP, unified communications, and telecommunications infrastructure. The vulnerability resides in net/proto_tcp/tcp_common.h within the tcp_parse_headers() function, which stores the parsed Content-Length header value in an unsigned int without any upper-bound or overflow validation - a textbook CWE-190 (Integer Overflow or Wraparound) defect. Sending a Content-Length value of 4294967296 (2^32) causes the 32-bit unsigned integer accumulator to wrap around to 0, causing the TCP stream framing layer to miscompute the message boundary. The body of the attacker's first SIP message is then fed back into the parser as an independent SIP message, enabling the classic HTTP/SIP request smuggling attack class applied to the SIP protocol over TCP. The fix confirmed in commit 4d23613b adds a bounds check against TCP_BUF_SIZE immediately after parsing the content_len value, rejecting any value exceeding the read buffer size and transitioning the connection to the H_SKIP error state. Secondary commits (5f103eff) address related length checks in other parsing paths (sipmsgops, msg_translator, parse_body, transformations) as part of the same hardening effort.
RemediationAI
Upgrade to OpenSIPS 3.6.6 (3.x branch) or 4.0.0-rc1 (4.x branch), both of which include the Content-Length upper-bound check added in net/proto_tcp/tcp_common.h via commits 4d23613b and 5f103eff - these are vendor-confirmed fix versions per advisory GHSA-jv35-555v-54jh. As a compensating control pending patching, deploy an upstream SBC or SIP-aware firewall configured to reject SIP messages with Content-Length values exceeding a realistic ceiling (e.g., 65535 bytes); however, not all SBC products inspect TCP-layer SIP framing at this granularity, so this mitigation requires verification per product. Restricting TCP listener access to known trusted source IPs reduces attack surface but does not eliminate risk from compromised upstream nodes that already have TCP access. Disabling all TCP-based transports and operating UDP-only eliminates the vulnerability entirely but breaks TLS, WebSocket, and WebSocket Secure support, which is not viable for most production deployments.
Same weakness CWE-190 – Integer Overflow or Wraparound
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today