Like finding a safety recall on a crash-test dummy
CVE-2026-90779 is a stack-based buffer overflow in SIPp's createAuthHeader() function, specifically in the getAuthParameter() helper that parses SIP authentication challenges (401/407 responses). When a SIP server returns an oversized or malformed algorithm parameter, the function copies it into a fixed 32-byte algo buffer without adequate bounds checking, corrupting the stack and crashing the SIPp client process. All versions through 3.7.7 are affected — and 3.7.7 is the latest release as of this writing. A fix exists in PR #880 but has not been cut into a release.
The vendor CVSS of 7.5 HIGH is technically defensible against the CVSS 3.1 rubric — it is network-reachable, no-auth, no-interaction, high-availability-impact. But this score catastrophically misrepresents real-world risk because it ignores what SIPp actually is: a SIP protocol *testing and benchmarking tool*, not production telephony infrastructure. SIPp is the thing you point at your PBX during a maintenance window to see if it can handle 10,000 concurrent calls. Crashing SIPp means your load test aborts. No production calls drop. No voicemail queues stall. No 911 service degrades. The CVSS score treats SIPp as though it were Oracleʼs SBC or a Cisco CUBE — it is not, and the vendor HIGH label is dramatically overblown for any enterprise patching queue.
4 steps from start to impact.
Attacker operates a malicious SIP server
- Attacker controls or has compromised a SIP server that the target SIPp instance will connect to
- SIPp is typically pointed at internal, org-controlled SIP infrastructure — testers do not benchmark random Internet SIP servers
- Compromising the SIP test target first requires a separate, unrelated exploit chain
SIPp initiates a test session to the malicious server
- SIPp must be actively running a test scenario that involves authentication against the attacker-controlled server
- The SIPp scenario XML must include
[authentication]handling
- SIPp runs transiently — minutes to hours during test windows, not 24/7
- Many SIPp test scenarios skip authentication entirely (unauthenticated load generation is the primary use case)
- The window of exploitation is limited to the test execution period
Malicious 401/407 triggers stack buffer overflow
algorithm parameter. getAuthParameter() copies this value into a 32-byte stack buffer (char algo[32]) without proper length enforcement across all parsing paths. The overflow corrupts the stack frame of createAuthHeader().- SIPp binary was compiled without stack canaries or has them but the overflow is large enough to be useful
- Modern Linux distros compile with
-fstack-protector-strongby default — most distro-packaged SIPp binaries will have stack canaries that turn this into a clean abort rather than exploitable corruption - ASLR and NX further reduce any theoretical RCE pathway
- The vendor CVSS vector explicitly scores C:N/I:N — even the vendor does not claim RCE
SIPp process crashes (DoS)
- SIPp must have been doing something the operator cares about — otherwise the crash is a non-event
- Impact is limited to the test run itself — production telephony continues uninterrupted
- The operator can immediately restart SIPp and avoid the malicious server
- No data exfiltration, no lateral movement, no persistence
The supporting signals.
| In-the-Wild Exploitation | None observed. No reports from CISA, Mandiant, CrowdStrike, or any threat intel feed. Not listed in CISA KEV. |
|---|---|
| Proof-of-Concept | No public PoC found. The vulnerability description and PR #880 provide enough detail to craft a malicious 401/407 response, but no weaponized exploit code is circulating. Trivial to reproduce with a Python SIP server script. |
| EPSS Score | 0.00565 (0.565%) — 54th percentile. Below the threshold where EPSS-based prioritization frameworks flag for attention. |
| KEV Status | Not listed. No CISA KEV entry. No CISA alert or ICS advisory. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — The vector is technically valid but misleading: AV:N describes the SIP transport, but the *victim* (SIPp) must initiate the connection to the attacker. No confidentiality or integrity impact — vendor explicitly scopes this as DoS only. |
| Affected Versions | SIPp 0.x through 3.7.7 (all releases ever published). The createAuthHeader() function has carried this flaw since authentication support was introduced. |
| Fixed Version | No release available. Fix is in PR #880 on GitHub but no 3.7.8 tag exists. Defenders must build from source (master branch post-PR-merge) or apply the patch manually. |
| Exposure / Scanning | SIPp is a client-side testing tool — it does not listen on a port by default (UAC mode). Shodan/Censys/GreyNoise scans are irrelevant; you cannot scan the Internet for vulnerable SIPp instances. UAS mode listens on 5060 but is also a testing configuration. |
| Disclosure Date | 2026-09-13 — one week ago as of this assessment. |
| Reporter | Reported via VulnCheck initial triage. No named researcher credited in public advisories. |
Why this verdict
- SIPp is a testing tool, not production infrastructure. This is the dominant factor. SIPp is a SIP traffic generator used for load testing and functional testing. It is not a PBX, SBC, proxy, or any component in the production call path. Crashing SIPp interrupts a benchmark — it does not drop calls, degrade 911 service, or affect any production system. This alone invalidates the operational severity implied by a 7.5.
- Client-initiated connection model. The CVSS AV:N is technically correct but practically misleading. SIPp must actively connect to the malicious server — an attacker cannot spray this at targets. The victim organization controls which servers SIPp talks to, and those are almost universally internal, org-owned SIP infrastructure.
- DoS-only impact with modern mitigations against RCE. The vendor explicitly scores C:N/I:N, scoping this to availability. Stack canaries (
-fstack-protector-strong), ASLR, and NX on modern Linux distributions further ensure that the stack corruption results in a clean crash, not code execution. Even the theoretical worst case (RCE) would execute code in the context of a test tool process, not a privileged service. - Role multiplier: SIPp does not occupy any high-value deployment role. It is not an identity provider, hypervisor, CI/CD runner, backup system, database engine, network edge appliance, or security agent. Its canonical deployment role is (a) low-value: developer workstation, QA lab, or test VM. In rare cases it may run in a CI pipeline for SIP integration tests, but even there the blast radius of a crash is a failed CI job — not a supply-chain compromise. The high-value role floor does not apply because SIPp is not a component whose compromise cascades to domain, fleet, or supply-chain scope.
- No exploitation pressure. Zero in-the-wild exploitation, no public PoC, EPSS at 0.565%, not on KEV. There is no urgency signal from any threat intelligence source.
- Transient attack surface. SIPp runs for the duration of a test (minutes to hours), not as a persistent service. The window during which the vulnerability is reachable is a fraction of the host's uptime.
Why not higher?
SIPp is not production infrastructure and does not appear in any high-value role catalog. There is no path from crashing SIPp to compromising production telephony, exfiltrating data, or pivoting laterally. The DoS impact is confined to a test process that the operator intentionally started and can immediately restart. No exploitation evidence, no PoC, and sub-1% EPSS provide zero urgency signal. Elevating this above LOW would misallocate patching resources away from vulnerabilities that actually threaten production systems.
Why not lower?
Despite being a testing tool, the vulnerability is real, trivially triggerable by any SIP server SIPp connects to, and affects every version ever released with no patched release available yet. An IGNORE verdict would be appropriate only if SIPp were fully deprecated or if the flaw were unexploitable; neither is the case. In environments where SIPp runs in CI pipelines with authentication scenarios against semi-trusted infrastructure, a crash could mask test results or cause pipeline flakiness. LOW acknowledges the flaw exists and should be tracked as backlog hygiene.
What to do — in priority order.
- Only run SIPp against org-controlled SIP infrastructure — SIPp should never be pointed at untrusted or Internet-facing SIP servers for testing. This is already standard practice in virtually all enterprises and eliminates the attack vector entirely. No SLA pressure — this is a LOW finding — but confirm this practice in your SIP testing runbooks as part of backlog hygiene.
- Apply PR #880 patch from source if you build SIPp internally — If your organization builds SIPp from the GitHub master branch, cherry-pick the fix from PR #880. This bounds the
getAuthParameter()copy to the buffer size. No mitigation SLA applies for LOW severity — treat as backlog hygiene. - Use ASAN or stack-canary-enabled builds for SIPp in CI — Compile SIPp with AddressSanitizer (
-fsanitize=address) or ensure your distro package includes-fstack-protector-strong. This converts any stack overflow into a clean, detectable abort rather than undefined behavior. Useful regardless of this specific CVE. - Monitor for SIPp process crashes in automated test pipelines — If SIPp is invoked in CI/CD, ensure the pipeline treats a non-zero exit code as a test failure and alerts the team. This provides immediate visibility if the bug is ever triggered, whether by this CVE or any other crash.
- WAF or SIP-aware firewall in front of SIPp — SIPp is the *client*, not the server. Traffic filtering on inbound SIP is irrelevant because the malicious payload arrives as a *response* to SIPp's outbound request, traversing the return path of an established connection.
- Upgrading to SIPp 3.7.8 — This version does not exist yet. The fix is only in an unmerged PR. Do not wait for a release that has no scheduled date; apply the source patch if needed.
- Network segmentation of the SIPp host — While generally good practice, segmentation does not help here because SIPp must reach the SIP server it is testing. The attack vector is the test traffic itself, not lateral movement to the SIPp host.
Crowdsourced verification payload.
Run this on any host where SIPp may be installed. Execute as any user with read access to the sipp binary. Example: bash check_cve_2026_90779.sh or bash check_cve_2026_90779.sh /usr/local/bin/sipp if the binary is in a non-standard location.
#!/usr/bin/env bash
# CVE-2026-90779 checker — SIPp createAuthHeader stack buffer overflow
# Checks installed SIPp version against affected range (<= 3.7.7)
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -euo pipefail
SIPP_BIN="${1:-$(command -v sipp 2>/dev/null || true)}"
if [[ -z "$SIPP_BIN" ]]; then
echo "UNKNOWN — sipp binary not found in PATH. Supply path as argument."
exit 2
fi
if [[ ! -x "$SIPP_BIN" ]]; then
echo "UNKNOWN — $SIPP_BIN is not executable."
exit 2
fi
# SIPp prints version with -v flag; output format: "SIPp v3.7.7-..."
VERSION_OUTPUT=$($SIPP_BIN -v 2>&1 || true)
VERSION=$(echo "$VERSION_OUTPUT" | grep -oP 'v\K[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — could not parse version from: $VERSION_OUTPUT"
exit 2
fi
echo "Detected SIPp version: $VERSION"
# Compare version — affected: <= 3.7.7
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
if (( MAJOR < 3 )) || \
(( MAJOR == 3 && MINOR < 7 )) || \
(( MAJOR == 3 && MINOR == 7 && PATCH <= 7 )); then
echo "VULNERABLE — SIPp $VERSION is affected by CVE-2026-90779 (createAuthHeader stack buffer overflow)."
echo "Note: No patched release exists yet. Apply PR #880 from https://github.com/SIPp/sipp/pull/880"
exit 0
else
echo "PATCHED — SIPp $VERSION is above the affected range (through 3.7.7)."
exit 1
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.