Someone found a way to crash your stress-test dummy, and the vendor scored it like it was your PBX
CVE-2026-90778 is a classic buffer overflow (CWE-120) in get_peer_tag() within SIPp, a free open-source SIP protocol testing and traffic generation tool. When SIPp parses a SIP To header whose tag= parameter is 2,049 bytes or longer, a static buffer is overrun and the process crashes. All versions through 3.7.7 are affected. The fix landed in commit ddf22d1 and is included in SIPp 3.7.8. The impact is strictly denial of service — the overflow crashes the process but does not yield code execution.
The vendor CVSS of 7.5 HIGH is technically accurate *for the mechanics*: unauthenticated, network-reachable, low complexity, full availability impact. But CVSS is context-blind. SIPp is not a production SIP proxy, PBX, or session border controller — it is a test harness engineers spin up in labs and CI pipelines to stress-test real VoIP infrastructure. Scoring it the same as a DoS in Oraclecommunications SBC or Oraclecommunications SBC or Oraclecommunications or Oraclecommunications or Kamailio or Asterisk massively overstates the operational risk. The real-world severity is LOW.
3 steps from start to impact.
Identify a reachable SIPp instance
- SIPp process is actively running a test scenario
- Attacker has network reachability to the SIPp listener port
- SIPp is a testing tool; instances are overwhelmingly on internal lab networks or developer workstations, not internet-facing
- SIPp runs only during active test sessions — often minutes to hours — not 24/7
- Enterprise firewalls and network segmentation typically isolate test/lab VLANs from untrusted networks
sipvicious) could fingerprint a SIPp User-Agent header if they reach the port.Send a crafted SIP message with an oversized tag
To: header contains a tag= parameter of 2,049+ bytes. No authentication is required; SIPp parses all incoming SIP messages without credential checks. The oversized tag value is copied into a fixed-size stack or static buffer inside get_peer_tag() without length validation.- Ability to send a raw SIP message to the target port
- No authentication or prior session required
- The payload is trivial to construct (just a long string), but the target must be reachable first — which is the real gate
- Most SIPp deployments are behind NAT or on isolated lab networks
SIPp process crashes
- The crafted message reaches the SIPp parser
- Impact is limited to a test process crash — no production traffic is affected
- The engineer simply restarts the test
- No evidence of code execution; modern stack protections (ASLR, stack canaries, NX) on typical Linux test hosts further limit escalation
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed in CISA KEV. No reports of active exploitation from any threat intelligence source. |
|---|---|
| Proof of Concept | No public PoC identified. The vulnerability is trivially reproducible (send a long tag= value in a SIP To header), but no named researcher has published a weaponized exploit or PoC script on GitHub, ExploitDB, or Sploitus. |
| EPSS Score | 0.00633 (0.63%) — bottom quartile. FIRST's model rates exploitation probability as very low within 30 days. |
| KEV Status | Not listed. No CISA KEV entry as of 2026-09-20. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — unauthenticated remote DoS, no confidentiality or integrity impact. CVSS 4.0 scored 8.7 by some sources but the delta is methodological, not contextual. |
| Affected Versions | SIPp ≤ 3.7.7 (all prior releases). The vulnerable function get_peer_tag() has existed since early versions of the SIP parser. |
| Fixed Version | SIPp 3.7.8 (commit ddf22d1, PR #879). NixOS tracking in nixpkgs#563484. |
| Scanning / Exposure | Near-zero internet exposure. SIPp is a CLI testing tool, not a production service. Shodan/Censys show no meaningful population of internet-facing SIPp instances. Contrast with Asterisk or Kamailio which have tens of thousands of exposed instances. |
| Disclosure Date | 2026-09-13 — published in NVD and vendor channels. |
| Reporter | Not attributed to a named researcher. Disclosed via the SIPp GitHub project. |
Why this verdict
- Deployment context is decisive: SIPp is explicitly a *SIP protocol testing and traffic generation tool*, not production telecom infrastructure. Its canonical deployment is a developer workstation, QA lab, or CI pipeline — environments with near-zero attacker exposure and near-zero blast radius on crash.
- Network reachability is the real gate: While the CVSS vector says AV:N (network), real-world SIPp instances sit on internal test VLANs, behind NAT, or on localhost. Internet-facing SIPp is an edge case so rare it does not register on Shodan or Censys.
- Impact ceiling is process crash of a test tool: The overflow produces DoS only — no code execution, no data leak, no lateral movement. Crashing a load-test binary means an engineer restarts their test. There is no production traffic disruption.
- Role multiplier: SIPp does not occupy any high-value deployment role. It is not an identity provider, hypervisor, edge appliance, database, backup system, CI/CD controller, or security agent. It is a test harness. Even in telecom organizations that use it heavily, it generates synthetic traffic — it does not carry real calls. The blast radius on crash is *local to a single test session* with zero domain/fleet/supply-chain/safety implications. No floor override applies.
- No exploitation pressure: EPSS 0.63%, no KEV listing, no public PoC, no observed campaigns. The vulnerability has been public for a week with zero attacker interest — consistent with the negligible value of crashing a test tool.
Why not higher?
Upgrading to MEDIUM would require either meaningful production impact or credible exploitation interest — neither exists. SIPp is not production infrastructure; crashing it disrupts a test, not a service. The EPSS score is bottom-quartile, there is no PoC, and no attacker has reason to target a load-testing binary when actual SIP infrastructure (Asterisk, Kamailio, FreeSWITCH) carries the real calls.
Why not lower?
IGNORE would be appropriate if the software were entirely deprecated or the bug were theoretical. The vulnerability is real, trivially triggerable if you can reach the port, and SIPp is still actively maintained and widely installed in telecom engineering environments. An internal attacker on a shared lab network could disrupt a colleague's testing. It deserves tracking as backlog hygiene, not complete dismissal.
What to do — in priority order.
- Update SIPp to 3.7.8 on your next maintenance cycle — The fix is a one-line bounds check in
get_peer_tag(). Since SIPp is a test tool with no production dependencies, updating carries near-zero regression risk. Treat this as backlog hygiene with no noisgate mitigation SLA — roll it into your next routine toolchain refresh. - Isolate SIPp test hosts on dedicated lab VLANs — If not already segmented, ensure SIPp instances run on test/lab networks that are unreachable from production and untrusted zones. This is standard practice and eliminates the remote attack vector entirely.
- Do not expose SIPp listeners to the internet — There is never a legitimate reason to bind SIPp to a public IP. If CI/CD pipelines run SIPp, ensure they use loopback or private interfaces only. Firewall rules should block inbound SIP ports (5060/5061) to test hosts from external sources.
- SIP-aware WAF/IPS in front of SIPp — overkill for a test tool, and most organizations don't deploy SIP inspection on lab networks. The right answer is network segmentation, not inline inspection of test traffic.
- Rate-limiting SIP traffic to SIPp — the crash is triggered by a single malformed message, not a flood. Rate limiting does not prevent exploitation.
Crowdsourced verification payload.
Run this on any host where SIPp is installed. No special privileges needed — it just checks the installed version. Example: bash check_sipp.sh
#!/usr/bin/env bash
# CVE-2026-90778 checker — SIPp get_peer_tag() buffer overflow
# Checks whether the installed SIPp version is <= 3.7.7 (vulnerable)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
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 outputs version info to stderr in most builds
RAW=$(sipp -v 2>&1 | head -5)
VERSION=$(echo "$RAW" | grep -oP '\d+\.\d+\.\d+' | head -1)
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — could not parse SIPp version from output"
echo "Raw output: $RAW"
exit 2
fi
IFS='.' read -r MAJ MIN PAT <<< "$VERSION"
if (( MAJ < VULN_MAJOR )) || \
{ (( MAJ == VULN_MAJOR )) && (( MIN < VULN_MINOR )); } || \
{ (( MAJ == VULN_MAJOR )) && (( MIN == VULN_MINOR )) && (( PAT <= VULN_PATCH )); }; then
echo "VULNERABLE — SIPp $VERSION is affected by CVE-2026-90778 (fixed in 3.7.8)"
exit 1
else
echo "PATCHED — SIPp $VERSION is not affected by CVE-2026-90778"
exit 0
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.