CVE-2026-9586: Sangoma Switchvox SQLi to RCE, Patch Now

CVE-2026-9586 is an unauthenticated SQL injection in Sangoma Switchvox SMB Edition that chains into remote code execution, no login, no session token, nothing but network access to the phone system. Sangoma fixed it in version 8.4.0.2 on July 14. Attackers started exploiting it on August 30. CISA added it to the Known Exploited Vulnerabilities catalog on September 2. If you run Switchvox and you’re still on 8.3, patch today, not this sprint.

What CVE-2026-9586 actually is

Switchvox ships an endpoint called /pa, short for phone auto-provisioning. Its job is boring and specific: when a Polycom IP phone boots up on the network, it phones home to /pa with an XML payload describing itself, and Switchvox uses that data to hand back the right configuration. It’s the kind of endpoint that exists purely for machine-to-machine bootstrapping, the sort of thing nobody thinks about once it’s working.

Here’s the problem. The endpoint checks whether the posted XML body’s root element is PolycomIPPhone, and if so, pulls out the PhoneIP value to use in a database lookup. That lookup runs against PostgreSQL. And the code that builds the query doesn’t use a parameterized statement or a prepared query, the standard, decades-old fix for exactly this class of bug. It concatenates the raw PhoneIP string straight into the SQL text.

That means anyone who can craft an XML body with a PolycomIPPhone root element, which requires no authentication because the whole point of the endpoint is to serve phones before they’ve authenticated anything, can put SQL syntax where an IP address is expected. The database executes it as part of the query. From there, per Horizon3.ai’s disclosure write-up, researchers demonstrated a path to arbitrary database read and write access and, ultimately, remote code execution on the underlying host. CVSS scored it 9.3 under the newer 4.0 methodology, which weighs “no privileges required, network-reachable, high impact to confidentiality/integrity/availability” about as harshly as the scoring system allows.

It’s a bug that’s almost old-fashioned in its simplicity. No auth bypass chain, no race condition, no memory corruption. Just a value that should have been bound as a parameter and instead got pasted into a string.

Who’s affected, and how to check

The vulnerable software is Sangoma Switchvox SMB Edition version 8.3. Switchvox is a VoIP phone system aimed at small and midsize businesses, sold as an appliance or virtual machine that a company runs on its own network, often facing the internet directly so remote employees and branch offices can register phones without a VPN.

Check your version in the Switchvox admin panel, under system information, or ask whoever manages the phone system for your office if that’s not you. If you’re anywhere on 8.3 and haven’t applied the update, you’re exposed. If you’re not sure whether your /pa endpoint is reachable from the open internet, that’s worth confirming independently of the patch status. Even patched, an exposed provisioning endpoint is more attack surface than it needs to be.

The exploitation timeline, and why the gap matters more than the bug

Here’s the part worth sitting with. Sangoma released the fix on July 14, 2026. Honeypot researchers first started seeing real exploitation attempts on August 30, six weeks later, according to Help Net Security’s reporting and a separate BleepingComputer writeup on the same activity. Attackers observed so far are dropping reverse shells and running commands to enumerate what’s running on the compromised host, standard early reconnaissance for a foothold, not yet a documented ransomware payload or data exfiltration campaign. That could change quickly once access is more widely traded.

Six weeks is not a fast turnaround for attackers by 2026 standards. It’s actually a fairly typical one for appliance-style software that isn’t getting patched the moment an update drops. A patch existing and a patch being installed are two different facts, and the gap between them is where nearly every KEV listing lives. We covered the same pattern with JFrog Artifactory’s admin bypass from the same September 2 CISA batch, where exploitation started three to four days after the fix shipped instead of six weeks. Switchvox’s slower timeline isn’t a sign the bug is less serious. If anything it says something about who runs VoIP appliances: IT teams stretched across a dozen priorities, phone systems that work and get left alone, patch windows that get scheduled around business hours because taking the phones down mid-shift has its own cost.

CISA’s KEV listing on September 2 grouped CVE-2026-9586 with six other actively exploited vulnerabilities that week. That wasn’t the only interesting bug in the batch, either. The Starlette Host-header bypass we covered separately landed in the same KEV update, along with a CVSS 10.0 auth bypass in Kestra OSS that’s arguably the more severe bug of the two, a reminder that CISA’s Tuesday-adjacent listings tend to arrive in clusters, not one at a time, and a single week’s KEV update is often worth a full pass through your own asset inventory rather than a check against one product.

For federal agencies, KEV listing isn’t advisory. Binding Operational Directive 22-01 sets a hard remediation deadline once a CVE lands in the catalog. Private organizations aren’t legally bound the same way, but treating a KEV entry as background noise is a mistake auditors and cyber insurers increasingly don’t let slide. An unpatched KEV-listed CVE sitting in a vulnerability scan is a specific, named finding now, not a generic “should probably patch this” line item.

What to do

Upgrade to Switchvox 8.4.0.2 or later. That’s the entire fix; Sangoma didn’t ship a workaround or a mitigation flag, because there isn’t a good partial fix for “the query concatenates untrusted input.” Parameterizing the query is the actual repair, and that only happens through the update.

If you can’t apply the patch within the next few hours for change-control reasons, don’t leave the endpoint open in the meantime. Restrict /pa to the internal network segment where your Polycom handsets actually live, or block it entirely at the firewall until the update goes in. That’s a real mitigation here, unlike a lot of “restrict network access” advice that just narrows the blast radius without closing the hole. Since exploitation needs nothing but a crafted XML POST, cutting off unauthenticated internet reach removes the precondition the whole attack depends on.

After patching, check your access logs for /pa requests with unusual timing, source IPs outside your expected phone provisioning range, or XML bodies that don’t match a real Polycom handset’s normal check-in pattern. If your Switchvox host has been internet-facing since before July 14 and you only patched recently, that log review isn’t optional. A device that got compromised before the patch stays compromised after it; upgrading closes the door but doesn’t evict anyone already inside.

The actual lesson here

The technical bug is a textbook SQL injection, the kind of thing that shouldn’t ship in 2026 and yet still does, in provisioning code that nobody stress-tests the way they stress-test a login form. But the more useful number in this whole story isn’t 9.3. It’s six weeks: the gap between “the vendor told you exactly how to fix this” and “someone starts exploiting the ones who didn’t.” That gap is where the actual risk lives, and it’s closed by treating a patch release as the start of a countdown, not an item you’ll get to eventually. If you want the deeper mechanics of how SQL injection like this gets built and how to actually close it off in your own code, that’s worth a read regardless of whether Switchvox is in your stack, because the “concatenate instead of bind” mistake shows up in homegrown provisioning and admin endpoints far more often than in the parts of an app anyone thinks to audit.