CVE-2026-58268: SIPGO Library DoS Vulnerability

CVE-2026-58268 Overview

CVE-2026-58268 is a memory allocation vulnerability in SIPGO, a Go library for building Session Initiation Protocol (SIP) services. The flaw exists in ParserStream.parseSingle within sip/parser_stream.go. The function allocates a SIP body buffer using the client-controlled Content-Length header before enforcing ParseMaxMessageLength. An unauthenticated remote peer can send a single stream-transport message with an oversized declared length. The server then attempts to allocate excessive memory, leading to denial of service. The vulnerability affects TCP, TLS, WS, and WSS transports and is fixed in version 1.4.1. The weakness is classified as [CWE-789] Memory Allocation with Excessive Size Value.

Critical Impact
Unauthenticated attackers can trigger memory exhaustion on any SIPGO-based service exposed over TCP, TLS, WS, or WSS by sending a single oversized Content-Length header.

Affected Products

SIPGO library versions prior to 1.4.1
SIP services written in Go using SIPGO stream transports (TCP, TLS, WS, WSS)
Applications embedding sip/parser_stream.go from vulnerable SIPGO releases

Discovery Timeline

2026-09-22 - CVE-2026-58268 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-58268

Vulnerability Analysis

SIPGO parses SIP messages received over stream transports through ParserStream.parseSingle. When the parser reaches the message body, it reads the Content-Length header value and immediately allocates a byte slice of that size. The size check against ParseMaxMessageLength occurs after allocation rather than before. A peer can declare an arbitrarily large Content-Length value without transmitting the actual body data. The Go runtime attempts to reserve the requested memory, exhausting available heap space on the target host. The condition is reachable pre-authentication because SIP does not require credentials to establish a session or send a request.

Root Cause

The root cause is an ordering flaw in input validation. parseSingle trusts the attacker-controlled Content-Length field to size an allocation before comparing the resulting cumulative message size against the configured MaxMessageLength bound. This matches [CWE-789], where a value derived from untrusted input directly drives memory allocation.

Attack Vector

An attacker opens a TCP, TLS, WebSocket, or Secure WebSocket connection to a SIPGO listener. The attacker sends a single SIP request with a header such as Content-Length: 9999999999. The parser allocates the declared buffer size before reading any body bytes. Repeated connections amplify the impact and can crash the service through out-of-memory conditions.

// Patch applied in sip/parser_stream.go (v1.4.1)
			p.state = -1
			return nil
		}
		// avoid huge allocation if it will exceed message size
		if (p.totalRead + contentLength) > p.p.MaxMessageLength {
			return ErrMessageTooLarge
		}
		body := make([]byte, contentLength)
		p.msg.SetBody(body)
		p.state = stateContent

Source: GitHub Commit a7be60a0. The fix enforces the MaxMessageLength bound before calling make([]byte, contentLength), returning ErrMessageTooLarge when the declared length would exceed the configured limit.

Detection Methods for CVE-2026-58268

Indicators of Compromise

Inbound SIP requests with Content-Length header values disproportionate to actual body size or session context
Sudden spikes in resident memory usage on SIPGO-based processes followed by out-of-memory termination
Short-lived TCP, TLS, WS, or WSS connections to SIP ports that send headers only and never deliver body payloads

Detection Strategies

Instrument the SIP service to log parsed Content-Length values and alert when they exceed operational norms for the deployment
Correlate process restart events for SIPGO services with preceding connection metadata from network telemetry
Track Go runtime metrics such as HeapAlloc and Sys to identify abnormal allocation growth tied to specific peer connections

Monitoring Recommendations

Forward SIP proxy, load balancer, and Go application logs into a centralized analytics platform for correlation across transports
Alert on repeated ErrMessageTooLarge errors after upgrade, as they indicate ongoing exploitation attempts
Monitor connection rates per source IP on ports serving TCP, TLS, WS, and WSS SIP endpoints

How to Mitigate CVE-2026-58268

Immediate Actions Required

Upgrade SIPGO to version 1.4.1 or later in all Go services that link the library
Rebuild and redeploy any downstream binaries that vendor SIPGO through Go modules or vendored source
Restrict network exposure of SIP stream transports to trusted peers where feasible until the upgrade is deployed

Patch Information

The fix is committed in a7be60a07f48c06b3cdd5a7d35eb820b3df5736c and released as SIPGO v1.4.1. Full advisory details are published in GitHub Security Advisory GHSA-pg59-5vwg-4jxq. The patch validates p.totalRead + contentLength against p.p.MaxMessageLength before allocating the body buffer.

Workarounds

Front the SIPGO service with a reverse proxy or SIP-aware load balancer that enforces a strict maximum Content-Length value
Apply network-level rate limits on TCP, TLS, WS, and WSS SIP listeners to reduce amplification from repeated connections
Configure host-level memory limits such as cgroup constraints so that a single process cannot exhaust node memory during exploitation attempts

bash

# Update SIPGO to the patched release
go get github.com/emiago/sipgo@v1.4.1
go mod tidy
go build ./...