CVE-2026-77322: SIPGO: DoS via unvalidated WebSocket frame length
Summary
The WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS.
Details
WSConnection.Read allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transportws.go#L400):
go data := make([]byte, header.Length) // header.Length is client-controlled, up to 2^63-1 (int64)
- NextFrame() reads only the frame header and never checks the length: wsutil.NewReader is created with no MaxFrameSize (0 = unlimited). ParseMaxMessageLength applies only downstream, not here. - A value above the max slice size (e.g. 2^63-1) panics make. sipgo does not recover from this panic, so it crashes the whole server process.
PoC
Tested on emiago/sipgo v1.4.0 (latest).
After a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read.
0x81 FIN + text opcode 0xFF MASK bit + length marker 127 (8-byte length follows) 0x7F FF FF FF FF FF FF FF declared length = 2^63-1 -> make panics (crash) <4-byte masking key> (no payload)
This crashes the server process:
panic: runtime error: makeslice: len out of range
goroutine 23 [running]: github.com/emiago/sipgo/sip.(WSConnection).Read(...) /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transportws.go:400 +0x2df github.com/emiago/sipgo/sip.(TransportWS).readConnection(...) /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transportws.go:194 +0x266 created by github.com/emiago/sipgo/sip.(TransportWS).initConnection in goroutine 21 /path/to/pkg/mod/github.com/emiago/sipgo@v1.4.0/sip/transportws.go:167 +0x268
Suggested Fix
Set MaxFrameSize on the wsutil.NewReader.
Impact
Unauthenticated DoS. Any service using sipgo with a WS/WSS transport can be crashed by a single frame (panic), or forced to run out of memory.
Other sources
SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transportws.go creates a wsutil.Reader without setting MaxFrameSize, allowing NextFrame to accept a client-controlled header.Length before ParseMaxMessageLength is applied. An unauthenticated WS or WSS peer can send a frame header declaring an extremely large payload, causing an oversized allocation or a makeslice length panic before the payload is read and crashing or exhausting memory in the server process. This issue is fixed in version 1.4.3.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/emiago/sipgoto a version that resolves this vulnerability.Fixed in 1.4.3 - Upgrade
Upgrade
emiago/sipgoto a version that resolves this vulnerability.Fixed in 1.4.3 - Configuration
Set MaxFrameSize on wsutil.NewReader to impose a maximum WebSocket frame size; the default value 0 is unlimited.
wsutil.NewReader MaxFrameSize = non-zero maximum
Event History
Frequently Asked Questions
Which deployments are exposed to this denial of service?
SIP services written with affected SIPGO versions that accept WebSocket or secure WebSocket (WSS) connections are exposed. The issue is reachable by an unauthenticated peer.
What does an attacker need to do to trigger the issue?
An attacker only needs network access to a WS or WSS endpoint and can send a WebSocket frame header that declares an extremely large payload length. No authentication or user interaction is required.
What is the impact if exploitation succeeds?
The server process may perform an oversized allocation, panic while creating a slice, or exhaust memory before the frame payload is read. This can crash the process or cause denial of service.
What version resolves the issue?
Upgrade SIPGO to version 1.4.3, which sets a WebSocket frame-size limit before processing the client-controlled length.