February 27, 2026 Source: SecurityWeek 2 min read · 572 words

900 Sangoma FreePBX Instances Infected With Web Shells

900 екземплярів Sangoma FreePBX заражені веб-оболонками

Sangoma FreePBX just became a poster child for what happens when authentication controls fail at scale. SecurityWeek reported that 900 instances of the popular open-source PBX system were infected with web shells, all stemming from a single post-authentication command injection flaw in the endpoint manager interface. This isn't a theoretical vulnerability buried in obscure documentation. This is real infrastructure, real targets, right now compromised.

The timing alone should make your security team uncomfortable. We're talking about telephone systems—infrastructure that touches everything from customer service lines to emergency response workflows. When 900 of them fall, it's not just a patch Tuesday problem.

What We Know

The attacks exploited a post-authentication command injection vulnerability in FreePBX's endpoint manager. According to the SecurityWeek report, the vulnerability allowed attackers to inject commands after passing through authentication, meaning they needed valid credentials—but once inside, the system trusted them completely.

Web shells were deployed across the infected instances.

This wasn't a spray-and-pray campaign. The targeting was specific enough to compromise 900 systems, suggesting either active reconnaissance, credential theft, or both. The real question is: how long were these systems compromised before anyone noticed?

And here's what we don't know yet: the full scope of lateral movement, data exfiltration, and persistence mechanisms deployed post-infection. Web shells are just the visible part of an iceberg.

How It Works

The endpoint manager in FreePBX handles phone device provisioning and configuration across your entire deployment. It's a privileged interface by design. The vulnerability allowed authenticated users to inject system commands that execute with the permissions of the FreePBX process itself.

So an attacker with valid credentials—whether stolen, brute-forced, or obtained through social engineering—could run arbitrary code on the system. From there, web shells provide persistence and remote access, turning compromised FreePBX instances into entry points for deeper network penetration.

The fact that this is a post-authentication flaw is important. It means the Sangoma FreePBX authentication bypass vulnerability required that initial foothold. But frankly, that's almost worse. It means internal threats, credential leaks, and weak password hygiene become direct paths to system compromise. You can't just firewall your way out of this one.

Why It Matters

FreePBX powers phone systems for small businesses, enterprises, service providers, and critical infrastructure operators. When 900 instances fall simultaneously, you're looking at potential eavesdropping on calls, call interception, toll fraud, and lateral movement into internal networks via VoIP infrastructure.

This is particularly nasty because VoIP systems often occupy a trust zone that network teams forget to monitor aggressively. The phone system talks to everything—workstations, servers, mobile clients. A compromised FreePBX instance becomes a beachhead.

And the web shells? Those are bread and butter for persistent attackers. Long-term access, command execution, data exfiltration—all without touching the PBX system itself once the shell's in place.

Next Steps

If you're running FreePBX, assume you need a patch immediately. Check your endpoint manager logs for unusual command execution, authentication anomalies, and web requests to suspicious files. Look for web shells in the web root and any new user accounts created during the compromise window.

Rotate credentials for any accounts that could access the endpoint manager. Segment your VoIP infrastructure from your core network if you haven't already. And audit which systems have access to FreePBX—because if attackers are in, the question isn't whether they'll move laterally, it's where they're moving.

Frankly, this should have been caught sooner. Post-authentication command injection in a management interface isn't subtle. Check your monitoring. If you missed this on your own systems, that's a separate conversation you need to have with your security team.

Read original article →

// FAQ

How can I tell if my FreePBX system was infected with web shells?

Check your endpoint manager logs for unusual command executions, look for unexpected files in your web directories (typically /var/www/html), and review authentication logs for anomalous access patterns. Use file integrity monitoring tools to detect changes to system files and web shell artifacts.

Does the Sangoma FreePBX authentication bypass vulnerability require a password reset?

Yes. Even if you patch the vulnerability, rotate all credentials that can access the endpoint manager interface, as the attack required valid authentication credentials that may have been compromised or leaked.

What should I do if my FreePBX instance was compromised?

Immediately isolate the system from the network, deploy a patch when available, conduct forensic analysis to determine what data or systems were accessed, and perform a complete audit of all connected infrastructure for lateral movement indicators.

Concerned about your project's security? Run an automated pentest with AISEC — AI-powered scanner with expert verification. Go to dashboard →