An unauthenticated SQL injection is dropping reverse shells on Switchvox PBXes right now

An unauthenticated SQL injection is dropping reverse shells on Switchvox PBXes right now

The PBX is the machine nobody logs into for two years and then panics about. It sits in a rack, it routes calls, it works. Which is why CVE-2026-9586 is the kind of bug that ruins a quarter: an unauthenticated SQL injection in Sangoma Switchvox that chains straight through to a reverse shell, and it’s being exploited in the wild today. No credentials. No user interaction. A crafted HTTP request and the box calls out to someone else’s server.

Here’s the timeline as it actually unfolded, and what each beat means for the call you have to make this afternoon.

Whenever your appliance was last patched — the clock started here

The vulnerability lives in how the Switchvox web interface handles input before it reaches the database. Somewhere in the request path, attacker-controlled data gets concatenated into a SQL query without proper parameterisation. That’s the whole tragedy of SQL injection in 2026 — a class of bug we’ve had the fix for since before some of your engineers were born, still shipping in appliance firmware because nobody re-audited the old admin endpoints.

On its own, SQL injection reads database rows. The reason this one is a five-alarm fire rather than a data-leak footnote is that the injection is the first link, not the last. From SQL-layer access the attackers pivot to code execution on the underlying host, and from there they drop a reverse shell — the appliance opens an outbound connection to attacker infrastructure and hands them an interactive session. Outbound, note. Your perimeter firewall is very good at blocking connections in. It is usually asleep on connections going out from a trusted VoIP box.

Sangoma has not, at the time of writing, published a specific affected-version range that I’d stake a remediation plan on. So don’t wait for one. Treat every unpatched Switchvox instance — on-prem appliance or virtual — as vulnerable until you’ve confirmed otherwise against Sangoma’s advisory. That’s not fearmongering; that’s the only safe default when the vendor hasn’t drawn a line and exploitation is already live.

Today, 2026-09-03 — BleepingComputer confirms it’s being exploited

The reporting is unambiguous: confirmed in-the-wild attacks, working exploit code, reverse shells deployed for persistent access. That single fact changes the math. When a bug is theoretical you can schedule it. When someone has automated it and is spraying the internet for vulnerable hosts, the window between “I’ll get to it” and “the box is already talking to Moldova” is measured in hours.

The exposure that matters most is any Switchvox web UI reachable from an untrusted network — internet-facing instances first, then anything reachable from a broad internal segment. VoIP gear ends up internet-exposed constantly: remote extensions, SIP trunking, a “temporary” NAT rule from 2021 that outlived the person who added it. And a lot of these boxes are shadow IT. The office manager bought a phone system; nobody told security it had a web server on it.

Find every Switchvox before the attackers finish finding them

Step one isn’t patching. It’s inventory, because you can’t patch a box you don’t know you own. This runs from a Windows admin host, checks TCP 443 across a subnet, and fingerprints the response for Switchvox’s web interface. It’s read-only — it reports, it doesn’t touch anything.

