An August Zero-Day in FreePBX Just Got a Push-Button Exploit. Shodan Shows ~10,700 Admin Panels Still Hanging Open — a Third of Them in the US.
- Patrick Duggan
- 3 minutes ago
- 4 min read
If you saw FreePBX exploitation in a surge this week and thought it was odd to still be seeing it, your instinct was correct, and the explanation is not a new vulnerability — it is a new exploit for an old one. The bug at the center of the surge is CVE-2025-57819, an authentication bypass in the FreePBX commercial Endpoint Manager that chains into SQL injection and then remote code execution, carrying the maximum CVSS score of 10.0. That bug is not fresh. It was exploited as a zero-day starting August 21, 2025, and has been in CISA's Known Exploited Vulnerabilities catalog since. What is fresh is that on June 6, 2026 — yesterday, in news terms — a clean, one-shot public exploit was published and demonstrated against FreePBX 16.0.40.7. A push-button exploit for a 10.0 unauthenticated auth-bypass is the single most reliable way to re-ignite mass scanning of a bug that has been sitting patched-but-not-patched for ten months. The vulnerability did not get more dangerous. The skill required to use it dropped to zero, and the opportunistic crews piled back in.
To understand why this keeps happening to phone systems specifically, we asked Shodan how many FreePBX administrative interfaces are sitting on the open internet right now. The answer: roughly ten-thousand-seven-hundred instances return a FreePBX administration title, and about thirteen-thousand-four-hundred carry FreePBX markup in their HTML — a population of internet-facing PBX consoles, the exact surface this exploit reaches. The geography is the part that should land for a US reader: of the ~10,700 by title, three-thousand-six-hundred-one are in the United States, roughly a third of the global exposure, followed by Germany at nine-hundred-ninety, Brazil at four-forty, Canada at four-thirty-three, the United Kingdom at three-eighty-eight, and China at three-eighty-three. This is not enterprise core infrastructure behind three layers of defense. It is self-hosted small-business telephony — the PBX a managed-service provider stood up years ago, that works, that nobody logs into, and that has its admin panel reachable from the open web because that was easier than a VPN. That population barely moves. It is why a phone-system bug from last August can surge again in June: the install base does not patch, so every new public exploit finds the same unlocked doors waiting.
The mechanism is worth stating plainly because it tells you exactly what to hunt for. The Endpoint Manager's ajax handler takes the brand parameter from a request and concatenates it straight into a SQL query while skipping the Referrer and authentication check, which gives an unauthenticated attacker error-based SQL injection with stacked-query writes enabled. From there the path to code execution is short and well-documented: write an operating-system command into the FreePBX cron_jobs table and let the scheduler run it, or insert a new administrator straight into the ampusers table and log in as a legitimate admin. Either way the attacker is on the box, often as the asterisk user, on a system that routes a business's phone calls — which means toll fraud, call interception, and a foothold into the network behind the phones. And this is not the only FreePBX bug in play right now, which is what can make the surge feel like a brand-new chain. A separate flaw, CVE-2025-64328 — a post-authentication OS command injection in the same Endpoint Manager, through the testconnection function's check_ssh_connect() call — has been exploited since at least December 2025 to deploy a PHP web shell called EncystPHP, with privilege escalation to root and active defense-evasion built in. Reporting attributes that campaign to an actor tracked as INJ3CTOR3, with more than nine-hundred FreePBX instances confirmed compromised by February. Two FreePBX bugs being worked simultaneously, by different operators, with different payloads, is why the activity reads as sustained novelty rather than a single old CVE.
Our coverage status, stated honestly: all three FreePBX CVEs — the new-exploit 57819, the web-shell 64328, and the older 2019 authentication bug — are in our KEV index and have been. The gap we just closed today is the actor: we ingested an INJ3CTOR3 profile into our adversaries index, naming the EncystPHP web shell, the CVE-2025-64328 vector, and the December-onward timeline, and linked it into the FreePBX cluster so the next query — ours or a customer's through the feed — resolves the crew, not just the CVE. That is the flywheel: the question exposed what we did not have, and now we have it.
The protective read is blunt, and the highest-value move is not the patch. Patch, yes — FreePBX fixed 57819 in 15.0.66, 16.0.89, and 17.0.3, and you should be on those or later tonight. But the move that defeats this entire class is to get the FreePBX administrative interface off the public internet. Every one of these exploits assumes the attacker can reach the admin panel; put it behind a VPN or an IP allowlist and the unauthenticated reach evaporates, which is why the ~10,700 exposed panels are the real story and not the CVE. Then hunt, because patching forward does not evict someone already inside: look for administrator accounts in the ampusers table that you did not create, unexpected rows in the cron_jobs table containing shell commands, unfamiliar PHP files under the web root (EncystPHP is a web shell — it lives as a file), and shells or outbound connections running as the asterisk user. The Shodan number is the framing to take to your own estate: if you run FreePBX, assume you are in the ten-thousand-seven-hundred until you have confirmed your admin plane is not answering the open web.
The honest 95%: a Shodan title match is an exposure count, not a vulnerability scan — some fraction of those ~10,700 panels are patched, behind compensating controls, or honeypots, so treat the number as the surface population, not a casualty list, and treat it as a floor besides, because Shodan does not see everything. We are repeating the INJ3CTOR3 attribution from public reporting rather than our own incident response, and the actor label is looser than a single named group. And we cannot tell you the June 6 exploit is the last word; a 10.0 with a public one-shot tends to get folded into botnet toolkits within days, so the surge you are seeing now is more likely a beginning than a peak. The bug is from August. The exploit is from yesterday. The exposed phones have been waiting the whole time.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.