Skip to main content

SIPGO CVE-2026-58268

| EUVDEUVD-2026-84817 HIGH
Memory Allocation with Excessive Size Value (CWE-789)
2026-09-22 GitHub_M GHSA-pg59-5vwg-4jxq
7.5
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach SIP stream endpoint over TCP/TLS/WS/WSS
  2. Delivery
    Send message with oversized Content-Length header
  3. Exploit
    Parser allocates buffer before size check
  4. Execution
    Memory exhaustion / OOM
  5. Impact
    Service denial of service

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
Exploitation Conditions

Exploitable only against services built on the sipgo library that expose a stream transport - specifically TCP, TLS, WS, or WSS listeners (datagram/UDP transport is not implicated by the described stream-parser path). No authentication, user interaction, or special configuration is required: an unauthenticated remote peer sends one SIP message with an attacker-controlled oversized Content-Length header (up to 2^32-1). The limiting factors are that the target must be running sipgo at or below version 1.4.0 with a stream listener reachable by the attacker; the ParseMaxMessageLength (65535) guard exists but runs too late in ParseNext to prevent the allocation. Impact is availability-only (memory exhaustion), with no path to code execution or data disclosure.

Impact

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: an unauthenticated, network-reachable, low-complexity availability-only attack (memory exhaustion). No confidentiality or integrity impact, so the 7.5 is driven entirely by A:H. A working proof-of-concept exists in the GHSA advisory (a single INVITE with Content-Length: 4000000000), so publicly available exploit code exists, but this is NOT evidence of active exploitation. No EPSS score, CISA KEV listing, or SSVC decision data was provided in the input; absence of those is not an error but does limit prioritization precision. Real-world risk is moderate rather than urgent: the flaw is trivially triggerable and pre-authentication, but the affected component is a niche Go SIP library rather than a widely deployed product, and the impact is a transient DoS (out-of-memory) rather than code execution or data loss. A single oversized-length message forces a large allocation (up to 2^32-1 bytes) before the ParseMaxMessageLength (65535) guard runs. Priority should be treated as high for the specific population running sipgo stream transports on exposed SIP endpoints, and low-to-moderate globally given the small deployment footprint. The signals do not conflict; the main caveat is simply the missing EPSS/KEV/SSVC telemetry.

Exploit ScenarioDerived

An attacker with network reach to a SIP service built on sipgo opens a TCP/TLS/WS/WSS stream and sends a single SIP message (e.g. an INVITE) declaring an enormous Content-Length such as 4000000000 with no actual body. The parser allocates a body buffer sized to the attacker-declared length before the size limit is enforced, exhausting memory and crashing or hanging the service. A functional PoC message is published in the GHSA-pg59-5vwg-4jxq advisory, making exploitation trivial and repeatable.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.6% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 22, 2026

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).

RemediationAI

