Critical Stack Buffer Overflow in sngrep's SIP Header Parser

Executive Summary

A critical stack-based buffer overflow (CVE-2026-90558) has been disclosed in sngrep, the widely used open-source SIP traffic analyzer maintained by Irontec. The flaw lives in the tool's SIP header formatting routines, which copy attacker-controlled header values — including Call-ID and X-Call-ID — into fixed 255-byte stack buffers without validating their length. Any SIP packet with an oversized header value overflows the buffer and corrupts adjacent stack memory, including potentially the return address.

CVSS Score: 9.8 (CVSS 3.1) / 9.3 (CVSS 4.0) — Critical

No official patched release exists yet, though a fix commit has surfaced upstream (unverified as shipped).

Vulnerability Overview

Affected Versions

Attack Vector

1. Attacker identifies a host running sngrep to monitor/capture SIP traffic
2. Attacker crafts a SIP packet with an oversized Call-ID, X-Call-ID, or
   similar header value (exceeding the 255-byte buffer sngrep allocates)
3. Attacker sends (or induces) the packet toward a network segment sngrep
   is capturing on
4. sngrep's header formatting routine copies the value into a fixed stack
   buffer with no length check, overflowing it
5. Adjacent stack memory — potentially including the return address — is
   corrupted, causing a crash and opening the door to code execution

Impact of Successful Exploitation

This maps to MITRE ATT&CK T1499 (Endpoint Denial of Service) at minimum, with the buffer-overflow primitive itself falling under CWE-121.

Why this matters for VoIP shops: sngrep is a staple tool for SIP/VoIP engineers doing live traffic debugging and packet capture analysis. It's commonly run with elevated privileges to bind to network interfaces, which raises the stakes of any memory-corruption bug found in its parsing path.

Immediate Remediation

Step 1: Check Your Version

Confirm your deployed sngrep build is v1.8.4 or earlier. There is currently no vendor-confirmed patched release to upgrade to.

Step 2: Reduce Exposure

1. Restrict sngrep's capture scope to trusted network segments only — avoid running it against untrusted or internet-facing SIP traffic
2. Run sngrep with the least privilege necessary rather than as root, to limit the blast radius of a successful exploit
3. Deploy sngrep behind a SIP-aware filtering layer (e.g., a SIP proxy or firewall with header-length enforcement) that rejects abnormally long Call-ID/X-Call-ID values before they reach sngrep

Step 3: Monitor for Abuse

# Watch for sngrep process crashes correlated with inbound SIP traffic
# containing header values well beyond typical Call-ID lengths (~50-80 chars)
 
# Consider capturing crash cores for analysis if sngrep segfaults
# unexpectedly in production

Post-Remediation Steps

1. Track the upstream Irontec repository for an official tagged release addressing this CVE and apply it as soon as it ships
2. Audit any automation or dashboards that ingest sngrep output for unexpected downtime tied to this issue
3. Consider isolating sngrep instances in a container or restricted VM given the RCE potential, until a confirmed fix is available

References

• NIST NVD — CVE-2026-90558
• VulDB — CVE-2026-90558
• OffSeq Threat Radar — Stack-Based Buffer Overflow in Irontec sngrep
• Strix.ai — CVE-2026-90558