CVE-2025-57819, FreePBX Pre-Auth RCE and the PBX Blast Radius

CVE-2025-57819 is the kind of PBX vulnerability that deserves faster handling than a normal web admin bug. It affected FreePBX 15, 16, and 17 through the commercial Endpoint Manager module, allowed unauthenticated access into FreePBX Administrator logic, and could lead to arbitrary database manipulation and remote code execution. The official GitHub advisory lists patched Endpoint Manager versions as 15.0.66, 16.0.89, and 17.0.3; NVD records a CVSS v3.1 score of 9.8 and a CNA CVSS v4.0 base score of 10.0. (GitHub)

The important part is not only “RCE.” FreePBX often sits in the middle of voice infrastructure, SIP trunks, extensions, voicemail, help desk workflows, call routing, and sometimes provider-managed customer systems. A compromised PBX can become a billing-fraud engine, a credential source, a call-disruption point, or a pivot into networks that were never designed to treat telephony as hostile. The FreePBX community advisory said unauthorized access began on or before August 21, 2025 against multiple FreePBX 16 and 17 systems that were directly connected to the public internet and had inadequate IP filtering or ACLs. (GitHub)

The facts that matter first

Item	What security teams need to know
CVE	CVE-2025-57819
Product area	FreePBX Endpoint Manager, also referred to as the endpoint module in advisories
Main impact	Unauthenticated access to FreePBX Administrator paths, arbitrary database manipulation, and remote code execution
Affected supported branches	FreePBX 15, FreePBX 16, FreePBX 17
Patched Endpoint Manager versions	15.0.66, 16.0.89, 17.0.3
Weakness classes	CWE-89 SQL injection and CWE-288 authentication bypass as recorded by NVD
Exploit status	Reported exploitation in the wild, added to CISA KEV on August 29, 2025
Most urgent mitigations	Upgrade the module, restrict FreePBX Administrator access, check IOCs, rotate credentials, investigate exposed systems as potentially compromised
High-value IOCs	/var/www/html/.clean.sh, missing or modified /etc/freepbx.conf, POST requests to modular.php, unusual calls to extension 9998, suspicious ampusers, suspicious cron_jobs

The official advisory says the issue came from insufficient sanitization of user-supplied data, allowing unauthenticated access to FreePBX Administrator and leading to database manipulation and RCE. NVD also records CISA KEV metadata, including an August 29, 2025 addition date and a September 19, 2025 remediation due date for U.S. federal civilian executive branch agencies under the KEV process. (GitHub)

Why a FreePBX bug is different from a normal web panel bug

FreePBX is a web-based open-source GUI used to manage Asterisk, the open-source PBX and VoIP server. The Asterisk Exchange description is plain: FreePBX controls and manages Asterisk and can be installed manually or as part of a preconfigured FreePBX Distro with the operating system, Asterisk, the FreePBX GUI, and dependencies. (Asterisk)

That architecture gives attackers several reasons to care. A PBX is not just a web app. It is an operations system that decides who can call, where calls route, which trunks are used, which extensions exist, how voicemail works, and how devices are provisioned. It can hold secrets that are valuable outside the PBX itself: SIP trunk credentials, extension passwords, voicemail PINs, contact data, call detail records, internal naming conventions, and sometimes VPN or management hints left by administrators.

The blast radius is also different. A compromised CMS might leak content or become a phishing page. A compromised PBX can generate fraudulent international calls, intercept call metadata, disrupt customer support, break emergency or after-hours routing, and create a foothold on a system that administrators may not monitor with the same rigor as laptops, domain controllers, or cloud workloads. This is why CVE-2025-57819 should be treated as both an application security incident and a communications infrastructure incident.

Affected versions and patch levels

The official GitHub advisory identifies the vulnerable packages and patched Endpoint Manager versions as follows. (GitHub)

FreePBX branch	Vulnerable Endpoint Manager versions	Patched Endpoint Manager version	Practical note
FreePBX 15	Less than 15.0.66	15.0.66	Update the module even if the system appears stable
FreePBX 16	Less than 16.0.89	16.0.89	Systems exposed to the internet should also be checked for compromise
FreePBX 17	Less than 17.0.3	17.0.3	Confirm automated update behavior because update notification issues were noted for some v17 framework module conditions
End-of-life branches	Untested	Not a reliable security state	Upgrade to a supported version rather than assuming non-listed versions are safe

