← Back to Feed CACHED · 2026-09-20 12:34:33 · CACHE_KEY CVE-2026-90780
CVE-2026-90780 · CWE-120 · Disclosed 2026-09-13

SIPp through 3.7.7 contains a buffer overflow vulnerability in the get_header

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

Someone found a way to crash your lab's SIP load-test harness by sending it a fat header

CVE-2026-90780 is a classic buffer overflow (CWE-120) in SIPp's get_header() function inside src/sip_parser.cpp. When the tool parses a SIP message whose header content exceeds 20,490 bytes, it overflows a static buffer and the process crashes. All SIPp versions from 3.4-beta1 through 3.7.7 are affected. The fix exists in upstream commits (8ddfb43 and 369b3c1) and PR #881, but no official v3.7.8 release has been cut yet — the latest tagged release remains v3.7.7.

The vendor CVSS 3.1 score of 7.5 HIGH is mechanically correct: network-reachable, no auth, low complexity, full availability impact. But it wildly overstates the real-world risk because it ignores *what SIPp actually is*. SIPp is a SIP protocol testing and load-generation tool — it is not an SBC, PBX, proxy, or any production VoIP component. It is run on demand by QA engineers in lab/staging networks to stress-test SIP infrastructure, then stopped. Crashing a SIPp process means a load test aborts. No production calls drop, no service degrades, no data leaks. The CVSS model has no field for 'nobody runs this in prod,' so the mechanical score lands at HIGH when reality is firmly LOW.

"DoS-only bug in a SIP testing tool that never runs in production — patch at leisure"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Identify a running SIPp instance

The attacker must locate a SIPp process actively listening for SIP traffic (UAS mode or bidirectional scenario). SIPp binds to a user-specified UDP/TCP port (default 5060) and advertises itself in the User-Agent header. The attacker needs network reachability to this port.
Conditions required:
  • SIPp is running in server (UAS) or bidirectional mode
  • Target port is network-reachable from the attacker's position
Where this breaks in practice:
  • SIPp is a test tool — instances are ephemeral, running minutes to hours during QA cycles, not 24/7 daemons
  • Almost never bound to an internet-routable address; typically on isolated lab VLANs or loopback
  • No enterprise asset-management system tracks SIPp instances because they aren't production assets
STEP 02

Craft an oversized SIP message

The attacker constructs a SIP INVITE (or any SIP request) with a single header whose value exceeds 20,490 bytes. This is trivial — a one-liner in Python or netcat can generate the payload. No special tooling is needed beyond knowledge of the SIP message format (RFC 3261).
Conditions required:
  • Knowledge that the target is SIPp (User-Agent banner)
  • Ability to send raw UDP/TCP to the listening port
Where this breaks in practice:
  • Crafting the payload is trivial, so no friction here — but the target must be reachable first
STEP 03

SIPp crashes — test run aborts

The oversized header overflows the static buffer in get_header(), corrupting memory and causing the SIPp process to segfault. The impact is pure denial of service — the CVSS vector explicitly confirms C:N/I:N/A:H. There is no evidence of code execution; the overflow target is a stack/static buffer that crashes rather than redirects control flow. The QA engineer restarts SIPp and reruns the test.
Conditions required:
  • SIPp successfully receives and begins parsing the message
Where this breaks in practice:
  • The only 'impact' is a test engineer's terminal printing a segfault — no production service is affected
  • Modern distros with ASLR and stack canaries make RCE from this overflow class extremely unlikely even if someone tried
Detection/coverage: Process monitoring (if any) would see the crash; no CVE-specific scanner signatures exist because the tool is not in vulnerability-management scope for most orgs
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. No campaigns, no threat-actor usage, no CISA KEV listing. This is a test tool — there is nothing to exploit for profit.
Proof-of-ConceptNo public PoC repository found. The trigger is trivial (send >20,490 bytes in a SIP header), but nobody has bothered to package one because the payoff is crashing a QA tool.
EPSS Score0.00633 (~0.6th percentile) — bottom of the barrel. FIRST's model agrees this is not going to be exploited.
KEV StatusNot listed. No federal mandate to patch.
CVSS v3.1 VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — 7.5 HIGH. Note the C:N/I:N: purely availability impact, no data at risk.
CVSS v4.0 VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N — 8.7 HIGH. V4 inflates further due to scoring mechanics.
Affected VersionsSIPp 3.4-beta1 through 3.7.7 (all released versions).
Fixed VersionNo official release yet. Commits 8ddfb43 and 369b3c1 fix the issue; PR #881 is merged. NixOS has a backport PR. A future v3.7.8 will carry the fix.
Internet ExposureEffectively zero. SIPp is not indexed by Shodan/Censys as a production service class. It is a CLI test harness, not a deployed network service.
Disclosure / ReporterDisclosed 2026-09-13. Advisory published via VulnCheck. Researcher not publicly named.
04 · The Call

Final Verdict
DOWNGRADED to LOW (2.5/10)

