CISA added CVE-2026-9586 to its Known Exploited Vulnerabilities catalog on September 2 after Horizon3.ai observed live exploitation attempts against internet-exposed Sangoma Switchvox deployments, with attackers attempting to plant reverse shells for persistent remote access. The bug is an unauthenticated SQL injection in a phone-provisioning endpoint that escalates directly to operating-system command execution — no credentials, no user interaction, one HTTP request.

What Happened

Switchvox is Sangoma’s VoIP/UC platform, commonly deployed as an on-prem PBX appliance for small and mid-size businesses. It exposes an HTTP endpoint at /pa that handles auto-provisioning callbacks from supported Polycom IP phones — a feature that, by design, has to accept requests before any phone has authenticated to the system.

The handler parses incoming XML bodies, and when the root element is <PolycomIPPhone>, it extracts the PhoneIP attribute (or a child value) and drops it directly into a PostgreSQL query as a raw string literal rather than a bound parameter. An attacker who controls that value can break out of the string context and inject arbitrary SQL. Horizon3’s researchers, who discovered and reported the issue back in April 2026, found that the query executes with PostgreSQL superuser privileges — which means SQL injection isn’t the ceiling. From there it’s a short hop to COPY ... TO PROGRAM or equivalent superuser tricks to reach arbitrary OS command execution on the underlying appliance.

CVE-2026-9586 carries a CVSS score of 9.3. It affects Switchvox SMB Edition 8.3, build 104997, and earlier. Sangoma shipped a fix in version 8.4.0.2 on July 14, 2026 — but per Horizon3, real-world exploitation attempts against unpatched, internet-facing instances only began around August 30, a six-week gap in which the technical details had time to circulate before most operators patched.

Impact

Shodan shows roughly 4,000 Switchvox instances reachable from the internet, the bulk of them in the United States. Because the vulnerable endpoint requires zero authentication and the resulting access runs as the database superuser, a successful exploit hands an attacker root-equivalent control of the PBX appliance in a single unauthenticated request — no phishing, no credential theft, no chained precondition.

A compromised VoIP/PBX server is a disproportionately valuable foothold: it typically sits with trusted access into internal networks, holds call detail records and voicemail that can support further social engineering or business email compromise, and — as Horizon3 and BleepingComputer both report — is already being used by attackers to drop reverse shells for follow-on command-line access. From there, lateral movement into the broader corporate network, credential harvesting from adjacent systems, or straightforward ransomware staging are all in scope. Organizations that treat their PBX as a “phone problem” rather than a network-attached server tend to under-patch and under-monitor it, which is exactly the exposure this bug is designed to punish.

Mitigation

  • Patch immediately. Upgrade to Switchvox 8.4.0.2 or later. This has been available since mid-July; any instance still on 8.3 or earlier has had a public fix to apply for nearly two months.
  • Assume compromise on any unpatched, internet-facing instance. Because in-the-wild exploitation is already underway, don’t treat patching alone as remediation for a box that was exposed and vulnerable in the days before you updated. Check for unfamiliar processes, unexpected outbound connections, added cron jobs, or new local/database accounts.
  • Review PostgreSQL and application logs for anomalous queries hitting the /pa endpoint, especially malformed or oversized PhoneIP values and any COPY ... TO PROGRAM-style statements that have no legitimate reason to appear in provisioning traffic.
  • Restrict network exposure. The provisioning endpoint should not need to be reachable from the open internet in most deployments — front it with an allowlist for known phone-network ranges or a VPN, and remove it from direct WAN exposure where the deployment doesn’t strictly require it.
  • Federal agencies and KEV-tracking organizations should treat this as a patch-immediately item per CISA’s Known Exploited Vulnerabilities catalog entry and associated remediation deadline.

References