A common mistake is to read the version table as a narrow inventory exercise. The right question is not only “Is the module patched now?” The better question is “Was this system reachable before it was patched?” If FreePBX Administrator was exposed directly to the internet before the fixed module landed, the system needs IOC review and likely credential rotation, not just a module update.

The community advisory explicitly urged administrators to determine whether FreePBX or PBXAct systems were exposed to the public internet, activate firewall controls, lock access down to trusted hosts, and verify access from an external device. It also recommended immediate updates through Module Admin or fwconsole ma upgradeall. (FreePBX Community Forums)

# Update all FreePBX modules using the supported CLI path.
# Run as root, or use sudo where appropriate.
fwconsole ma upgradeall

# Confirm the installed endpoint module version.
fwconsole ma list | grep -i endpoint

Do not stop at the version check. A patched system can still carry attacker-created users, suspicious scheduled jobs, tampered logs, or exposed credentials if it was compromised before the update.

The vulnerability chain, without the hype

At a high level, CVE-2025-57819 combined three ideas:

Stage	What happens	Why it matters
Pre-auth reachability	An attacker reaches code paths that should not be meaningfully reachable without a valid session	The attack starts before normal admin authentication protects the workflow
SQL injection	User-controlled input reaches database query logic without adequate neutralization	The attacker can manipulate sensitive FreePBX database state
Execution path	Database manipulation can affect users, scheduled jobs, or other execution-adjacent behavior	Database write access becomes operational control, and in some paths RCE

NVD classifies CVE-2025-57819 under CWE-89 and CWE-288, which is a useful way to think about it. CWE-89 describes improper neutralization of special elements used in SQL commands. CWE-288 describes authentication bypass using an alternate path or channel. Together, they capture the real problem: the attacker did not simply guess a password, and the attacker did not need a normal admin session first. (NVD)

watchTowr’s later technical analysis found that /admin/ajax.php normally rejects unauthenticated requests with a 401 response, but the module routing and custom class-loading behavior exposed a more subtle path into module .php files. Their writeup states that FreePBX’s custom class loader could include files ending in .php from the admin/modules location, allowing certain module files to be hit without logging in. (watchTowr Labs)

That distinction matters for defenders because it explains why purely checking “Can I log in?” is weak evidence. The vulnerable path was not the same as a normal browser login. It was a module dispatch and database-manipulation problem reachable through FreePBX’s request-handling behavior.

Why SQL injection became remote code execution

SQL injection is often described as “database access,” but in management systems the database can be part of the control plane. FreePBX stores administrative users, module state, configuration, scheduled behavior, and other operational data in ways that affect what the PBX later does. If an attacker can write into the right tables, database access can become application control.

Public research connected CVE-2025-57819 exploitation to two especially important database effects. One was creation of unexpected administrative users in ampusers. The other was insertion of scheduled jobs into cron_jobs, where a command field could later be executed by the PBX environment. watchTowr described a path where adding a row to cron_jobs with a frequent schedule could cause a command to run, completing the SQL injection to RCE chain. (watchTowr Labs)

For a production defense team, the lesson is simple: do not treat this as only a patching task. Affected systems should be examined for persistent state changes. Users, scheduled jobs, PHP files, web-root changes, shell history, SSH keys, systemd units, cron entries, and call records all matter.

A safe investigation should not replay public exploit requests against production systems. It should rely on version checks, log review, database review, configuration review, and controlled validation in a lab or authorized test environment. Public proof-of-concept material and detection artifact generators can be useful for defenders, but running exploit-style checks against live PBX systems can create operational damage, add suspicious artifacts, or make forensic timelines harder to interpret.

What exploitation looked like in the wild

The exploitation timeline matters because some organizations patched after public disclosure and assumed that was enough. The FreePBX GitHub advisory says unauthorized access began on or before August 21, 2025. The community thread and government advisories emphasized that administrators should check for compromise indicators, not only update. (GitHub)

