Security Advisory · Published 2026-05-29

FreePBX May 2026 CVEs: a 15-minute self-check that won't break your phones

Four FreePBX CVEs dropped together on May 29. One is a pre-auth UCP takeover via hard-coded credentials (9.3). One is SQL injection in CDR Reports (8.5). The OAuth2 implementation accepts any client secret (7.6). The Dashboard module has a PHP path traversal (7.6). This audit is ordered by operational risk: takeover first, call records second, then config and log checks.

Why this matters for operators

FreePBX often sits in the background until phones stop working or a SIP bill spikes. If UCP is internet-facing, stale credentials and exposed reports can become a business outage, not just a software maintenance issue.

This four-CVE cluster deserves a same-day check: confirm the patch line, review UCP access, and look for unusual call/report activity before normal traffic hides the signal.

The four CVEs, in plain English

Official advisories are linked at the bottom. This section keeps the checks focused on what the system owner can verify safely.

CVE-2026-46376 — UCP hard-coded credentials (CVSS 9.3, Critical)

FreePBX ships UCP with a generic initial template account. The administrator is expected to change those credentials immediately after enabling UCP. A lot of admins don't. If your UCP install came from a version between 15.0.42 and the patch line (16.0.45 / 17.0.7), and you never changed the template creds, anyone on the internet who knows the default username and password can log into your UCP. From there they can read voicemail, change call-forwarding rules, listen to call recordings, and pivot into the rest of the system.

This is the one that wakes up scanner authors first. If you only have time to check one of these four today, check this one.

CVE-2026-44238 — CDR Reports SQL injection (CVSS 8.5, High)

The CDR Reports module passes the order and sort POST parameters straight into the database query. An attacker with a FreePBX admin account that has CDR section access (not full admin — just enough to see billing reports) can extract anything in the FreePBX database. Including the password hashes of every other admin and every SIP secret.

MSPs hand out CDR access to billing staff routinely. If your customer's accountant has a login that can see call reports, that account is now a privilege-escalation vector. Patched in 16.0.50 / 17.0.11.

CVE-2026-44237 — OAuth2 accepts any client secret (CVSS 7.6, High)

The API module's OAuth2 implementation validates client_id against the database, then calls validateClient() to check the matching secret. The method unconditionally returns true. So if an attacker knows a valid client_id, they get an access token without knowing the matching secret. client_id values are often visible in client-side JavaScript, mobile app bundles, and integration documentation. Patched in 17.0.8.

CVE-2026-44239 — Dashboard module path traversal (CVSS 7.6, High)

The Dashboard's getcontent AJAX handler reads rawname from $_REQUEST and concatenates it into a PHP include() call with a .class.php suffix. ../ sequences let you point that include at any .class.php file on the filesystem the web user can read. The included file's PHP code runs before the inevitable class-instantiation error gets thrown. Requires an authenticated admin, but combined with the other three, that's not a high bar. Patched in 16.0.22 / 17.0.5.

The 15-minute self-check I actually run

Five steps. SSH into your FreePBX box for steps 2–5, or run them from the FreePBX web console's System Admin → Terminal if you have it. Step 1 you can do from any browser. None of this probes or attacks anything. Just reads.

Step 1: Check your FreePBX version from outside

Open Ping7's HTTP Status Checker and fetch https://your-pbx-hostname/admin/. The login page usually returns either a version string in the HTML or a recognisable layout. If the page is reachable from the public internet without any IP allow-list, that alone is worth fixing. Phone systems do not need to be browsable from Romania, Tunisia, or anywhere your business doesn't operate.

While you're there, run Ping7's SSL Checker against the same URL. An expired cert, self-signed cert, or one that doesn't match the hostname is a tell that nobody's been maintaining the server.

Step 2: Verify your exact FreePBX version on the box

SSH in and run: 

fwconsole ma list | head -5

That gives you the FreePBX module manager output. The very first line of fwconsole --version tells you which FreePBX major version you're on. Compare against the patched-version table at the top of the article. If you're below the patched version for any of the four CVEs, you're exposed to that CVE.

