sipgo CVE-2026-77322

Exploitable only when a service built on sipgo enables the WebSocket transport (WS or WSS) and exposes it to the network; the SIP-over-WebSocket listener must be reachable by the attacker. No authentication, credentials, or user interaction are required (PR:N/UI:N) - after a standard WebSocket handshake a single crafted frame header triggers the flaw against default configurations of sipgo <=1.4.2. The primary limiting factor is deployment: services using only UDP/TCP/TLS SIP transports (not WebSocket) are not affected, and the impact is limited to denial of service with no confidentiality or integrity consequences.

This is a genuine but bounded risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 HIGH) is well-supported by the evidence: a single unauthenticated WebSocket frame reaches vulnerable code with no privileges or user interaction, matching AV:N/AC:L/PR:N/UI:N. Impact is availability-only (A:H, C:N/I:N) - there is no code execution, data disclosure, or integrity loss, consistent with CWE-789 uncontrolled memory allocation. Working PoC code is embedded in the GHSA advisory (a masked text frame declaring length 2^63-1 triggers a makeslice panic), so publicly available exploit code exists, though there is no CISA KEV listing and no EPSS score in the provided data. No SSVC decision data was supplied. The realistic-priority weighting is tempered by product prevalence: sipgo is a niche Go SIP library, not a ubiquitous component, so widespread automated exploitation is unlikely despite the low attack complexity. For any organization actually running a sipgo-based SIP service on WS/WSS, this is a real and trivially-triggerable crash and should be patched to 1.4.3; for everyone else it is not relevant. No signals conflict here - the vector, description, and advisory all align on unauthenticated remote DoS.

An attacker completes a normal WebSocket handshake against a sipgo-based SIP service exposed over WS/WSS, then sends a single masked frame containing only a header that declares a payload length near 2^63-1. WSConnection.Read calls make([]byte, header.Length) before any size validation, causing a makeslice panic (or massive allocation) that crashes the unrecovered server process. Working proof-of-concept code and the exact byte sequence are published in the GHSA-8h6x-h86x-75wh advisory.