The most useful IOCs are not subtle:

IOC	Where to look	Why it matters
/var/www/html/.clean.sh	Web root	A cleanup script should not exist on normal systems and was linked to log tampering
Modified or missing /etc/freepbx.conf	Filesystem	This file is central to FreePBX behavior, and unexpected changes may indicate compromise
POST requests to modular.php	Apache/httpd access logs	FreePBX guidance says these are likely not legitimate traffic
Calls to extension 9998	Asterisk logs and CDRs	Unusual unless the organization intentionally configured that extension
Unknown users in ampusers	MariaDB/MySQL asterisk database	Attackers were associated with suspicious admin user creation
Suspicious rows in cron_jobs	MariaDB/MySQL asterisk database	Database-driven scheduled commands can create persistence or RCE effects
Unknown PHP files	Web root and module paths	Web shells are a common post-exploitation artifact

The Singapore Cyber Security Agency alert listed the same core indicators: recent modification or absence of /etc/freepbx.conf, the presence of /var/www/html/.clean.sh, suspicious POST requests to modular.php, unusual calls to extension 9998, and suspicious ampuser users or unknown users in the ampusers table. (Cyber Security Agency of Singapore)

watchTowr also published the observed .clean.sh behavior. The script iterated through log paths and removed lines matching strings such as .cache, modular.php, monitor.php, and backend.php, then attempted to remove itself. That is classic post-exploitation cleanup: erase traces of web-shell and control activity, then disappear. (watchTowr Labs)

Fast triage for exposed FreePBX systems

The first triage question is exposure, not patch status. If the FreePBX Administrator interface was reachable from the public internet before the fix, assume higher risk until evidence says otherwise.

Use an external network, not the PBX host itself, to validate management-plane exposure. A phone on cellular data, a trusted external scanner, or a controlled bastion outside the protected network can answer a basic question: can the Admin UI be reached without VPN or allowlist membership?

# From a trusted external host, check whether the FreePBX admin path is reachable.
# This does not test exploitability. It only checks exposure.
curl -k -I https://pbx.example.com/admin/

# Check HTTP as well if the environment historically used it.
curl -I http://pbx.example.com/admin/

If the response shows a reachable web service, that is not automatically proof of compromise. It is proof that the attack surface existed. The next step is to combine exposure, version history, module status, logs, and database artifacts.

On the FreePBX host, confirm the installed module version:

fwconsole ma list | grep -i endpoint
fwconsole --version

Then search for the high-signal filesystem indicators:

# A normal system should not have this file.
ls -l /var/www/html/.clean.sh

# Check whether the core FreePBX config file exists and when it changed.
ls -l /etc/freepbx.conf
stat /etc/freepbx.conf

# Look for recently changed PHP files in common web paths.
find /var/www/html -type f -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %TT %p\n" | sort

Search web logs across Apache naming variations. The FreePBX community advisory first suggested checking Apache logs for modular.php and later expanded the command to include both httpd and apache2 log paths. (FreePBX Community Forums)

