A stack buffer overflow reachable from any SIP packet sngrep renders carries a 9.8, the patch exists as a commit on master, and no tagged release or distribution package contains it.
What happened
On September 12, 2026, at 6:16 p.m. UTC, VulnCheck published CVE-2026-90558 against sngrep, the terminal SIP packet viewer maintained by Irontec and used by most people who debug voice infrastructure for a living. The record carries a CVSS v3.1 base score of 9.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, a CVSS v4.0 score of 9.3, and CWE-121, stack-based buffer overflow. Both scores come from [email protected]. There is no score from the project.
The description reads: “sngrep through 1.8.4 contains stack buffer overflow vulnerabilities in SIP attribute formatting routines when header values exceed the 255-byte buffer limit. Attackers can craft malicious SIP packets with oversized Call-ID, X-Call-ID, or other header fields to overflow stack buffers and cause crashes or execute arbitrary code during packet parsing and rendering.” VulnCheck’s advisory credits Tristan Madani.
The affected range in the NVD record runs from version 0 through 1.8.4. There is no versionEndExcluding, no fixed version named anywhere in the record, and no release tag in the reference list — there is a commit.
That commit is 1ff74ee3ab5ff280e8ba976aa8c744dca57eb35b, authored by the project’s maintainer, Ivan Alonso. Its message is unusually precise about reachability, and worth reproducing: “call_get_attribute() formatted the Call-ID, X-Call-ID and Reason header text with an unbounded sprintf(“%s”). Call-ID/X-Call-ID can hold up to MAX_CALLID_SIZE/MAX_XCALLID_SIZE (1023 bytes) and Reason text is copied from the raw payload (up to MAX_SIP_PAYLOAD), while all callers pass a 255-byte SIP_ATTR_MAXLEN stack buffer (call list rendering, sort compare). A SIP message with a long Call-ID, X-Call-ID or Reason header overflowed the stack, triggerable via pcap, live capture or HEP/EEP remote capture.”
The change is seven added and seven removed lines across src/sip_call.c and src/sip_msg.c. We read both files at the v1.8.4 tag and at master. At 1.8.4, src/sip_call.c writes the Call-ID with sprintf(value, "%s", call->callid), and the X-Call-ID and Reason text the same way. On master, those three lines read sprintf(value, "%.*s", SIP_ATTR_MAXLEN - 1, ...). src/sip_attr.h defines SIP_ATTR_MAXLEN as 255; src/sip.h defines MAX_CALLID_SIZE and MAX_XCALLID_SIZE as 1024 and MAX_SIP_PAYLOAD as 10240.
The second half of the commit is a separate defect. At 1.8.4, src/sip_msg.c already used the bounded form, but passed SIP_ATTR_MAXLEN as the precision rather than SIP_ATTR_MAXLEN - 1 — 255 characters plus a terminator into a 255-byte buffer. Master corrects that on four calls. The code that looked guarded was off by one byte; the code that looked unguarded was off by up to 768.
Now the part that decides what a reader can do. configure.ac on master still reads AC_INIT([sngrep], [1.8.4], ...) — not bumped since the fix landed — and the ChangeLog has no entry after “2026-07-24 Ivan Alonso — sngrep 1.8.4 released.” There is no 1.8.5.
Debian carries 1.8.2-1 in stable and 1.8.4-1 in testing and unstable, the latter accepted into unstable on July 30, 2026, and migrated to testing on August 4, 2026. Every one of those is inside the affected range, because the range starts at zero. The newest sngrep any mainstream distribution ships is the ceiling of the range, not above it.
sngrep is not in CISA’s Known Exploited Vulnerabilities catalog, whose current published version is 2026.09.11, and no exploitation has been reported. The NVD record carries no cisaExploitAdd or cisaActionDue field.
Why it matters
The 1.8.4 release is the ceiling of this affected range, and 1.8.4’s own changelog contains the line “sip: fix stack buffer overflow on non-numeric Warning header.” Seven weeks ago the project fixed a stack buffer overflow in SIP header handling. The release that shipped that fix is the top of the affected range for a second stack buffer overflow in SIP header handling, in adjacent functions, found by looking at the same class of formatting call. That is not a criticism of the maintainer, who fixed this one quickly and documented it better than most vendors document anything. It is an observation about how these audits go: when one sprintf in a family gets bounded, someone eventually reads the rest of the family.
What makes the 9.8 defensible is where the input comes from. sngrep is not a service, so the instinct is to file this under “local tool, low priority.” The commit message names three paths, and two of them do not require the operator to do anything unusual. Live capture is the ordinary way sngrep is used: an engineer runs it on a session border controller or a PBX and watches signaling go by. Anyone who can put a SIP message on a monitored interface — for a public-facing SIP service, anyone on the internet — supplies the Call-ID. The overflow then happens during call list rendering and during sort comparison, meaning it fires as the operator looks at the screen, not as a result of any decision the operator makes about the packet.
The third path is the one to check tonight. sngrep can act as an EEP/HEP capture server, receiving signaling from remote agents. In src/setting.c, eep.listen defaults to off — but when it is turned on, eep.listen.address defaults to 0.0.0.0, eep.listen.port to 9060, and eep.listen.pass to the empty string. A shop that enabled remote capture during a troubleshooting session and left it on has a UDP listener on every interface, with no password unless someone set one, feeding attacker-controlled header text straight into the formatting routines this CVE describes.
Then there is the privilege question the CVSS vector does not capture. Packet capture needs elevated rights, and the path of least resistance is sudo sngrep. A stack overflow in a root process on the same host as the telephony stack it is debugging is a different outcome than the same overflow in an unprivileged viewer. The score asserts C:H/I:H/A:H on the assumption that code execution is achievable; whether it is, on a toolchain with stack protector and FORTIFY_SOURCE, VulnCheck does not demonstrate and we will not assert. What is certain is the crash, and it happens in the tool you were using to find out what was wrong.
The shape of this record is one this publication has now seen four times in four days: a real fix exists in version control, the CVE’s affected range ends at the last release because there is nothing later to point at, and every scanner that resolves version numbers against that range will keep reporting the newest available build as vulnerable, correctly. HAProxy’s HTTP/3 smuggling fix, covered here this morning, has the same structure. The difference is that HAProxy ships releases on a schedule measured in weeks. sngrep’s last two releases were eleven months apart. “Wait for the next release” is not a remediation timeline here; it is a hope.
What to do
There is no version to upgrade to. The options are to build from master, which contains commit 1ff74ee3ab5ff280e8ba976aa8c744dca57eb35b, or to apply that seven-line change to whatever source your distribution packages. Both touched functions, call_get_attribute() in src/sip_call.c and msg_get_attribute() in src/sip_msg.c, are small and the change is mechanical: bound the writes with %.*s and SIP_ATTR_MAXLEN - 1.
Until then, check eep.listen in your sngrep configuration, which lives in ~/.sngreprc or /etc/sngreprc. If it is on and you are not actively using remote capture, turn it off. If you are, set eep.listen.pass to something, and bind eep.listen.address to a management interface rather than 0.0.0.0.
Treat pcap files from outside your organization as untrusted input; sngrep begins rendering the call list as soon as it opens one. A capture emailed by a carrier or a customer to help diagnose a problem is exactly the delivery vehicle this flaw wants.
Stop running sngrep as root where you can. Granting CAP_NET_RAW and CAP_NET_ADMIN to the binary, or capturing to a file with a minimal tool and viewing it as an unprivileged user, removes the worst version of this outcome without waiting for anyone.
Finally, if a scanner reports sngrep 1.8.4 as vulnerable and someone is about to mark it a false positive because 1.8.4 is the latest release: it is not one. That is the correct answer to the question the scanner was asked.
Sourcing note
Checked: the NVD record for CVE-2026-90558, which supplied the description, both CVSS vectors and their source, CWE-121, the affected range, and the reference list; VulnCheck’s advisory, which supplied the researcher credit; the sngrep repository’s shipped source at the v1.8.4 tag and at master, read directly via raw.githubusercontent.com, which is how the sprintf calls before and after, the value of SIP_ATTR_MAXLEN, the eep.listen defaults in src/setting.c, the unchanged version string in configure.ac, and the ChangeLog entries were confirmed rather than taken on description; and the Debian package tracker for the packaged versions. The KEV catalog was read from the cisagov/kev-data mirror on GitHub, because cisa.gov returns 403 to automated fetching; the catalog version read was 2026.09.11 and sngrep does not appear in it.
Could not reach: GitHub’s commit-listing and tag pages, which are disallowed to automated fetching by robots.txt, so the calendar date the fix commit landed is not established here — only that it is present on master and absent from v1.8.4.
Unresolved: whether the overflow is exploitable beyond a crash on a distribution build with stack protector and FORTIFY_SOURCE enabled. VulnCheck’s 9.8 asserts confidentiality, integrity, and availability impact; the advisory does not show code execution, and the project has published no advisory of its own. Also unresolved: whether a 1.8.5 release is planned.