A version like 16.0.40 means you have CVE-2026-46376 (patched in 16.0.45) and CVE-2026-44238 (patched in 16.0.50) and CVE-2026-44239 (patched in 16.0.22 — so this one you're probably fine on). 17.x users with anything below 17.0.11 are exposed to at least CVE-2026-44238.

Step 3: Audit the UCP for template-default accounts

This is the one that matters most. SSH in and check the UCP user table: 

fwconsole userman --list

Look for any account whose username matches the FreePBX initial template defaults (anything that smells like admin, template, user1, ucp_default, or numerical placeholders). Anything you don't recognise. Anything that hasn't logged in for over a year but is still active.

If you find a default-template account, force a password reset on it immediately, or disable it entirely if nobody's using it: 

fwconsole userman --disableUser USERNAME

Don't delete first. Disable, watch logs for 48 hours, then delete if nothing complains. Deleting a UCP user that an extension is still bound to can leave that extension in a half-broken state.

Step 4: Check who has CDR access

CVE-2026-44238 needs an admin account with CDR section permission. Open the FreePBX admin console, navigate to Admin → Administrators, and look at every account in there. For each one, click in and check the section permission grid. Anyone who has CDR Reports access and is not a fully trusted admin is now a SQL injection vector.

For the cleanup: either revoke CDR access for non-admin accounts until you've patched, or patch the box first and then leave the permissions alone. I prefer patching first because revoking permissions in a live billing workflow tends to break Monday morning for someone.

Step 5: Sweep the logs for unusual activity

Two log files matter here: 

tail -500 /var/log/asterisk/full | grep -i ucp
tail -500 /var/log/httpd/access_log | grep -E "rawname|order=|sort="

On Debian-based installs the second path is /var/log/apache2/access.log. Look for UCP login attempts from IPs you don't recognise. Look for HTTP requests with rawname containing ../. Look for POST requests to the CDR endpoint with unusual order or sort parameter values containing quotes, semicolons, or SQL keywords.

If you find any of those, don't panic. Snapshot the log files (cp /var/log/asterisk/full /root/full-snapshot-2026-05-29), then move to the incident response section below.

If something looks weird, do this in order

  1. Patch first. fwconsole ma upgradeall followed by fwconsole reload. Asterisk will pause for a few seconds. That's fine. Active calls survive a reload, but new calls may queue. Schedule outside business hours if you can. If you can't, do it anyway — a compromise hurts more than a thirty-second blip.
  2. Force a password reset for every admin and UCP account. Don't trust any existing session. Kick everyone out and require new passwords. Enable 2FA on admin accounts if FreePBX supports it for your version (16.x and up does).
  3. Lock down network access. The FreePBX admin interface and UCP do not need to be reachable from the public internet. Put them behind a VPN or an IP allow-list. iptables is fine. Cloudflare Access in front of nginx is better for distributed teams.
  4. Check for new admin accounts and unexpected SIP extensions. fwconsole userman --list for users. The FreePBX admin console's Extensions page for SIP/PJSIP entries. Anything you don't recognise either belongs to a customer you forgot about, or to an attacker who set up an extension to ring out toll-fraud calls. Diff the list against the last known-good config.
  5. Check the call records for fraud patterns. Pull up CDR Reports for the last 14 days. Sort by destination. Look for any batch of calls to country codes your business doesn't use. Premium-rate numbers (anything starting with international premium prefixes) are the classic signal. If you see them, you're almost certainly already compromised, and the next step is calling your SIP trunk provider to freeze the account before more charges accrue.
  6. If you suspect active intrusion, isolate the box. Take it off the public internet. Snapshot the disk before you do anything destructive. If this is deep, you'll want professional incident response, not a Reddit thread.

Long-term hardening that makes the next CVE less painful

  • FreePBX admin and UCP behind a VPN or IP allow-list. Period. There is no business reason for these to be reachable from anywhere on Earth.
  • Auto-update modules monthly via fwconsole ma upgradeall in a cron job. Yes, FreePBX updates occasionally regress things. The trade-off is still worth it.
  • SIP trunk credentials rotated annually. Toll fraud is the way attackers monetise FreePBX compromises, and rotated trunk creds reduce the blast radius.
  • Outbound dial plan with explicit country allow-lists. If you only call US/UK customers, block everything else at the dialplan level. Asterisk's exten patterns handle this in under twenty lines.
  • fail2ban with the asterisk jail enabled. The default jail catches most UCP and SIP brute force attempts.
  • Centralised logging to a server the FreePBX box doesn't control. If the box gets owned, you still have the logs.
  • Off-box backups of the Asterisk config and the FreePBX database. Daily. Tested quarterly. A backup you've never restored is a wish, not a backup.

Frequently asked questions

Will fwconsole ma upgradeall break anything?

Sometimes. FreePBX module upgrades occasionally regress in third-party modules. The mainline modules are usually solid. I run upgrades in a snapshot/restore-friendly environment and recommend you do too. If you don't have snapshots, take a full backup (fwconsole backup --backup default) before the upgrade. Then run the upgrade. If something breaks, restore the backup.

Do I need to upgrade Asterisk too?

Not for these specific CVEs. All four are in FreePBX itself (the web/PHP layer), not Asterisk. But while you're patching, check whether you're on a current LTS Asterisk version. Anything below Asterisk 20 LTS is getting close to end-of-life.

How do I tell if my UCP was already abused?

Pull the UCP audit log from /var/log/asterisk/freepbx_security.log. Look for successful logins from IPs outside your normal user geography. Look for changes to call forwarding rules you didn't make. Listen to a sample of recent voicemails that haven't been retrieved — sometimes attackers leave them intact rather than tipping their hand by deleting messages.

I'm running a really old FreePBX. Like 14 or 15. What do I do?

Migrate. FreePBX 14 reached end of life in 2022. 15 hits end of life around the time of these CVEs. There are no patches coming. Spin up a fresh FreePBX 17 box, port your extensions and trunks over, test thoroughly, and cut over during a maintenance window. It's a weekend of work. The alternative is running unpatched on a CVE pipeline that's clearly still active.

Can Ping7 do this for me?

Yes. See the CVE repair page. The most common engagement on a CVE cluster like this is the $399 Full Patch Package: we audit your version, patch the four CVEs, run the IOC checklist, send you a written report you can give the customer or your manager. Two to four hours of work on a typical box. We don't sell scary, we sell quiet. We patch, we verify, we leave you a report, we move on.

What I'd do if I were you, in order of urgency

  1. Today: SSH in. Check version. Patch if you're below the lines listed at the top. Force password reset on UCP. Lock the admin interface behind a VPN if it isn't already.
  2. This week: Audit UCP user list. Revoke CDR access for non-admins. Sweep the logs. Enable fail2ban with the Asterisk jail.
  3. This month: Country-code allow-list in the outbound dialplan. SIP trunk credential rotation. Off-box backup verification.
  4. This quarter: If you're on FreePBX 14 or 15, plan the migration to 17.

References

Ping7 is not affiliated with FreePBX, Sangoma, or any VoIP vendor. All trademarks belong to their owners. This guide references public CVE data and operational best practices only. No proof-of-concept exploit code or attack steps are included or referenced.