Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-90558

  • Seven of today’s nine stories describe a fix that never reaches the running install

    Seven of today’s nine stories describe a fix that never reaches the running install

    The most important thing published today is not the day’s highest score. HAProxy CVE-2026-90678 is a 7.5, against a 9.8 for sngrep’s stack overflow. HAProxy outranks it on where it sits and on what a reader can do about it. A remote, unauthenticated HTTP/3 client can desynchronize reused backend connections, slip requests past a frontend deny rule, and swallow other users’ Authorization headers — at the edge, in front of everything behind it. And the fix is a commit, not a release: 3.3.14 and 3.4.4 are the newest builds on their maintained branches and both sit inside the affected range, which makes “update to the latest version,” the advice most coverage will give, wrong. sngrep’s 9.8 is real, but it is a terminal SIP viewer an operator points at traffic by hand, the blast radius is one workstation, and its fix is likewise a commit on master that no tagged release and no Debian package carries.

    There is a thread, and it is the day’s actual story. In seven of the nine stories published today, a fix exists somewhere other than in something you can install. HAProxy’s and sngrep’s are commits. snappy-java’s 7.5 out-of-bounds write has no fix at all — the newest artifact on Maven Central was published in July 2025 and is the top of the affected range. LangBot 4.10.11 generates its new recovery key only when none exists, so upgrading leaves an existing installation holding the 24-bit secret the release was cut to replace. ESPnet’s patched release raises an error below PyTorch 2.6 while its own metadata still declares torch>=2.3.1, so an install that satisfies the declared dependencies gets a fixed path that throws and unfixed paths that run. Nodemailer’s denial of service was introduced by the security fix in 9.1.0 and repaired only in 10.x, so a 9.x user has to cross a major version to escape it. And Really Simple Security’s fix has been auto-updating to three million sites since September 1 under a changelog line that reads like a display bug: the code arrived, the reason to care did not.

    Order of business behind HAProxy. LangBot next, because the reset endpoint is unauthenticated and the remedy is a key rotation by hand that the upgrade will not perform for you. Then ESPnet and Nodemailer, both dependency audits rather than emergencies. Really Simple Security mostly needs confirmation that auto-update ran. snappy-java is availability-only and lands on the one decompression call that makes the caller size its own output buffer. Two records close the day: Flowise’s cross-workspace credential flaw, patched in July and given CVE IDs on Friday, six weeks later and by a third-party CNA rather than the vendor; and Internet Download Manager’s kernel driver, where a public proof of concept turns idmwfp.sys into an arbitrary registry write for any logged-in user and the vendor, by the CVE record’s account, has not responded.

    Still open at the end of the day. Two federal deadlines come due tomorrow: NVD’s records for ConnectWise ScreenConnect CVE-2026-84869 and GitLab CVE-2026-85706 both carry a cisaActionDue of 2026-09-14, Monday, September 14, 2026. Tonec has said nothing about the IDM driver, so there is no patch to wait for. snappy-java has shipped no release in more than a year. And Flowise is the day’s inverse case, worth keeping in view: the code was fixed on time, and the record took six weeks to say so.

  • sngrep’s 9.8 stack overflow is fixed in master and in no release, and Debian’s newest package is the top of the affected range

    sngrep’s 9.8 stack overflow is fixed in master and in no release, and Debian’s newest package is the top of the affected range

    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.