CVE-2026-45537: What a CVSS 9.1 SIP Buffer Overflow Actually Means for Underwriters, CISOs, and Risk Managers

Severity: CRITICAL (CVSS v3.1: 9.1) · CWE-120 Buffer Overflow · Published to NVD 2026-08-04

When a critical-severity CVE lands in telecom infrastructure software, the instinct for most security teams is “patch everything now.” For underwriters and risk managers, the instinct should be different: separate what is severe from what is likely, and price the gap between the two. CVE-2026-45537 is a useful case study in exactly that discipline — a vulnerability whose technical severity and near-term exploitation probability point in opposite directions, and whose real-world impact depends almost entirely on deployment context: the version running in production, the routing script configuration, and whether the proxy is reachable from the public internet.

The Vulnerability in Plain Terms

CVE-2026-45537 is a critical global buffer overflow in OpenSIPS, an open-source Session Initiation Protocol (SIP) server used widely in telecommunications and VoIP infrastructure. SIP is the signaling protocol that sets up, modifies, and tears down voice and video sessions, which means an OpenSIPS deployment typically sits at the logical center of an operator’s voice traffic — handling registration, routing decisions, and session negotiation for every call the organization makes or receives. A flaw at this layer is not a peripheral application bug; it is a flaw in the control plane of the voice network.

The defect sits in the construct_uri() function, which concatenates multiple URI components (protocol, username, domain, port, params) into a fixed 1024-byte global BSS buffer without any bounds checking. In practical terms, the function joins several variable-length strings — several of which are supplied, directly or indirectly, by the requester — and writes the result into a fixed-size block of statically allocated memory. Nothing verifies that the combined length fits. It is the memory-safety equivalent of pouring a quart into a pint container and letting the overflow land wherever the process memory layout decides.

The exploitation path is correspondingly simple: a remote, unauthenticated attacker sends a SIP message containing a sufficiently long username. If a routing script passes that attacker-controlled username into construct_uri(), the combined components push past the 1024-byte boundary and overwrite adjacent global memory. No credentials are required, no prior foothold is needed, and no user on the victim side has to be tricked into anything — a single crafted request from anywhere that can reach the proxy is enough.

Two details elevate this above a generic overflow:

1. Deterministic state corruption, not a crash lottery. The overflow reliably corrupts disable_503_translation, a global flag controlling SIP 503 response handling. As SentinelOne notes, “Remote unauthenticated attackers can corrupt global server state and alter SIP routing behavior by sending crafted URI usernames, undermining the integrity and availability of OpenSIPS deployments.” An attacker who can alter how a SIP proxy routes and responds to traffic is an attacker positioned in the middle of the voice infrastructure — able to influence failover behavior, distort error signaling, and shape which upstream receives which traffic.

2. Silent collateral damage. The same 1024-byte buffer is shared with contact_builder(), which is silently corrupted on every request containing a long username when no memory sanitizer is deployed. Exploitation may leave no crash, no log entry, and no obvious artifact — the server keeps running with corrupted internal state. That combination is an incident-response and forensic problem of the worst kind, and it has direct consequences for detection and insurability, discussed below.

Affected versions: everything prior to 3.6.6 and prior to 4.0.0-rc1. Fixed in: 3.6.6 and 4.0.0-rc1, per the notcve.org record.

What Silent Corruption Means for Detection and Claims

Most vulnerability narratives assume a detectable event: a crash, a restart, a spike in error rates. CVE-2026-45537 violates that assumption. Because the overflow lands in global state and a shared buffer rather than a return address, the likely outcome is not a daemon dying but a daemon behaving subtly differently — SIP 503 handling flipped, contact headers assembled from corrupted memory, routing decisions drifting from configuration intent.

For security operations, this means standard detective controls underperform. Availability monitoring sees a healthy service. SIP error-rate dashboards may stay flat. The signal that remains — abnormally long usernames in request URIs — is cheap to alert on but rarely instrumented by default, which is why the response plan below calls it out explicitly.

