CVE-2026-9586: Sangoma Switchvox SQL Injection Vulnerability

What this software does

Sangoma Switchvox is a VoIP phone system appliance. It runs the PBX (private branch exchange) for small and medium businesses — routing calls, managing voicemail, hosting auto-attendants, and providing the web interface your phone administrators log into to manage extensions and call routing. Because it sits at the center of your telephony, it holds call records, voicemail, extension credentials, and often integrates with your directory or CRM. A compromise here means someone can listen to voicemail, reroute calls, and potentially pivot into whatever else the appliance can reach on your network.

What went wrong

This is a SQL injection vulnerability in Switchvox's handling of a crafted request. The weakness lets an unauthenticated remote attacker execute arbitrary SQL statements against the backend PostgreSQL database with a single request. The description goes further: the attacker can perform database operations and achieve remote code execution. No credentials are required, and no user interaction is needed. The description does not state an authentication requirement, and the CVSS vector agrees — this is reachable by anyone who can send a request to the appliance over the network.

The fault lives in how the application builds database queries from request data. An attacker who can reach the Switchvox web interface or API can inject SQL that the backend database will execute. From SQL injection to code execution on PostgreSQL is a well-trodden path when the database runs with elevated privileges, which is common on appliance-style deployments.

Why this one matters

This is listed in CISA's Known Exploited Vulnerabilities catalogue, which means it is confirmed exploited in the wild. That changes the calculus from "should I patch soon" to "assume someone is scanning for this right now." The combination is the worst profile a flaw can have: network-reachable, no authentication, no user interaction, and code execution. Automated scanning tools pick up signatures for flaws like this within days of public disclosure, and the exploit is already out there — CISA does not add things to KEV on speculation.

The EPSS probability of exploitation in the next 30 days is 1.1%. That number looks small, but it is not a reason to relax. EPSS measures the likelihood that any given system will be targeted, not the consequence if yours is. For a confirmed-exploited, unauthenticated code-execution flaw in a network appliance, the operational question is not whether you will be hit but how long you stay exposed. Patch this before you patch anything else.

Are you affected?

You are affected if you run Sangoma Switchvox and the appliance is reachable over your network — from the LAN, a VPN, or worse, the internet. This is not a feature-gated flaw. There is no non-default setting that needs to be enabled for the vulnerability to exist. If the Switchvox web interface or API is listening on a port that an attacker can reach, you are exposed.

The one mitigating condition is network segmentation. If your Switchvox is isolated so that only trusted administrative hosts can reach it, your exposure is reduced — but not eliminated, because any compromised machine on that trusted path becomes a launching point. Check whether the appliance is directly internet-facing. If it is, treat this as urgent.

How to fix it

There is no fixed version published yet. The vendor has not released a patch as of this advisory. Your usual update routine — whether that is the Switchvox web admin's update checker or whatever process you use to keep the appliance current — will not deliver a fix that does not exist. Watch the vendor advisory for Sangoma Switchvox and apply the fixed version the moment it is released. The fixed version, when it exists, will be in the table below.

When the patch does arrive, do not stop at installing it. An upgraded package still running the old process in memory is the most common way a patch silently fails. After you apply the update, restart the Switchvox services and verify that the running service reports the new version — not just the version on disk. If the appliance has a web admin interface, log in and confirm the version it displays. If you manage it through SSH, check what the running process reports, not what the package manager thinks is installed.

If you cannot patch immediately

There is no fixed version yet, so "immediately" is the only option you have — but you can reduce your exposure while you wait.

First, if the Switchvox web interface or API is reachable from the internet, block it at your firewall or proxy now. This appliance should never be directly internet-facing for administration. Restrict access to trusted administrative IP ranges or require a VPN before anyone can reach it.

Second, if you have a web application firewall or reverse proxy in front of Switchvox, enable SQL injection filtering rules for the paths that handle administrative requests. This is not a complete fix — a WAF can be bypassed — but it raises the bar for automated scanning.

Third, review any firewall rules that allow broad network access to the appliance. If your Switchvox is on the same flat network as your user workstations, a single compromised desktop becomes a path to your phone system. Segment it if you can.

The cost of these mitigations: remote administration becomes less convenient, and you will need VPN access or a jump host to manage the appliance. That is a price worth paying while there is no patch.

How to tell if you were already targeted

Because this is confirmed exploited in the wild, you should check whether your appliance has been hit. Look for signs of database activity that does not match normal operation. On the Switchvox appliance, examine the PostgreSQL logs for queries that reference system tables or attempt to read files — legitimate phone-system queries do not touch pg_catalog in unusual ways or call functions like pg_read_file. Look for outbound connections from the appliance to IP addresses that are not your normal telephony providers or update servers. An appliance that is phoning home to an unfamiliar address is a red flag.

Check for new scheduled tasks or cron jobs on the appliance. Attackers who achieve code execution often install persistence through scheduled tasks that survive a reboot. Look for anything that was not created by your administration team. Also check for new user accounts, particularly in the PostgreSQL database or the operating system, that you did not create.

If you find evidence of compromise, preserve the logs and any suspicious files before deleting anything. Take the appliance offline if you can — a compromised phone system can be used to make expensive calls, eavesdrop on voicemail, or pivot into your network. Then restore from a known-good backup and change all credentials that the appliance holds, including extension passwords and any directory or CRM integration credentials.

Reducing the blast radius

When the patch arrives and you have recovered, make three changes so the next flaw in this appliance costs less.

Run Switchvox with the database account limited to the minimum privileges the application needs. If the PostgreSQL account Switchvox uses is a superuser, an SQL injection flaw becomes code execution trivially. If the vendor supports it, create a restricted database role for the application.

Segment the appliance onto its own VLAN or firewall zone. Phone systems do not need to reach your file servers, domain controllers, or workstations. Restrict both inbound and outbound traffic to what the appliance actually needs: SIP traffic, update servers, and administrative access from trusted hosts.

Keep the appliance's administrative interface off the general network. Require VPN access or a jump host for anyone who manages Switchvox. The convenience cost is small; the benefit is that a flaw like this one stops being reachable by every machine on your LAN.