CVE-2026-77322 in Sipgo
Summary
by MITRE • 09/22/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in SIPGO versions prior to 1.4.3 represents a critical resource exhaustion flaw within the WebSocket transport layer implementation of this Go-based library for Session Initiation Protocol services. The core technical deficiency lies in the initialization sequence of the wsutil.Reader object during the execution of the WSConnection.Read function located in sip/transport_ws.go. Specifically, when establishing or maintaining a WebSocket connection, the code fails to configure the MaxFrameSize parameter on the reader instance before invoking NextFrame to process incoming data frames. This omission creates a window where the library accepts frame headers directly from unauthenticated clients without enforcing size constraints at the parsing stage.
In standard WebSocket protocol operations, the first part of an incoming message is the header, which contains metadata including the length of the subsequent payload. Because MaxFrameSize was not set, the NextFrame function proceeds to parse this client-controlled header.Length value immediately. The library then attempts to allocate memory for a buffer capable of holding the declared payload size before any validation against ParseMaxMessageLength occurs. This sequence error means that an attacker can craft a malicious WebSocket frame with a header declaring an excessively large payload length, such as several gigabytes or even larger values depending on system limits and integer overflow behaviors in Go's makeslice function.
The operational impact of this flaw is severe, leading to either a denial of service through memory exhaustion or a catastrophic application crash. When the server process attempts to allocate memory for the oversized buffer based on the malicious header length, it may trigger an out-of-memory condition if sufficient resources are available but insufficient for such a massive allocation. Alternatively, and more commonly in Go environments, this action results in a makeslice panic due to an invalid slice capacity or length exceeding system limits. This causes the goroutine handling that specific connection to terminate abruptly, potentially destabilizing the entire SIP service depending on how gracefully the application handles panics within its main event loop. Since the vulnerability affects unauthenticated peers, any external actor can exploit this without needing valid credentials, making it a high-risk remote denial of service vector.
From an industry standards perspective, this flaw aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to properly limit the amount of resources consumed by user input. It also relates to CWE-787: Out-of-bounds Write if the allocation leads to memory corruption, though primarily it manifests as a crash or resource exhaustion scenario typical of improper validation before buffer allocation. In terms of MITRE ATT&CK mapping, this vulnerability facilitates Denial of Service (T1499) by allowing an attacker to disrupt service availability through resource depletion techniques targeting application layer protocols.
Mitigation for this issue requires immediate upgrading to SIPGO version 1.4.3 or later, where the developers have corrected the initialization logic to ensure MaxFrameSize is properly set before frame parsing begins. For organizations unable to upgrade immediately due to dependency constraints, implementing a reverse proxy with WebSocket support that enforces strict message size limits can provide an effective workaround. Such proxies should be configured to drop any frames exceeding a reasonable payload threshold, thereby preventing malicious headers from reaching the vulnerable application layer code. Additionally, developers integrating SIPGO into larger systems should ensure their Go runtime is updated to recent stable releases to benefit from general improvements in panic recovery and memory management mechanisms that may mitigate some secondary effects of such allocation failures.