For insurers, silent corruption changes the claims picture in three ways. First, the interval between compromise and discovery can stretch across weeks or months, so interruption losses accumulate before anyone files a notice. Second, root-cause attribution becomes genuinely difficult: routing anomalies without crash artifacts invite disputes over whether a loss event was a security incident or an operational failure. Third, toll-fraud losses that ride on corrupted routing can look like ordinary arbitrage until call detail records are examined forensically. None of this makes the risk uninsurable, but it does make detection capability a legitimate underwriting factor rather than a checkbox.

The CVSS 9.1 vs. EPSS Tension: Why Risk Teams Shouldn’t Panic-Price

This is where CVE-2026-45537 gets interesting for anyone whose job is quantified risk rather than vulnerability scanning:

• CVSS v3.1 base score: 9.1 (Critical) — driven by network attack vector, no privileges, no user interaction, and high integrity/availability impact (SentinelOne).
• EPSS exploit likelihood: under 1% in the first 30 days (notcve.org).
• CISA KEV: not listed. No confirmed in-the-wild exploitation.
• CISA SSVC decision: “Attend” — not “Act,” meaning remediation should be scheduled rather than treated as an emergency.
• Blast radius: only 2 NIST-validated CPEs, a narrow footprint relative to headline CVEs in browsers or VPN appliances.

Read these signals together rather than in isolation. CVSS answers “how bad if exploited”; EPSS answers “how likely to be exploited soon”; KEV answers “is it being exploited now”; SSVC synthesizes those inputs into a decision. A 9.1 with sub-1% EPSS, no KEV entry, and an “Attend” verdict is a conditional risk: catastrophic if exploited on an unpatched carrier-grade SIP proxy, but with low near-term exploitation probability — in part because OpenSIPS deployments are far scarcer than browser installs or edge appliances.

The CPE count deserves one caveat. Exposure management tooling that relies on CPE matching finds only what vendors have validated, and open-source SIP servers are frequently embedded in OEM platforms, PBX distributions, and session border controller products where the downstream vendor, not the upstream project, owns version identification. A two-CPE footprint therefore understates the true install base by an unknown margin — which is exactly the kind of uncertainty that should widen, not narrow, the loss distribution you model.

The catch — and the reason this cannot be filed under “ignore” — is that EPSS is a lagging indicator for niche infrastructure software. The model learns from public exploit code, threat-intel reporting, and KEV entries; before any of those exist, a niche CVE scores low almost by construction. Public exploit code for a deterministic, unauthenticated overflow in a telecom control plane could shift that probability quickly, and telecom targets are attractive to both state-aligned actors and toll-fraud crews. Prudent teams treat the EPSS score as a snapshot with wide error bars, not a verdict.

For Underwriters: What to Ask on Renewal

When assessing a policyholder’s telecom or UCaaS stack, CVE-2026-45537 supplies a concrete question set:

1. Do you run OpenSIPS, and at what version? Anything below 3.6.6 (or below 4.0.0-rc1 on the 4.x line) is exposed to a known, published, unauthenticated overflow. Ask about embedded instances too — the SIP engine inside a third-party PBX or session border controller may lag upstream releases by quarters.
2. Is the SIP proxy internet-facing? The attack requires no authentication, so exposure surface matters more than usual. A proxy restricted to peering interfaces and carrier VLANs is a different risk than one reachable from arbitrary source addresses.
3. Does your routing script pass user-controlled input to construct_uri()? Exploitation is conditional on script behavior, not just version. An insured who can answer this accurately demonstrates configuration management maturity; one who cannot is guessing.
4. Can you detect it? Given silent corruption of shared buffers, a policyholder who cannot demonstrate SIP anomaly detection, alerting on oversized URI fields, or sanitizer-instrumented test environments has a materially worse claims posture for “silent failure” scenarios — routing corruption that persists undetected for weeks.
5. What is the patch SLA for third-party open-source components? The interval between upstream disclosure and downstream deployment is where this class of loss lives.

