CISA added CVE-2026-9586 to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a September 5 due date, and Sangoma’s own release notes check “Cloud” alongside “On-Prem” for the fix — while the only CPE on the NVD record ends in on-premises.
What happened
The NVD record for CVE-2026-9586 carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-05, and a cisaVulnerabilityName of “Sangoma Switchvox SQL Injection Vulnerability.” Federal civilian agencies have until Saturday, September 5, 2026 to act.
The cisaRequiredAction is the standard BOD 26-04 text. Two clauses matter below: agencies must “Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable,” and they are “responsible for evaluating each asset’s internet exposure.” It also invokes CISA’s “Forensics Triage Requirements.”
From the record: “An unauthenticated SQL injection vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997). The /pa endpoint processes XML content beginning with <PolycomIPPhone> and directly concatenates the user-controlled PhoneIP value into PostgreSQL queries without sanitization or parameterization. An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution.” The class is CWE-89. Horizon3, which analyzed the code path, places it in PhoneAppsHandler.pm and says the queries run as a PostgreSQL superuser.
Two scores sit on the record. SRA, the CNA that assigned the CVE, scored it CVSS 4.0 at 9.3 critical; NVD’s own analysts scored it CVSS 3.1 at 9.8 critical as the primary source. Most coverage has carried the 9.3. The two are on different scales rather than in dispute — but a triage rule keyed to “9.5 and above” sorts this vulnerability differently depending on which field it reads.
Sangoma shipped the fix on July 14, 2026, in Switchvox 8.4.0.2, and published no security advisory. What exists is a release-notes page on Sangoma’s knowledge base with a resolved-issues table; the word “security” does not appear anywhere on it. The table has an “Issue” column and two check columns headed “On-Prem” and “Cloud.” Every row is checked in both.
The rows, verbatim: “CWE-89 – Improper Neutralization of Special Elements used in an SQL Command”; “CWE-22 – Improper Limitation of a Pathname to a Restricted Directory”; “CWE-78 – Improper Neutralization of Special Elements used in an OS Command”; “CWE-269 – Improper Privilege Management”; “CWE-918 – Server-Side Request Forgery”; “CVE-2026-9588 – Authenticated Stored Cross-Site Scripting (XSS) in Switchvox Web Portal”; “CVE-2026-9587 – Authenticated Local File Inclusion (LFI) in Switchvox Web Portal”; “CVE-2026-9586 – Unauthenticated RCE via SQL Injection in SwitchVox 8.2.2.1”; “CVE-2026-9585- Unauthenticated Reflected Cross-Site Scripting (XSS) in Switchvox Web Portal.”
Five CWE rows and four CVE rows, and they do not describe the same set of fixes. CWE-79 — cross-site scripting, the class of two of the four listed CVEs — is not in the CWE list. CWE-78, CWE-269, and CWE-918 map to none of the four CVE descriptions. Horizon3 says it reported twelve distinct vulnerabilities to Sangoma on April 10, 2026. Four CVE IDs exist for this release, all assigned by SRA and all credited to Cam Lischke of SRA. Severity Daily could not match the three unaccounted-for CWE rows to any published CVE.
The disclosure ran on two tracks. Horizon3 reported its twelve findings on April 10, 2026 and had a patched pre-release build from Sangoma by April 21. SRA submitted its four between May 11 and May 26 and says Sangoma acknowledged them on June 2. The patch shipped July 14; SRA published the CVEs on July 17.
Exploitation came six weeks after the fix. Horizon3, running honeypots with Defused Cyber since May 8, 2026, says it saw exploitation on August 30, 2026 — netcat reverse shells and enumeration commands, artifacts landing in /var/log/switchvox/db-quirks.log, and one address, 176.65.148.184, moving across multiple sensors. That is a single research firm’s honeypot data. Horizon3 published on September 1; CISA listed the CVE on September 2, and the record’s CISA-ADP block now carries Exploitation: active, Automatable: yes, and Technical Impact: total. Horizon3 puts internet-exposed instances at roughly 4,000 by Shodan count, mostly in the United States — one vendor’s scan, and it should be read as one.
Why it matters
The cloud column is the part with an action attached to it. CISA’s required action tells agencies to “Follow applicable BOD 26-04 guidance for cloud services.” Sangoma’s release notes check Cloud alongside On-Prem, which is a vendor statement that the hosted edition was affected. NVD’s record disagrees by omission: its single CPE is cpe:2.3:a:sangoma:switchvox:*:*:*:*:on-premises:*:*:*, versions 8.2.2.1 up to but excluding 8.4.0.2, and there is no cloud or hosted CPE on the record at all.
CPE strings are what asset-matching tools consume. An organization running the hosted edition and matching its inventory against this record gets no hit, produces a clean report, and never asks the question the required action is telling it to ask. It cannot patch a hosted service in any case — but it can demand written confirmation that the fix reached its tenant, and the KEV entry is the reason to ask this week rather than next quarter. The vendor’s own bug list is currently better evidence of cloud exposure than the federal vulnerability record is.
The second thing worth sitting with is how this fix was communicated. There is no advisory page, no security mailing-list entry, no vendor CVSS score, and no use of the word “security” on the page that announces the fix. The CVE identifiers are present — Sangoma did list them — but as bug rows in a changelog. An operator who subscribes to vendor security advisories learned nothing; an operator who diffs release notes learned everything. Six weeks later, roughly 4,000 instances were still reachable, and attackers found them before most defenders read the changelog.
Then the version numbers. Three statements of where the affected range begins, and no two agree. SRA’s CVE record and advisory both say “8.3 (104997)” through versions before 8.4.0.2. NVD’s CPE says 8.2.2.1 through 8.4.0.2 exclusive. Sangoma’s release-notes row names the flaw as being “in SwitchVox 8.2.2.1.” NVD’s range is the widest, and the widest is the one to act on — but an administrator on an 8.2 build reading the CVE description alone would reasonably conclude the record does not describe their system.
Finally, the clock. This CVE was published on July 17, 2026 and drew a three-day deadline on September 2 — the shortest band BOD 26-04 defines, and one that obliges agencies to carry out a forensic triage of the asset rather than merely patch it. The record now carries CISA’s own machine-readable values for three of the four variables the directive uses: exploitation, automation, and technical impact are all in the ADP block. The fourth, internet exposure, is left to the agency, which is exactly what the required action says. What is not published in machine-readable form is the schedule those variables feed into. CISA distributes that mapping as Table 1 in Appendix A, as PNG images with no alt text, and the vendors who transcribed it by eye disagree with each other about which combinations earn three days. The inputs are in the record; the function is a picture. Do not reason backward from this deadline to the table.
What to do
- Upgrade to Switchvox 8.4.0.2 or later — the only fixed build named by the vendor, the CVE record, and NVD alike.
- Federal agencies: the due date is Saturday, September 5, 2026, and the required action pairs remediation with CISA’s forensic triage obligation. Patching alone does not close it.
- Hosted-edition customers: ask Sangoma in writing whether the fix has been applied to your tenant. The release notes check “Cloud”; the NVD record has no cloud CPE, so inventory tooling will not raise this for you.
- Check
/var/log/switchvox/db-quirks.log for anomalous SQL and shell commands. This is Horizon3’s stated artifact location, from honeypot data rather than from the vendor.
- The
/pa endpoint should not be reachable from the internet. It accepts unauthenticated XML by design. Restricting it to the phone VLAN removes the attack path regardless of version.
- 176.65.148.184 is the one address Horizon3 named — a single campaign’s infrastructure, not an indicator list.
Sourcing note
CISA’s KEV fields, the CVSS scores, the CWE, the CPE range, and the description were read from the NVD API record for CVE-2026-9586 (lastModified 2026-09-03T13:06:25.427), retrieved twice with different query forms; the CPE scope claim — that no cloud or hosted CPE exists on the record — was confirmed on both. The CNA record was read from the CVE Program API: assigner SRA, published July 17, 2026, updated September 2, 2026, credit to Cam Lischke of SRA, and CISA-ADP values of active exploitation, automatable, total technical impact. Sangoma’s release notes for 8.4.0.2 were fetched twice with different prompts; the resolved-issues table, the On-Prem and Cloud columns, and the absence of the word “security” were consistent across both. SRA’s advisory at labs.sra.io supplied the disclosure timeline and the other three CVEs. Horizon3’s disclosure page supplied the honeypot timeline, the log artifact, the attacker address, and the Shodan count — all single-sourced to Horizon3, none verified independently here, and the exposure figure is a scan estimate, not a count of vulnerable systems.
cisa.gov returns HTTP 403 to automated fetching from this container, so the KEV catalog page and the September 2 alert were not read directly; CISA’s fields were taken from NIST’s republication of them in NVD, the standing practice on this site. Unresolved: whether the three CWE rows with no matching CVE — CWE-78, CWE-269, and CWE-918 — correspond to any of the twelve vulnerabilities Horizon3 says it reported, and whether identifiers were ever assigned for them. Sangoma has published no security advisory for this release, so there is no vendor document in which to look.