Sipgo
Monthly
Unauthenticated denial of service in the sipgo SIP library (versions up to and including 1.4.2) lets any remote attacker who can reach a SIP-over-WebSocket (WS or WSS) listener crash or memory-exhaust the server process. WSConnection.Read allocates a buffer directly from the client-declared WebSocket frame length - a value the attacker controls up to 2^63-1 - before MaxFrameSize or the downstream ParseMaxMessageLength check is ever applied, so a single header-only frame with a huge declared length triggers a makeslice panic that terminates the whole process (sipgo does not recover it), or forces an oversized allocation. No authentication, credentials, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5, CWE-789), a working proof-of-concept frame is documented in the vendor advisory, and the flaw is fixed in 1.4.3; impact is confined to availability, with no confidentiality or integrity effect, and only services that actually enable the WS/WSS transport are exposed.
Memory-exhaustion denial of service in the SIPGO Go library (versions up to and including 1.4.0) lets an unauthenticated remote peer crash or destabilize any SIP service built on it that exposes a stream listener. A single SIP message sent over TCP, TLS, WebSocket, or WebSocket-Secure with an oversized, attacker-declared Content-Length header (up to 2^32-1) causes the stream parser to allocate a body buffer of that size before the library's 65535-byte max-message-length guard is evaluated, exhausting process memory. The flaw is fixed in version 1.4.1, the vendor advisory (GHSA-pg59-5vwg-4jxq) includes a working proof-of-concept, so publicly available exploit code exists; impact is availability-only with no code execution or data disclosure, consistent with the CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Unauthenticated denial of service in the sipgo SIP library (versions up to and including 1.4.2) lets any remote attacker who can reach a SIP-over-WebSocket (WS or WSS) listener crash or memory-exhaust the server process. WSConnection.Read allocates a buffer directly from the client-declared WebSocket frame length - a value the attacker controls up to 2^63-1 - before MaxFrameSize or the downstream ParseMaxMessageLength check is ever applied, so a single header-only frame with a huge declared length triggers a makeslice panic that terminates the whole process (sipgo does not recover it), or forces an oversized allocation. No authentication, credentials, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CVSS 7.5, CWE-789), a working proof-of-concept frame is documented in the vendor advisory, and the flaw is fixed in 1.4.3; impact is confined to availability, with no confidentiality or integrity effect, and only services that actually enable the WS/WSS transport are exposed.
Memory-exhaustion denial of service in the SIPGO Go library (versions up to and including 1.4.0) lets an unauthenticated remote peer crash or destabilize any SIP service built on it that exposes a stream listener. A single SIP message sent over TCP, TLS, WebSocket, or WebSocket-Secure with an oversized, attacker-declared Content-Length header (up to 2^32-1) causes the stream parser to allocate a body buffer of that size before the library's 65535-byte max-message-length guard is evaluated, exhausting process memory. The flaw is fixed in version 1.4.1, the vendor advisory (GHSA-pg59-5vwg-4jxq) includes a working proof-of-concept, so publicly available exploit code exists; impact is availability-only with no code execution or data disclosure, consistent with the CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).