CVE-2026-90558: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-90558 is a stack-based buffer overflow vulnerability in sngrep, an ncurses-based SIP message flow viewer developed by Irontec. The flaw exists in SIP attribute formatting routines (call_get_attribute() in sip_call.c and msg_get_attribute() in sip_msg.c) where header values exceeding the 255-byte SIP_ATTR_MAXLEN buffer limit can overflow stack buffers during packet parsing and rendering. All versions of sngrep through 1.8.4 are affected. The vulnerability was disclosed on September 12, 2026, and carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory, VulnCheck).

The root cause is CWE-121 (Stack-based Buffer Overflow): the call_get_attribute() function in src/sip_call.c used unbounded sprintf("%s", ...) calls when formatting Call-ID, X-Call-ID, and Reason header values into a 255-byte stack buffer (SIP_ATTR_MAXLEN). Since Call-ID and X-Call-ID fields can hold up to 1023 bytes (MAX_CALLID_SIZE/MAX_XCALLID_SIZE) and Reason text is copied from the raw payload (up to MAX_SIP_PAYLOAD), a crafted SIP message with an oversized header overflows the stack buffer. Additionally, msg_get_attribute() in src/sip_msg.c contained an off-by-one error where "%.*s" used SIP_ATTR_MAXLEN (255) as the precision, allowing 256 bytes (255 chars + NUL) to be written into the 255-byte buffer. The vulnerability is triggerable via pcap file loading, live network capture, or HEP/EEP remote capture, requiring no authentication or user interaction (GitHub Commit, sip_call.c v1.8.4).

Successful exploitation can result in application crashes (denial of service) or arbitrary code execution on the system running sngrep, with full confidentiality, integrity, and availability impact. Because sngrep is commonly run by network administrators and VoIP engineers for SIP traffic analysis — often with elevated privileges for packet capture — a compromise could expose sensitive call metadata, credentials embedded in SIP headers, and potentially allow lateral movement within the network. The attack is network-delivered and requires no prior authentication, making it particularly dangerous in environments where sngrep processes untrusted SIP traffic from external sources (GitHub Advisory, VulnCheck).

As of the disclosure date, there is no public proof-of-concept exploit code and no evidence of active in-the-wild exploitation (GitHub Advisory). The vulnerability was reported by researcher TristanInSec and assigned by VulnCheck. The EPSS score is approximately 0.507%, indicating a low but non-negligible probability of exploitation in the near term. The CVE is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD SSVC assessment classifies the vulnerability as not automatable with total technical impact, suggesting exploitation requires some targeting but yields full system compromise if successful.

1. Reconnaissance: Identify systems running sngrep through 1.8.4 that are performing live SIP capture on a network interface, processing pcap files, or receiving HEP/EEP remote capture streams. Tools like Shodan or network scanning can identify exposed HEP/EEP listeners (typically UDP/TCP port 9060).
2. Craft malicious SIP packet: Construct a SIP message (e.g., INVITE or REGISTER) with an oversized Call-ID, X-Call-ID, or Reason header field exceeding 255 bytes — for example, a Call-ID of 1024+ bytes filled with attacker-controlled data.
3. Deliver the payload: Transmit the crafted SIP packet to the network segment being monitored by sngrep (for live capture), inject it into a pcap file loaded by sngrep, or send it via the HEP/EEP protocol if remote capture is enabled.
4. Trigger buffer overflow: When sngrep parses the packet and calls call_get_attribute() or msg_get_attribute() to render the oversized header into the 255-byte stack buffer via unbounded sprintf(), the stack is overflowed with attacker-controlled data.
5. Achieve code execution or crash: Depending on stack layout and memory protections (ASLR, stack canaries), the overflow may overwrite the return address to redirect execution to attacker-controlled shellcode or ROP chain, or cause an immediate crash (GitHub Commit, VulnCheck).

• Network: Inbound SIP packets (UDP/TCP port 5060, or HEP/EEP port 9060) containing Call-ID, X-Call-ID, or Reason header fields exceeding 255 bytes; anomalously large SIP messages from unexpected source IPs.
• Process: Unexpected crash or core dump of the sngrep process; sngrep spawning unexpected child processes (e.g., /bin/sh, bash, curl, wget) if exploitation achieves code execution.
• File System: Core dump files (e.g., core, core.sngrep) in the working directory or /var/crash/; unexpected new files or scripts created by the user account running sngrep.
• Logs: System logs (/var/log/syslog, /var/log/messages) showing segmentation fault or signal 11 (SIGSEGV) for the sngrep process; kernel logs indicating stack smashing detected if stack canaries are enabled (__stack_chk_fail).

The fix was committed to the sngrep repository (commit 1ff74ee) by replacing unbounded sprintf("%s", ...) calls with precision-bounded sprintf("%.*s", SIP_ATTR_MAXLEN - 1, ...) in both src/sip_call.c and src/sip_msg.c, and correcting the off-by-one in msg_get_attribute(). Users should update sngrep to any version newer than 1.8.4 that includes this fix. As a network-level workaround, deploy SIP-aware firewalls or intrusion prevention systems configured to drop SIP packets with header fields exceeding 255 bytes, and restrict HEP/EEP listener access to trusted sources only. An openSUSE security update has also been issued (openSUSE Advisory, GitHub Commit).

The vulnerability was covered by The Hacker Wire, which published a dedicated article on the sngrep stack buffer overflow (The Hacker Wire). The openSUSE security team issued a distribution-level advisory, indicating downstream Linux distributions are actively patching the issue (openSUSE Advisory). Community reaction has been moderate given the niche but critical nature of sngrep in VoIP environments; the fix was credited to researcher TristanInSec for responsible disclosure.