Why this verdict

  • Not production software: SIPp is a SIP protocol *testing and load-generation tool*. It is not an SBC, PBX, proxy, or any component that carries production traffic. Crashing it interrupts a test run, not a service. This single fact dominates the assessment.
  • DoS-only impact, no RCE: The CVSS vector is C:N/I:N/A:H. There is no confidentiality or integrity impact. Even the availability impact is against a test process, not a production service. ASLR and stack canaries on modern Linux make escalation to code execution implausible.
  • No internet exposure: SIPp instances are ephemeral processes on lab VLANs or developer workstations. They are not persistent daemons, not internet-facing, and not tracked by asset-management tools. The network-reachable premise in the CVSS vector almost never holds outside the attacker being on the same test network.
  • Role multiplier: SIPp occupies *only* the low-value role (dev workstation, QA lab, CI test runner). It has zero presence in any high-value role category — it is not an identity system, hypervisor, backup, database, network edge appliance, CI/CD artifact store, or OT controller. The blast radius of a successful exploit is: *one test run restarts*. No floor elevation applies.
  • No exploitation pressure: EPSS is 0.6%, no KEV listing, no known campaigns, no public PoC. Nobody is weaponizing a crash bug in a QA tool.

Why not higher?

A MEDIUM or higher rating would imply the vulnerability poses meaningful operational risk to enterprise infrastructure. SIPp is not production infrastructure — it is a developer testing utility. The DoS impact lands on a test process, not a service with uptime requirements. There are no high-value deployment roles that would trigger a floor elevation. Even if an attacker could reach a running instance (unlikely), the payoff is restarting a test.

Why not lower?

An IGNORE rating would mean no action is needed at all. While SIPp is a test tool, it *is* present in enterprise environments (VoIP teams use it regularly), and a deliberate crash during an important capacity-planning test could cause schedule disruption. The fix exists and is low-effort to apply (rebuild from source with the patched commit). Acknowledging the CVE and patching on a backlog cadence is appropriate hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Isolate SIPp to dedicated test VLANs — SIPp should never listen on a routable production network segment. Ensure test/lab networks are firewalled from production and from the internet. This is standard practice and eliminates remote attack surface entirely. No mitigation SLA applies for a LOW verdict — treat as backlog hygiene.
  2. Build from patched source when convenient — Cherry-pick commits 8ddfb43 or 369b3c1 (or pull from HEAD after PR #881 merged) and rebuild. If you use NixOS, the backport PR #563981 carries the fix. Under the noisgate remediation SLA for LOW, this is backlog work — no hard deadline, but next time you rebuild your test toolchain is a fine time.
  3. Cap SIP message size at the SBC or test proxy — If your test topology routes traffic through an SBC or SIP proxy before it hits SIPp, configure a max-message-size policy (20 KB is a safe ceiling for any legitimate SIP message per RFC 3261 §18.1.1). This prevents the oversized header from ever reaching SIPp.
What doesn't work
  • WAF / IDS signatures — SIPp traffic is UDP/TCP on port 5060, not HTTP. Web application firewalls have no visibility into SIP message structure and cannot inspect or block oversized SIP headers.
  • Endpoint Detection and Response (EDR) — EDR may detect the crash post-facto but cannot prevent the malformed SIP message from arriving. The process is already dead by the time EDR logs the segfault.
  • Upgrading to v3.7.8 — as of 2026-09-20, v3.7.8 has not been officially released. The fix exists only in merged commits on the main branch. You must build from source or use a distro backport.
06 · Verification

Crowdsourced verification payload.

Run this script on any host where SIPp is installed (the test/lab machine, not a production server). Execute as a normal user: bash check_sipp_cve_2026_90780.sh. No elevated privileges required — it only checks the installed version.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_sipp_cve_2026_90780.sh
# Checks whether the installed SIPp version is vulnerable to CVE-2026-90780
# (buffer overflow in get_header() for headers > 20,490 bytes).
# Affected: all versions <= 3.7.7
# Fixed: commits 8ddfb43 / 369b3c1 (no official release yet as of 2026-09-20)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

VULN_MAJOR=3
VULN_MINOR=7
VULN_PATCH=7

if ! command -v sipp &>/dev/null; then
  echo "UNKNOWN — sipp binary not found in PATH."
  exit 2
fi

# sipp -v prints version to stderr in most builds
RAW_VERSION=$(sipp -v 2>&1 || true)

# Try to extract version like "SIPp v3.7.7" or "SIPp 3.7.7"
VERSION=$(echo "$RAW_VERSION" | grep -oP '(?i)sipp\s+v?\K[0-9]+\.[0-9]+\.[0-9]+' | head -1)

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — could not parse SIPp version from output."
  echo "Raw output: $RAW_VERSION"
  exit 2
fi

IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

echo "Detected SIPp version: $VERSION"

# Compare: vulnerable if version <= 3.7.7
if (( MAJOR < VULN_MAJOR )); then
  echo "VULNERABLE — SIPp $VERSION is affected by CVE-2026-90780."
  exit 1
elif (( MAJOR == VULN_MAJOR && MINOR < VULN_MINOR )); then
  echo "VULNERABLE — SIPp $VERSION is affected by CVE-2026-90780."
  exit 1
elif (( MAJOR == VULN_MAJOR && MINOR == VULN_MINOR && PATCH <= VULN_PATCH )); then
  echo "VULNERABLE — SIPp $VERSION is affected by CVE-2026-90780."
  exit 1
else
  echo "PATCHED — SIPp $VERSION is newer than 3.7.7."
  exit 0
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.