← Back to Feed CACHED · 2026-09-20 12:31:50 · CACHE_KEY CVE-2026-90779
CVE-2026-90779 · CWE-121 · Disclosed 2026-09-13

SIPp through 3.7.7 contains a stack buffer overflow vulnerability in createAuthHeader

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Stack overflow in a SIP testing tool — crashes your benchmark, not your PBX"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker operates a malicious SIP server

The attacker must control a SIP endpoint (registrar, proxy, or B2BUA) that SIPp will be directed to test against. Alternatively, the attacker could compromise an existing SIP test target on the internal network. The server must be capable of returning crafted SIP 401 or 407 authentication challenge responses.
Conditions required:
  • Attacker controls or has compromised a SIP server that the target SIPp instance will connect to
Where this breaks in practice:
  • 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
STEP 02

SIPp initiates a test session to the malicious server

A human operator or CI script launches SIPp with a scenario that triggers SIP authentication. SIPp sends an INVITE or REGISTER, and the malicious server responds with a 401/407 challenge. This requires the SIPp test to be actively running — SIPp is not a persistent daemon, it runs for the duration of a test.
Conditions required:
  • SIPp must be actively running a test scenario that involves authentication against the attacker-controlled server
  • The SIPp scenario XML must include [authentication] handling
Where this breaks in practice:
  • 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
Detection/coverage: Network IDS rules can flag 401/407 responses with abnormally long algorithm fields (>32 bytes) on SIP ports (5060/5061)
STEP 03

Malicious 401/407 triggers stack buffer overflow

The crafted authentication challenge contains an oversized 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().
Conditions required:
  • SIPp binary was compiled without stack canaries or has them but the overflow is large enough to be useful
Where this breaks in practice:
  • Modern Linux distros compile with -fstack-protector-strong by 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
Detection/coverage: Stack canary violations generate SIGABRT and may produce core dumps or syslog entries; ASAN-instrumented builds will catch this immediately
STEP 04

SIPp process crashes (DoS)

The SIPp client process terminates. The load test or functional test that was running is interrupted. No production SIP service is affected because SIPp is a test traffic generator, not a call-processing element. The operator restarts SIPp or investigates the crash.
Conditions required:
  • SIPp must have been doing something the operator cares about — otherwise the crash is a non-event
Where this breaks in practice:
  • 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
Detection/coverage: Process crash is immediately visible to the test operator via SIPp's own console output and exit code
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. No reports from CISA, Mandiant, CrowdStrike, or any threat intel feed. Not listed in CISA KEV.
Proof-of-ConceptNo 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 Score0.00565 (0.565%) — 54th percentile. Below the threshold where EPSS-based prioritization frameworks flag for attention.
KEV StatusNot listed. No CISA KEV entry. No CISA alert or ICS advisory.
CVSS VectorCVSS: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 VersionsSIPp 0.x through 3.7.7 (all releases ever published). The createAuthHeader() function has carried this flaw since authentication support was introduced.
Fixed VersionNo 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 / ScanningSIPp 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 Date2026-09-13 — one week ago as of this assessment.
ReporterReported via VulnCheck initial triage. No named researcher credited in public advisories.
04 · The Call

Final Verdict
DOWNGRADED to LOW (3.0/10)

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.