CVE-2026-77322

SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.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.

SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.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.

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/transport_ws.go#L400):

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/[email protected]/sip/transport_ws.go:400 +0x2df
github.com/emiago/sipgo/sip.(*TransportWS).readConnection(...)
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.go:194 +0x266
created by github.com/emiago/sipgo/sip.(*TransportWS).initConnection in goroutine 21
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.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.

SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.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.

SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.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.

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/transport_ws.go#L400):

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/[email protected]/sip/transport_ws.go:400 +0x2df
github.com/emiago/sipgo/sip.(*TransportWS).readConnection(...)
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.go:194 +0x266
created by github.com/emiago/sipgo/sip.(*TransportWS).initConnection in goroutine 21
        /path/to/pkg/mod/github.com/emiago/[email protected]/sip/transport_ws.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.

SIPGO: DoS via unvalidated WebSocket frame length in github.com/emiago/sipgo