GitHub Advisoryadvisory · Go

GHSA-pg59-5vwg-4jxq SIPGO: DoS via unvalidated Content-Length in the stream parser

HIGH Published 2026-09-22 Modified 2026-09-22 Official page ↗
Aliases
CVE-2026-58268
Ecosystem
Go
Packages
github.com/emiago/sipgo
Severity
High
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weaknesses
CWE-789
Reviewed
2026-09-22

Affected packages

• Go github.com/emiago/sipgo: < 1.4.1 → fixed in 1.4.1

Description

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/parser_stream.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/parser_stream.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:[email protected] SIP/2.0 Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1 From: ;tag=1 To: Call-ID: [email protected] 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.

Related

Alias · CVE (1)

  • CVE-2026-58268 SIPGO is a library for writing SIP services in the GO language. vulnerability

Weakness · CWE (1)

  • CWE-789 Memory Allocation with Excessive Size Value weakness

References