audit.ps1PowerShell
# Discover potential Switchvox web UIs on a subnet. REPORT ONLY.
# Adjust the /24 to your VoIP / management ranges.
$subnet   = '10.20.30'
$port     = 443
$results  = foreach ($i in 1..254) {
    $ip = "$subnet.$i"
    $tcp = Test-NetConnection -ComputerName $ip -Port $port -WarningAction SilentlyContinue
    if ($tcp.TcpTestSucceeded) {
        try {
            # Ignore cert validation for discovery only
            [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }
            $resp = Invoke-WebRequest -Uri "https://$ip/" -TimeoutSec 5 -UseBasicParsing
            $isSwitchvox = ($resp.Content -match 'Switchvox') -or `
                           ($resp.Headers['Server'] -match 'Switchvox')
            [pscustomobject]@{
                IP          = $ip
                Port        = $port
                LikelyPBX   = $isSwitchvox
                Server      = $resp.Headers['Server']
                TitleSample = ([regex]::Match($resp.Content,'<title>(.*?)</title>')).Groups[1].Value
            }
        } catch {
            [pscustomobject]@{ IP=$ip; Port=$port; LikelyPBX='port-open-no-http'; Server=$null; TitleSample=$null }
        }
    }
}
$results | Where-Object LikelyPBX -ne $false | Format-Table -AutoWidth

Cross-check that against what your asset inventory claims is on those ranges. The boxes that show up here but not there are your problem children.

The next 72 hours — assume you’re being scanned, then assume worse

With a live exploit in circulation, mass scanning follows fast. If your box is internet-facing and unpatched, the honest planning assumption is not “am I a target” but “have I already been hit.” So while the patch is downloading, go hunting for the signs of a shell that’s already home.

What a compromised Switchvox looks like:

  • Unexpected outbound connections from the appliance — especially to unfamiliar IPs on high or non-standard ports. A PBX has a predictable talk-list: SIP peers, your trunk provider, NTP, DNS, update servers. A shell to a random VPS is not on that list.
  • Unfamiliar processes, particularly shells (bash, sh, nc, python, perl) parented to the web server process rather than to a login session. Web-server-spawns-a-shell is the signature of exactly this attack class.
  • New or unexpected accounts, both OS-level and inside the Switchvox admin UI. Persistence outlives the patch if you don’t check.
  • Web/DB logs showing injection-shaped requests — long unauthenticated GET/POSTs to admin endpoints stuffed with SQL syntax and quote characters. You don’t need to reverse the exact payload to spot the pattern.

If you have shell access to the appliance, this read-only sweep is a fast triage. It changes nothing — it just tells you where to look harder.

run.shbash — zsh
#!/usr/bin/env bash
# Switchvox reverse-shell triage. READ ONLY. Run on the appliance.
​
echo "== Outbound established connections (review anything not a SIP peer/trunk/NTP/DNS) =="
ss -tnp state established 2>/dev/null | grep -vE ':(5060|5061|123|53|443)\b' || netstat -tnp 2>/dev/null
​
echo
echo "== Shells parented to the web server (classic RCE tell) =="
ps -eo pid,ppid,user,comm,args --sort=start_time 2>/dev/null \
  | grep -E '(bash|/sh|nc|ncat|python|perl|socat)' | grep -viE 'grep|triage'
​
echo
echo "== Recently modified files in web-writable/temp paths (last 3 days) =="
find /tmp /var/tmp /dev/shm /var/www 2>/dev/null -type f -mtime -3 -printf '%TY-%Tm-%Td %p\n' 2>/dev/null | sort
​
echo
echo "== Recent account additions =="
awk -F: '{print $1":"$3}' /etc/passwd | sort
tail -n 20 /var/log/secure 2>/dev/null; tail -n 20 /var/log/auth.log 2>/dev/null
​
echo
echo "== Web logs: injection-shaped unauthenticated requests =="
grep -iE "select|union|sleep\(|information_schema|0x[0-9a-f]{4}|--|';" \
  /var/log/httpd/*access* /var/log/nginx/*access* 2>/dev/null | tail -n 40

Two rules if any of this lights up. First, a reverse shell means hands-on-keyboard access — you cannot trust the box, and cleaning individual artefacts is a mug’s game. Plan to rebuild from known-good and restore config, not to scrub. Second, capture evidence (memory, logs, disk image if you can) before you nuke it, because the same actor who owns your PBX may own more than your PBX.

The moment a fixed build exists — that’s your real deadline

Patching is the fix. Full stop. Pull Sangoma’s advisory, identify the fixed build for your version, and apply it. Because I won’t quote a version or a patch date I can’t verify, confirm the exact fixed release directly from Sangoma rather than from any secondhand summary — this article included.

If you genuinely cannot patch in the next few hours — change window, dependency, appliance you can’t reach until Monday — then contain, and contain hard:

  1. Cut the box off from untrusted networks immediately. No internet-facing web UI, full stop. If remote admin matters, put it behind a VPN. This alone defeats the mass-scanning that’s driving the current wave.
  2. Restrict it to the VoIP VLAN and lock ingress to the ports the phone system actually needs — not the admin interface.
  3. Add egress filtering. This is the one control that directly breaks the reverse shell. If the appliance can only reach its trunk provider, NTP and update servers, the shell has nowhere to phone home. It’s also the control most orgs skip because “it’s internal.” A PBX with unrestricted outbound is a loaded gun.
  4. Turn logging up and ship it somewhere the attacker can’t reach, so if they’re already in, they can’t quietly tidy up after themselves.

Containment buys you a weekend. It is not a substitute for the patch — it’s the thing you do so the patch doesn’t have to happen at 2 a.m.

The urgency here is immediate, and I don’t use that word to pad a headline. The three ingredients that justify dropping everything are all present: no authentication required, code execution at the end of the chain, and confirmed exploitation in the wild. When all three line up, the only question worth answering is which of your Switchvox boxes an attacker reaches before you do.

The next dated beat on this calendar is the one you control: the timestamp on your change ticket. Make it today.

Related Post