Telecom and UCaaS insureds presenting unpatched, internet-facing OpenSIPS instances without compensating controls are the profile where this CVE justifies exclusions, sublimits, or premium adjustment. If you are working through placement with a broker, a structured broker scorecard keeps these questions attached to the submission rather than buried in the application narrative.

For CISOs and Risk Managers: A Sensible Response Plan

The SSVC “Attend” verdict supports a scheduled patch cycle rather than an emergency change window — but the schedule should be aggressive given the integrity impact:

• Patch to 3.6.6 or 4.0.0-rc1 as the primary control (notcve.org). If you operate a downstream product that embeds OpenSIPS, open a ticket with the vendor now; embedded copies will not appear in upstream release notes.
• Inventory your routing scripts. Exploitation requires a script that passes attacker-controlled usernames to construct_uri(). Knowing whether your configuration does this converts theoretical exposure into measured exposure — and in many deployments the answer will be “no,” which legitimately de-prioritizes this patch against competing demands.
• Validate with sanitizers. Because the overflow is silent without memory sanitization, run ASan or an equivalent on staging instances under production-like message loads to determine whether corruption has already occurred.
• Log and alert on long usernames. A cheap detective control: alert on SIP requests whose URI username field exceeds a sane threshold. It is the one reliable observable this vulnerability leaves behind.
• Verify your actual exposure. An external domain exposure review will surface SIP listeners inherited through acquisitions or shadow IT that never made it into the asset inventory.
• Track it formally. Record the finding in your risk register with an owner, a patch deadline, and a detection status, so it survives the next sprint cycle instead of living in a chat thread.

Quantifying It Instead of Gut-Feeling It

For risk managers who need to brief a board or an underwriter in dollars rather than CVSS decimals, model this as a single-loss-event scenario with low annualized frequency — consistent with, though not identical to, sub-1% EPSS, adjusted upward for internet-facing exposure and the absence of detection controls — and high magnitude loss. The magnitude components are concrete: corrupted routing on a telecom control plane translates into service outage measured against revenue per minute for voice traffic, toll fraud exposure while routing is distorted, regulatory exposure under NIS2 for EU telecom operators, and forensic costs for an incident that leaves no crash artifacts.

Running that scenario through a structured FAIR risk report or a fast cyber risk calculator converts “9.1 Critical, be scared” into a loss-exceedance range you can actually underwrite or budget against. If you are evaluating tooling for this kind of analysis, our comparison of cyber risk quantification tools and costs covers the practical trade-offs.

For EU telecom operators where SIP infrastructure falls in scope, fold patch status into the broader NIS2 compliance posture — an unpatched, known-critical in an essential entity’s control plane is precisely what supervisors ask about, and a structured NIS2 assessment gives you a documented answer rather than an ad hoc one.

Bottom Line

CVE-2026-45537 is a genuinely well-crafted vulnerability: unauthenticated, deterministic, silent, and sitting in the signaling layer that telecom depends on. But its risk profile is conditional — conditional on running OpenSIPS below 3.6.6, conditional on a vulnerable routing script, conditional on exposure, and currently low-probability per EPSS with no KEV listing.

For CISOs: patch on an aggressive-but-planned schedule, build the detective controls, and verify exposure rather than assuming it. For underwriters and risk managers: use it as a forcing function to ask telecom-stack questions you might otherwise skip, and to distinguish severity theater from quantified exposure. The organizations that manage cyber risk well are not the ones that react to every 9.1 — they are the ones that can explain, in numbers, why this one does or does not move their loss curve.

Sources

• CVE-2026-45537 - Global Buffer Overflow in construct_uri — notcve.org
• CVE-2026-45537: OpenSIPS Buffer Overflow Vulnerability — SentinelOne Vulnerability Database
• Discovery credited to “TristanInSec” per the notcve.org record
• NVD publication 2026-08-04, last updated 2026-08-05, per SentinelOne

Note: Several other CVEs circulating in threat feeds this week — notably CVE-2026-39980 and GHSA-36fr-4m54-94mj — relate to the OpenCTI platform and are unrelated to this OpenSIPS vulnerability. Do not conflate them in your tracking.