Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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): - 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. This crashes the server process: Suggested Fix Set MaxFrameSize on the wsutil.NewReader. Impact…
Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/parserstream.go#L195): The ParseMaxMessageLength (65535) check is in the caller ParseNext (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parserstream.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: 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.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/emiago/sipgo >= 0.3.0, < 1.0.0-alpha-1
Fixed in
1.0.0-alpha-1· Vendor fix available
Issue
A nil pointer dereference vulnerability was discovered in the SIPGO library's NewResponseFromRequest function that affects all normal SIP operations. The vulnerability allows remote attackers to crash any SIP application by sending a single malformed SIP request without a To header. The vulnerability occurs when SIP message parsing succeeds for a request missing the To header, but the response creation code assumes the To header exists without proper nil checks. This affects routine operations like call setup, authentication, and message handling - not just error cases. Note: This vulnerability affects all SIP applications using the sipgo library, not just specific configurations or edge cases, as long as they make use of the NewResponseFromRequest function. Technical details The vulnerability is located in /sip/response.go at line 242 in the NewResponseFromRequest function: Root Cause: 1. Missing To Header: When any SIP request is sent without a To header, the SIP…
Recommended action: Upgrade to 1.0.0-alpha-1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.