CVE-2026-77322: SIPGO Library DOS Vulnerability

CVE-2026-77322 Overview

CVE-2026-77322 is a denial-of-service vulnerability in SIPGO, a Go library for building Session Initiation Protocol (SIP) services. The flaw affects the WebSocket (WS) and secure WebSocket (WSS) transport in sip/transport_ws.go. The WSConnection.Read function instantiates a wsutil.Reader without configuring MaxFrameSize, so NextFrame trusts the client-declared header.Length before ParseMaxMessageLength is enforced. An unauthenticated remote peer can send a WebSocket frame header advertising an oversized payload, triggering an excessive allocation or a makeslice length panic. The result is a crash or memory exhaustion in the SIP server process. The issue is fixed in SIPGO version 1.4.3.

Critical Impact
Unauthenticated remote attackers can crash SIPGO-based SIP servers or exhaust host memory by sending a single malformed WebSocket frame header.

Affected Products

SIPGO library versions prior to 1.4.3
Go-based SIP services using WebSocket (WS) transport
Go-based SIP services using secure WebSocket (WSS) transport

Discovery Timeline

2026-09-22 - CVE-2026-77322 published to the National Vulnerability Database
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-77322

Vulnerability Analysis

The vulnerability is an allocation-of-resources-without-limits issue tracked as [CWE-789]. SIPGO exposes SIP signaling over WebSocket transports through the WSConnection.Read function in sip/transport_ws.go. That function constructs a wsutil.Reader from the gobwas/ws library but never assigns reader.MaxFrameSize. As a result, reader.NextFrame() reads the WebSocket frame header and accepts whatever payload length the peer declares. SIPGO's own ParseMaxMessageLength cap is only consulted after the frame is materialized, which is too late to prevent the underlying allocation.

When the declared length is very large, the Go runtime either attempts an oversized allocation that drives the process into memory exhaustion, or it triggers a makeslice: len out of range panic that terminates the goroutine and, depending on recovery, the whole server. Either outcome denies service to legitimate SIP clients.

Root Cause

The root cause is missing input validation on an attacker-controlled length field. The wsutil.Reader has a MaxFrameSize field that bounds the accepted header.Length, but SIPGO left it at the zero default, meaning no limit. Trust in the peer-supplied header is placed before any application-layer size check.

Attack Vector

Exploitation requires only network reachability to a SIPGO WebSocket listener. No authentication, credentials, or user interaction are needed. An attacker opens a WS or WSS connection and transmits a WebSocket data frame whose header advertises an extremely large payload length. The server attempts to allocate a buffer sized to that declared length and crashes or stalls before the payload is ever transferred.

// Patch: sip/transport_ws.go — enforce MaxFrameSize before NextFrame reads a
// client-controlled header.Length. Source: https://github.com/emiago/sipgo/commit/769e4bc958376e2363566c8f7042202b410becdc
 		state = ws.StateClientSide
 	}
 	reader := wsutil.NewReader(c.Conn, state)
+	reader.MaxFrameSize = int64(ParseMaxMessageLength)
 	for {
 		header, err := reader.NextFrame()
 		if err != nil {

The one-line fix binds the WebSocket reader's maximum frame size to ParseMaxMessageLength, so oversized frames are rejected during header parsing instead of triggering allocation.

Detection Methods for CVE-2026-77322

Indicators of Compromise

Unexpected process termination of SIPGO-based services with Go runtime panics referencing makeslice: len out of range in the goroutine reading from wsutil.Reader.
Sudden resident-set-size spikes on SIP server hosts followed by out-of-memory kills recorded by the kernel or container runtime.
Repeated short-lived WS or WSS connections from a single source that disconnect immediately after the opening handshake.

Detection Strategies

Inspect WebSocket traffic to SIP endpoints for frame headers declaring payload lengths that exceed configured SIP message limits.
Correlate service restart events on SIP servers with inbound WS or WSS sessions to identify crash-inducing peers.
Track goroutine panic stack traces containing wsutil.(*Reader).NextFrame as high-confidence exploitation evidence.

Monitoring Recommendations

Alert on repeated crashes or restarts of processes linking the github.com/emiago/sipgo module.
Monitor memory pressure and OOM events on hosts exposing SIP over WebSocket to the internet or untrusted networks.
Log source IPs of WS or WSS clients whose sessions terminate abnormally and rate-limit repeat offenders at the reverse proxy or load balancer.

How to Mitigate CVE-2026-77322

Immediate Actions Required

Upgrade the SIPGO dependency to version 1.4.3 or later and redeploy all affected services.
Restrict WS and WSS SIP transports to trusted networks until the upgrade is complete.
Place a reverse proxy or WebSocket-aware gateway in front of SIPGO listeners to enforce a maximum frame size independent of the library.

Patch Information

The fix is delivered in SIPGO release v1.4.3 via commit 769e4bc9. Additional detail is available in the GitHub Security Advisory GHSA-8h6x-h86x-75wh. The patch sets reader.MaxFrameSize = int64(ParseMaxMessageLength) so oversized frames are rejected during header parsing.

Workarounds

Terminate WS and WSS SIP traffic at an upstream proxy that enforces a strict WebSocket frame size before it reaches SIPGO.
Disable the WebSocket transports in SIPGO configuration and rely on UDP, TCP, or TLS transports if application requirements allow.
Apply network ACLs to limit which peers can open WebSocket connections to the SIP server.

bash

# Update SIPGO to the patched release in a Go project
go get github.com/emiago/sipgo@v1.4.3
go mod tidy
go build ./...