CVE-2026-58268: SIPGO: DoS via unvalidated Content-Length in the stream parser
Summary
The stream parser allocates the SIP body buffer from the Content-Length header before validating its size, which can lead to an unauthenticated DoS.
Details
ParserStream.parseSingle allocates the body buffer from the declared Content-Length with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parserstream.go#L195):
go body := make([]byte, contentLength) // contentLength is client-controlled, up to 2^32-1 (uint32)
The ParseMaxMessageLength (65535) check is in the caller ParseNext (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parserstream.go#L132), and only runs after parseSingle has already allocated the buffer.
PoC
Tested on emiago/sipgo v1.4.0 (latest).
Send a single message with a large Content-Length and no body to a SIP server:
INVITE sip:victim@example.com SIP/2.0 Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1 From: <sip:attacker@attacker.example>;tag=1 To: <sip:victim@example.com> Call-ID: 1@attacker.example CSeq: 1 INVITE Content-Length: 4000000000 // <- a large Content-Length
Suggested Fix
Validate contentLength against ParseMaxMessageLength before the allocation.
Impact
Unauthenticated DoS. Any service using sipgo with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.
Other sources
SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.1, ParserStream.parseSingle in sip/parserstream.go allocates a SIP body buffer from the client-controlled Content-Length header before ParseMaxMessageLength is enforced. An unauthenticated peer can send a stream-transport message over TCP, TLS, WS, or WSS with an oversized declared length, causing excessive memory allocation and denial of service before the body is read. This issue is fixed in version 1.4.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/emiago/sipgoto a version that resolves this vulnerability.Fixed in 1.4.1 - Upgrade
Upgrade
emiago/sipgoto a version that resolves this vulnerability.Fixed in 1.4.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using SIPGO versions before 1.4.1 that accept SIP messages over stream transports are exposed. The affected transports are TCP, TLS, WebSocket (WS), and secure WebSocket (WSS).
What does an attacker need to exploit it?
An unauthenticated peer only needs network access to send a crafted SIP message over an affected stream transport. The message declares an oversized Content-Length value, triggering allocation before the configured maximum message length is enforced.
Does setting ParseMaxMessageLength prevent exploitation in affected versions?
No. In versions before 1.4.1, the buffer allocation based on Content-Length occurs before ParseMaxMessageLength is enforced, so the limit does not prevent the excessive allocation.
How can I determine whether an application is affected?
Check whether the application depends on go/github.com/emiago/sipgo at a version earlier than 1.4.1 and accepts SIP traffic over TCP, TLS, WS, or WSS. Such deployments can be affected even if they configure ParseMaxMessageLength.
What is the remediation?
Upgrade SIPGO to version 1.4.1, which fixes the parser behavior.