Sangoma Patches Critical FreePBX Zero-Day Exploited in Wild with Perfect 10.0 CVSS Score

Another CVSS 10.0 vulnerability, and this one actually earned it. Sangoma patched a FreePBX zero-day that's been getting exploited in the wild since August 21st. Attackers were walking straight into admin panels like they owned the place.

Here's what makes me want to throw my laptop out a window: this wasn't some sophisticated APT shit. It's a basic input sanitization failure in the "endpoint" module. This is literally day-one web security stuff - sanitize your fucking inputs. We've known this since PHP was still cool and I was debugging SQL injection attacks with print statements.

The attack chain is textbook privilege escalation: bad input validation → admin access → database fuckery → remote code execution → root shell. I've seen this exact progression during incident response calls at 2 AM when some company's phone system is hemorrhaging data and the CEO is screaming about downtime costs.

FreePBX runs the web interface for Asterisk, which means thousands of companies just had their entire VoIP infrastructure exposed. When FreePBX gets owned, the phones die and business stops. I've been on conference calls where the conference system itself was compromised mid-call - surreal doesn't begin to cover it.

CISA dumped CVE-2025-57819 on the Known Exploited Vulnerabilities list with a September 19 patch deadline for federal agencies. If your FreePBX admin panel was internet-facing without IP filtering during that two-week shitshow from August 21 to September 2, you're probably fucked.

From my experience debugging telecom infrastructure at 3AM, the GitHub advisory's "chained with several other steps" usually means the attackers had a field day. Admin access on these systems typically leads to database dumps, call detail record extraction, and if you're really unlucky, pivoting to the rest of your network.

Credit where it's due: Sangoma actually handled this well. Emergency patches for versions 15, 16, and 17, proper IoCs for threat hunting, and system recovery procedures. Most vendors just push a patch and pray nobody notices the months of exposure.

If you think you got hit: Assume compromise, burn it down, rebuild from backups that predate August 21. Check your authentication logs for suspicious admin logins and pray your call detail records didn't leak. I've seen attackers sell CDRs for identity theft - your customers' phone metadata is worth money on the dark web.

The Vulnerability Breakdown

• CVE ID: CVE-2025-57819
• CVSS Score: 10.0/10 (yeah, it's that bad)
• Root Cause: Insufficient sanitization of user-supplied data in the "endpoint" module
• Attack Vector: Network-accessible admin panels without proper IP filtering
• Exploitation Window: August 21 - September 2, 2025

Affected Versions and Patches

• FreePBX 15: Patched
• FreePBX 16: Patched
• FreePBX 17: Patched (but watch out for framework module update notification issues)

The GitHub security advisory tells the whole sorry story: this was basic input validation fuckup that let attackers waltz right past the login screen. Once inside the admin panel, they could manipulate the database and execute arbitrary code.

What Actually Happened to Your Phone System

From my experience debugging telecom infrastructure at 3AM, here's what probably happened to compromised systems:

1. Initial compromise via web interface - no credentials needed
2. Database manipulation - call logs, user accounts, billing data
3. Code execution - backdoors, persistence mechanisms
4. Privilege escalation - working toward root access
5. Lateral movement - accessing other network resources

Detection Indicators

Sangoma released IOCs, but if you're running FreePBX, check your logs for:

• Unusual admin panel access from external IPs
• Database modifications outside normal business hours
• New user accounts you didn't create
• Unexpected system processes or network connections
• Modified configuration files

The Restoration Reality

If you got hit, restoration isn't just "apply patch and restart." You need to:

• Assume complete system compromise
• Rebuild from known-good backups (if you have them)
• Rotate all credentials
• Review call logs for data exfiltration
• Check connected systems for lateral movement

Why This Happened

FreePBX gets deployed by network admins who can configure a switch in their sleep but treat web security like a foreign language. The default configuration makes the admin interface accessible from anywhere, and many deployments skip the IP filtering setup that would have prevented this.

This is what happens when "just make it work" beats "maybe we should secure this shit." Every fucking time.