# Search compressed and uncompressed access logs.
zgrep -i "modular.php" /var/log/{httpd,apache2}/*access* 2>/dev/null

# Also search for suspicious direct access to admin ajax routing.
zgrep -Ei "POST /admin/(ajax|config|modular)\.php|module=.*endpoint" \
  /var/log/{httpd,apache2}/*access* 2>/dev/null

Search Asterisk logs and CDR data for the extension called out in official guidance:

grep -R "9998" /var/log/asterisk/full* 2>/dev/null

Check the database for unexpected FreePBX users and scheduled jobs. Use read-only queries first. Do not delete suspicious rows until evidence is preserved.

# Review FreePBX admin users.
mysql -e "SELECT username, extension, deptname, sections FROM ampusers;" asterisk

# Review scheduled jobs for suspicious commands.
mysql -e "SELECT id, modulename, jobname, command, schedule, enabled FROM cron_jobs;" asterisk

If any of these indicators appear, treat the host as potentially fully compromised. Snapshot it, preserve logs, rotate credentials, and plan for rebuild or known-good restore.

Detection engineering examples

Security teams with SIEM coverage should turn CVE-2025-57819 into detections that survive beyond the disclosure week. PBX servers are often under-monitored, so even simple log rules can have outsized value.

A Splunk search for suspicious FreePBX admin activity might start with URI and method patterns:

index=web sourcetype=access_combined
(host="pbx*" OR uri_path="/admin/ajax.php" OR uri_path="/admin/modular.php")
(
  uri_path="/admin/modular.php"
  OR uri_query="*module=*endpoint*"
  OR uri_query="*FreePBX%5Cmodules%5Cendpoint*"
  OR uri_query="*FreePBX\\modules\\endpoint*"
)
| stats count earliest(_time) as first_seen latest(_time) as last_seen values(src_ip) as src_ip by host, uri_path, uri_query, status
| convert ctime(first_seen) ctime(last_seen)

An Elastic or OpenSearch KQL query can be kept broad at first:

url.path:("/admin/ajax.php" or "/admin/modular.php" or "/admin/config.php")
and (
  http.request.method:POST
  or url.query:*endpoint*
  or url.query:*FreePBX*
  or url.query:*modules*
)

A filesystem monitoring rule should alert on web-root shell artifacts and FreePBX config changes:

# Minimal Linux audit idea for teams using auditd.
# Tune paths and noise before enforcing in production.
auditctl -w /var/www/html -p wa -k freepbx_webroot_write
auditctl -w /etc/freepbx.conf -p wa -k freepbx_conf_change
auditctl -w /var/spool/cron -p wa -k cron_change

The key is correlation. A single /admin/ajax.php request may be normal. A burst of POST requests to unusual FreePBX admin paths from an unknown IP, followed by .clean.sh, new PHP files, new ampusers, or changed cron_jobs, is much stronger evidence.

What to do when an IOC is found

The wrong response is to delete the suspicious file and move on. If CVE-2025-57819 exploitation succeeded, attackers may have obtained database control, PBX admin access, shell execution, SIP secrets, and a chance to tamper with logs.

A practical response sequence looks like this:

Step	Action	Rationale
1	Remove public access to FreePBX Administrator immediately	Stops further unauthenticated exploitation and opportunistic follow-on activity
2	Snapshot the system or preserve a forensic image where feasible	Avoids destroying evidence before scope is known
3	Export relevant logs and database evidence	Web logs, Asterisk logs, CDRs, ampusers, cron_jobs, auth logs, shell history, SSH keys
4	Update supported FreePBX modules or rebuild to a clean supported version	Patching closes the known vulnerable module path
5	Rotate credentials	Assume PBX, SIP, trunk, voicemail, SSH, database, and admin credentials may have been exposed
6	Review call records and provider bills	Toll fraud can become the most visible business impact
7	Restore from a known-good backup or rebuild the host	A normal FreePBX backup may not remove system-level persistence
8	Retest exposure and patch state	Confirm the Admin UI is no longer publicly reachable and the endpoint module is fixed

The FreePBX community advisory specifically recommended preserving backups from before the infection, installing a new system with sufficient firewalling and a fixed Endpoint Manager module, restoring a backup to it, rotating all passwords including system, SIP trunks, users, extensions, voicemail, and UCP, and checking CDRs and telco bills, especially international calling. (FreePBX Community Forums)

That advice is worth following even if the system appears to be working. Community reports noted that some compromised systems showed obvious breakage, while others kept functioning with fewer visible symptoms. (FreePBX Community Forums)

Why restoring a FreePBX backup may not be enough

A FreePBX application backup is not the same as a clean operating-system rebuild. If attackers gained command execution, they could have added SSH keys, changed systemd units, modified cron, dropped binaries, changed PHP files, or installed persistence outside the scope of a normal application restore.

The community incident note warned that a “full backup restore” did not necessarily mean the system was clean if attackers persisted outside the restored data. It recommended a true full restore that includes OS and system-level binaries, or rebuilding the system and re-applying configuration and data from known-good sources. (Gist)

For many small teams, rebuilding a PBX is painful. Phone systems are often full of historical exceptions, device quirks, extension mappings, trunk settings, and emergency routing rules. Still, if there is evidence of code execution, rebuilding is often safer than trying to surgically clean a host while attackers may have altered logs and persistence.

Hardening the FreePBX management plane

The most reliable mitigation is boring: do not expose FreePBX Administrator directly to the internet. Strong passwords are not enough for a pre-auth vulnerability. MFA is helpful, but not sufficient if a bug bypasses the authentication path before MFA participates. Admin access should sit behind a VPN, ZTNA gateway, bastion, or strict IP allowlist.

A basic network policy should enforce the following:

Control	Recommended state	Why it matters
Admin UI exposure	Private only, reachable through VPN, ZTNA, or trusted IPs	Reduces reachability for pre-auth bugs
HTTP	Disabled or redirected to HTTPS where possible	Avoids credential leakage and downgrade habits
SIP trunks	Restricted to provider IP ranges where feasible	Reduces abuse and scanning noise
SSH	Key-based, allowlisted, no password login	Limits post-exploitation reuse of guessed or stolen credentials
Module footprint	Remove unused modules, especially commercial modules not needed	Smaller code and route surface
Updates	Regular module and OS patch cadence	FreePBX security fixes may arrive as module updates, not only OS packages
Logging	Centralized and retained	Local logs may be altered by cleanup scripts
Backups	Tested restores, offline or isolated copies	Recovery matters more when PBX availability affects operations

Example Apache allowlisting can be useful when FreePBX is behind Apache and the environment has stable admin source IPs. This is not a replacement for vendor-supported firewalling, but it illustrates the control objective:

# Example only. Validate with your FreePBX and Apache version before use.
# Prefer product-supported firewall controls where available.

<Location "/admin">
    Require ip 203.0.113.10
    Require ip 198.51.100.24
</Location>

For Nginx reverse proxy deployments, the same idea applies:

# Example only. Use with care and test before production deployment.

location /admin/ {
    allow 203.0.113.10;
    allow 198.51.100.24;
    deny all;

    proxy_pass http://127.0.0.1:8080/admin/;
}

The real control is not the syntax. The real control is making sure the Admin UI is not reachable by the whole internet.

Verifying remediation without creating new risk

Security validation for CVE-2025-57819 should be staged.

First, validate exposure. Confirm that the FreePBX Administrator interface is not reachable from untrusted networks. Second, validate patch state. Confirm the Endpoint Manager version meets the fixed version for the installed FreePBX branch. Third, validate historical compromise. Review filesystem, web logs, Asterisk logs, CDRs, users, scheduled jobs, and system persistence. Fourth, validate post-remediation state from outside the network.

Do not use destructive exploit payloads against production systems. A safe validation workflow can still answer the important questions:

# 1. Confirm module version.
fwconsole ma list | grep -i endpoint

# 2. Confirm public exposure from an external trusted host.
curl -k -I https://pbx.example.com/admin/

# 3. Review key IOCs.
ls -l /var/www/html/.clean.sh /etc/freepbx.conf 2>/dev/null
zgrep -i "modular.php" /var/log/{httpd,apache2}/*access* 2>/dev/null
grep -R "9998" /var/log/asterisk/full* 2>/dev/null

# 4. Review database state.
mysql -e "SELECT username, extension, deptname, sections FROM ampusers;" asterisk
mysql -e "SELECT id, modulename, jobname, command, schedule, enabled FROM cron_jobs;" asterisk

For authorized security teams that need to repeat this kind of work across many assets, the hard part is rarely one command. It is keeping discovery, exposure checks, validation, evidence capture, remediation notes, and retesting tied together. Penligent’s site describes an agentic AI pentesting workflow that can scan for recent CVEs, generate one-click PoC exploit scripts, map attack surfaces, verify findings, and produce evidence-first reports; its AI Pentest page also describes blackbox endpoint mapping, independent sub-agent validation, and reports with impact, reproduction steps, evidence, and remediation guidance. That kind of workflow is only appropriate inside explicitly authorized scopes, but it matches the operational need created by bugs like CVE-2025-57819: prove exposure, preserve evidence, fix, and prove the fix. (Penligent)

Related FreePBX CVEs that change the risk picture

CVE-2025-57819 should not be analyzed in isolation. Later research and advisories around FreePBX showed additional weaknesses involving authentication configuration, SQL injection, and file upload. These do not replace CVE-2025-57819, but they help explain why defenders should harden the whole FreePBX management plane rather than patch one module and forget it.

CVE	What it affects	Exploitation condition	Impact	Fixed versions
CVE-2025-57819	FreePBX Endpoint Manager in FreePBX 15, 16, 17	Network reachability, no authentication required in the vulnerable chain	FreePBX Administrator access, database manipulation, RCE	Endpoint Manager 15.0.66, 16.0.89, 17.0.3
CVE-2025-66039	FreePBX authentication when auth type is set to webserver	Requires webserver authentication type, not default according to Horizon3.ai	Authorization header can associate a session with a target user without valid credentials	16.0.44, 17.0.23
CVE-2025-61675	Endpoint Manager SQL injection points	Authenticated with a known username	Arbitrary SQL queries, sensitive data access, database modification	16.0.92, 17.0.6
CVE-2025-61678	Endpoint Manager arbitrary file upload via fwbrand path behavior	Authenticated with a known username	Arbitrary file upload and possible web shell leading to RCE	16.0.92, 17.0.6

NVD describes CVE-2025-66039 as an authentication bypass when FreePBX uses the webserver authentication type, where an Authorization header with an arbitrary value can associate a session with the target user regardless of valid credentials; NVD lists fixes in 16.0.44 and 17.0.23. (NVD)

NVD describes CVE-2025-61675 as authenticated SQL injection affecting multiple Endpoint Manager functionality areas, including basestation, model, firmware, and custom extension configuration, with fixes in 16.0.92 and 17.0.6. (NVD)

NVD describes CVE-2025-61678 as an authenticated arbitrary file upload issue affecting the fwbrand parameter, allowing attacker-controlled paths and potentially web shell upload, with fixes in 16.0.92 and 17.0.6. (NVD)

Horizon3.ai’s updated analysis connects these vulnerabilities as chained paths in certain configurations: authentication bypass to SQL injection, or authentication bypass to file upload RCE. It also states that CVE-2025-57819 affects FreePBX in its default configuration, while CVE-2025-66039 depends on the non-default webserver authentication type. (Horizon3.ai)

The takeaway is not that every FreePBX instance is vulnerable to every chain. The takeaway is that FreePBX has multiple management-plane pathways where authentication assumptions, module routing, SQL handling, and file handling interact. Defenders should verify configuration, module versions, exposed routes, and reachable management paths together.

Why PBX compromise can turn into fraud

Security teams often frame RCE as the final outcome. In a PBX environment, RCE is often the beginning of the business problem.

A compromised FreePBX host can expose:

Asset	Potential abuse
SIP trunk credentials	Toll fraud, unauthorized outbound calls, provider abuse
Extension credentials	Internal impersonation, voicemail access, call routing manipulation
Voicemail data	Sensitive message exposure
Call detail records	Metadata leakage, customer relationship mapping
Admin users	Persistent control over the PBX
Device provisioning data	Phone compromise or rogue endpoint registration
Network position	Pivoting into less-monitored internal segments

Toll fraud deserves special attention. Attackers may place expensive calls to premium-rate destinations, international numbers, or attacker-controlled routes. The damage can appear as a phone bill before it appears as a security alert. That is why response playbooks should include telecom provider coordination, call-rate limits, international call restrictions, and CDR review.

Common mistakes during CVE-2025-57819 response

The first mistake is patch-only thinking. Updating Endpoint Manager is necessary, but it does not remove attacker-created users, scheduled jobs, web shells, or stolen credentials. If the Admin UI was exposed before patching, the system needs evidence review.

The second mistake is trusting the absence of one IOC. If .clean.sh is missing, the host may still have been compromised. The script may have removed itself, failed to run, been replaced, or never been used in a particular intrusion. Use multiple evidence sources.

The third mistake is restoring a FreePBX application backup onto a still-compromised operating system. If attackers achieved shell execution, persistence may live outside FreePBX application data.

The fourth mistake is failing to rotate telecom secrets. SIP trunk credentials, extension passwords, voicemail PINs, UCP passwords, and provider portal credentials should be considered at risk if compromise is confirmed.

The fifth mistake is leaving the Admin UI exposed after patching. A future pre-auth bug may not care how strong the password is. Reduce reachability.

The sixth mistake is not reviewing phone bills and CDRs. Some PBX intrusions are financially motivated. A clean web root does not prove there was no call fraud.

A practical remediation checklist

Use this checklist as a working sequence, not a substitute for incident response judgment.

Priority	Task	Done
1	Remove public internet access to FreePBX Administrator
2	Confirm Endpoint Manager is at or above 15.0.66, 16.0.89, or 17.0.3 depending on branch
3	Preserve logs, database exports, and a system snapshot if compromise is suspected
4	Search for .clean.sh, modified /etc/freepbx.conf, suspicious PHP files, and unusual web-root changes
5	Search web logs for modular.php, suspicious /admin/ajax.php module routing, and unusual POST traffic
6	Search Asterisk logs and CDRs for extension 9998 and abnormal outbound call patterns
7	Review ampusers for unknown users
8	Review cron_jobs for unexpected commands
9	Review SSH keys, systemd units, user accounts, cron entries, and listening services
10	Rotate FreePBX admin, UCP, SIP trunk, extension, voicemail, SSH, database, and provider credentials
11	Coordinate with telecom providers to detect or block fraudulent call routes
12	Rebuild or restore from a known-good system image if compromise is confirmed
13	Retest exposure and patch state from outside the network
14	Add monitoring for future admin-route access and PBX-specific anomalies

A good security report for CVE-2025-57819 should include the version state, exposure state, IOC results, evidence timestamps, remediation action, credentials rotated, provider/billing review status, and retest result. Do not write “patched” when the system was merely updated. Write what was proven.

Safe lab reproduction versus production validation

There is a place for exploit reproduction: an isolated lab, an owned system, a customer-approved test environment, or a dedicated clone created for validation. There is also a place where exploit reproduction does not belong: a live production PBX handling customer calls.

A safe lab setup can help teams understand the vulnerability chain and test detections. A production validation should answer narrower questions:

Question	Safe production method
Is the system still exposed?	External reachability check of /admin/
Is the vulnerable module still installed?	fwconsole ma list
Was the system possibly exploited?	IOC and log review
Did attackers create users?	Read-only ampusers query
Did attackers add scheduled commands?	Read-only cron_jobs query
Are there web shells?	Filesystem review and integrity checks
Did call fraud occur?	CDR and provider bill review
Is remediation complete?	Patch confirmation, access control confirmation, credential rotation evidence

This distinction matters because public exploit tooling can create artifacts by design. Some detection artifact generators intentionally add a user or create a web shell to prove exploitability. That may be useful in a lab, but it is a poor default on a production phone system.

What defenders should monitor after cleanup

The weeks after remediation matter. Attackers who obtained SIP credentials or admin credentials may reuse them after the vulnerability is closed. Monitoring should continue at several layers.

At the web layer, monitor access to /admin/, /admin/ajax.php, /admin/config.php, and unexpected module routes. At the database layer, monitor changes to ampusers, cron_jobs, trunk configuration, extension configuration, and admin roles. At the telephony layer, monitor international calling, premium-rate destinations, after-hours call spikes, repeated registration failures, and new device registrations. At the operating-system layer, monitor new users, SSH keys, cron, systemd services, new PHP files, and unexpected outbound connections.

The most useful alerts are tied to business behavior, not just technical signatures. A POST to a FreePBX admin route from a new country is suspicious. A new admin user followed by outbound calls to unusual destinations is more suspicious. A .clean.sh artifact plus missing /etc/freepbx.conf plus unknown cron_jobs is incident-response territory.

FAQ

What is CVE-2025-57819 in FreePBX?

• CVE-2025-57819 is a critical FreePBX vulnerability affecting the Endpoint Manager module in supported FreePBX 15, 16, and 17 branches.
• The official advisory describes insufficient sanitization of user-supplied data that allows unauthenticated access to FreePBX Administrator, arbitrary database manipulation, and remote code execution.
• NVD records CWE-89 and CWE-288 for the issue, reflecting SQL injection and authentication bypass characteristics.
• It was exploited in the wild and added to CISA’s Known Exploited Vulnerabilities catalog on August 29, 2025. (GitHub)

Which FreePBX versions are affected?

• FreePBX 15 systems are affected if the Endpoint Manager module is older than 15.0.66.
• FreePBX 16 systems are affected if the Endpoint Manager module is older than 16.0.89.
• FreePBX 17 systems are affected if the Endpoint Manager module is older than 17.0.3.
• End-of-life versions were not fully tested in the official advisory, so they should not be treated as safe by omission. Upgrade to a supported branch. (GitHub)

How can I check whether my FreePBX system is vulnerable?

• Check the installed Endpoint Manager version with fwconsole ma list | grep -i endpoint.
• Confirm whether FreePBX Administrator was reachable from the public internet before patching.
• Review whether the system had automatic module updates enabled and whether the update actually completed.
• If the host was exposed, perform IOC review even after updating. A patched version does not erase compromise artifacts.

What indicators of compromise should I check first?

• /var/www/html/.clean.sh, which should not exist on normal systems.
• Recent modification or absence of /etc/freepbx.conf.
• POST requests to modular.php in Apache or httpd logs.
• Unusual calls to extension 9998 in Asterisk logs or CDRs.
• Unknown users in the ampusers database table.
• Suspicious scheduled commands in cron_jobs.
• Unknown PHP files in web-accessible directories. (Cyber Security Agency of Singapore)

Is patching enough if the system was exposed to the internet?

• No. Patching closes the known vulnerable code path, but it does not remove attacker-created users, scheduled jobs, web shells, stolen credentials, or system-level persistence.
• If exposure existed before patching, preserve evidence and review IOCs.
• Rotate FreePBX, SIP, extension, voicemail, SSH, database, and provider credentials if compromise is suspected or confirmed.
• Consider rebuilding or restoring from a known-good system image if there is evidence of command execution.

How is CVE-2025-57819 different from CVE-2025-66039, CVE-2025-61675, and CVE-2025-61678?

• CVE-2025-57819 is the actively exploited 2025 FreePBX issue involving unauthenticated access, SQL injection, and RCE in the Endpoint Manager context.
• CVE-2025-66039 is an authentication bypass tied to FreePBX’s webserver authentication type and is not the default configuration according to Horizon3.ai’s analysis.
• CVE-2025-61675 covers authenticated SQL injection flaws in Endpoint Manager functionality areas.
• CVE-2025-61678 covers authenticated arbitrary file upload behavior that can lead to web shell upload.
• Together, these CVEs show why FreePBX management-plane hardening matters beyond a single patch. (NVD)

Should FreePBX Administrator ever be exposed directly to the internet?

• As a rule, no.
• Use VPN, ZTNA, a bastion, or strict source-IP allowlisting for administration.
• Strong passwords and MFA help against credential abuse, but they do not reliably protect against pre-auth vulnerabilities.
• Treat FreePBX as critical infrastructure, not a casual web admin panel.

What should I include in an incident report for CVE-2025-57819?

• FreePBX branch and Endpoint Manager version before and after remediation.
• Whether Admin UI was publicly reachable, and from what time window if known.
• IOC findings with timestamps and evidence paths.
• Database review results for ampusers and cron_jobs.
• CDR and telecom billing review results.
• Credential rotation scope.
• Rebuild or restore method.
• Retest evidence showing patched module state and restricted external access.

CVE-2025-57819 is a reminder that PBX servers are not low-value appliances. They are identity stores, call routers, credential holders, billing gateways, and sometimes overlooked Linux servers with privileged access to business communications. The fix starts with the Endpoint Manager patch, but it does not end there.

The defensible response is to reduce reachability, patch supported systems, check for compromise, rotate secrets, review call activity, rebuild when evidence demands it, and keep monitoring after the incident looks quiet. Treat the FreePBX Administrator interface like a critical control plane. If it is exposed to the internet, the next pre-auth bug will not need permission to become your problem.