Upgrade the sipgo module dependency to version 1.4.1 or later, which introduces the pre-allocation bound check that returns ErrMessageTooLarge when p.totalRead plus the declared Content-Length exceeds MaxMessageLength; the vendor-released patch is version 1.4.1 (https://github.com/emiago/sipgo/releases/tag/v1.4.1), delivered via the upstream fix commit a7be60a07f48c06b3cdd5a7d35eb820b3df5736c (https://github.com/emiago/sipgo/commit/a7be60a07f48c06b3cdd5a7d35eb820b3df5736c) and documented in advisory GHSA-pg59-5vwg-4jxq (https://github.com/emiago/sipgo/security/advisories/GHSA-pg59-5vwg-4jxq). For deployments that cannot immediately rebuild against 1.4.1, compensating controls include fronting the SIP stream listeners with a reverse proxy or security gateway that enforces a hard maximum message size and rejects or truncates any request whose Content-Length header exceeds a sane SIP limit (commonly 65535 bytes) before it reaches sipgo - the trade-off is that legitimate large SIP bodies, such as oversized SDP or MESSAGE payloads, will also be rejected, so the threshold must be tuned to the deployment. Restricting network reachability of TCP/8601-and-equivalent SIP stream ports to trusted peer networks with firewall or ACL rules reduces the exposed attack surface but does not help where the SIP service must accept connections from arbitrary user agents. Running the SIP service under an OS-level memory cap or cgroup limit converts the memory-exhaustion condition into a bounded process restart rather than host-wide pressure, though it still results in service interruption for the restarted instance. Switching an internal-only deployment to UDP transport would avoid this specific stream-parser path, but SIP over UDP has its own fragmentation and reliability drawbacks and is not viable for TLS/WebSocket-based deployments.

Affected VersionsENISA

sipgo < 1.4.1

Affected Packages

go github.com/emiago/sipgo fix: 1.4.1
euvd sipgo fix: 1.4.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

SIPGO is a Go library for building SIP (Session Initiation Protocol) user agents, proxies, and servers, and the vulnerable code lives in its stream-oriented parser, sip/parser_stream.go. SIP is a text-based signaling protocol whose messages carry a Content-Length header declaring the size of the message body, and for stream transports (TCP, TLS, WS, WSS) the parser must read and buffer that body incrementally. In ParserStream.parseSingle, the library executed 'body := make([]byte, contentLength)' directly from the client-supplied Content-Length value, which is parsed as an unsigned 32-bit integer and can therefore be as large as 4,294,967,295 bytes. The message-size enforcement constant ParseMaxMessageLength (65535) is checked in the caller ParseNext, but only after parseSingle has already performed the allocation, so the guard fires too late to prevent the memory reservation. This is a classic CWE-789 (Memory Allocation with Excessive Size Value) pattern, sometimes described as an uncontrolled resource consumption / pre-validation allocation flaw: the size value is trusted and used to size a buffer before it is validated against an upper bound. The fix in commit a7be60a07f48c06b3cdd5a7d35eb820b3df5736c adds a pre-allocation check that rejects the message with ErrMessageTooLarge when (p.totalRead + contentLength) exceeds p.p.MaxMessageLength. Note that the described code path is specific to the stream parser, so UDP/datagram transports are not implicated.

Know when Sipgo gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI 7.5 HIGH

Unauthenticated network peer sends one crafted message over a stream transport with no user interaction; impact is availability-only memory exhaustion, so C:N/I:N/A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Patch available
Sep 22, 2026 - 21:03 EUVD
CVE Published
Sep 22, 2026 - 19:49 cve.org
HIGH 7.5

DescriptionCVE.org

SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.1, ParserStream.parseSingle in sip/parser_stream.go allocates a SIP body buffer from the client-controlled Content-Length header before ParseMaxMessageLength is enforced. An unauthenticated peer can send a stream-transport message over TCP, TLS, WS, or WSS with an oversized declared length, causing excessive memory allocation and denial of service before the body is read. This issue is fixed in version 1.4.1.

Technical POC Analysis

CWE-789 (Memory Allocation with Excessive Size Value).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Any SIP-based voice or real-time communications service built on the SIPGO Go library at version 1.4.0 or earlier can be knocked offline by a single unauthenticated network message, putting inbound call routing, contact-center queues, and other telephony-dependent operations at immediate risk. Publicly available exploit code exists, and the triggering traffic is trivial to send over TCP, TLS, WebSocket, or WebSocket-Secure, so any internet-reachable stream listener is a viable target without credentials or user interaction. The defect affects availability only - no data disclosure or code execution - but sustained memory exhaustion can crash processes repeatedly and degrade service for the entire customer and employee base relying on that voice platform.

Business Impact: High
Compensating Controls

Apply vendor patch (upgrade to SIPGO 1.4.1). Where immediate upgrade is not possible: enforce a maximum declared Content-Length of 65535 bytes at an upstream proxy/WAF so oversized SIP bodies are rejected before reaching the parser, rate-limit and cap concurrent connections per source IP, restrict stream listeners to trusted networks or VPN where feasible, and apply process/container memory limits with supervised auto-restart to contain exhaustion.

Threat Intelligence Overview

EPSS Score
0.6%
Top 52% exploitable
Prevalence
Low
niche open-source Go SIP library, limited production footprint
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC Yes
EPSS 0.6%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

59
Low Medium High Critical
KEV: 0
EPSS: +1
CVSS: +38
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy