Security Advisory: Please Lock Down Your Administrator Access

Blog Security
, , ,
1

The Sangoma FreePBX Security Team is aware of a potential exploit affecting some systems with the administrator control panel exposed to the public internet. AUG. 28 GOOD NEWS: FIX IS NOW DEPLOYED IN STABLE REPOS FOR AFFECTED SUPPORTED VERSIONS, INCLUDING ALL RELEASES OF ENDPOINT MODULE IN 15, 16 & 17. PLEASE UPDATE! Users are advised to limit access to the FreePBX Administrator by using the Firewall module to limit access to only known trusted hosts.

UPDATE 2025-09-09T16:13:00Z

Trimmed opening paragraph and re-pinned globally for the rest of September.

UPDATE 2025-08-29T19:39:00Z

Organized to put the most recent updates at the top. Link to full thread at the bottom (scroll down.)

UPDATE 2025-08-28T16:46:00Z

Published Fix Now in STABLE Following Successful QA

Please immediately update all supported systems (15, 16 and 17) using normal/stable FreePBX update methods – via the Administrator Control Panel menu Admin → Module Admin or via generic command line method:

As root: $ fwconsole ma upgradeall
Or sudo: $ sudo fwconsole ma upgradeall

…and take time to review GitHub Security Advisory GHSA-m42g-xg4c-5f3h for details on CVE-2025-57819, a critical vulnerability affecting the “endpoint” module in all supported versions of FreePBX (15, 16 and 17).

Users should check their automated security updates are active – especially those reading this later who were unaware of the update. We are aware of a current issue in the v17 “framework” module that may prevent automated update notification emails.

Also note that the infection detection checklist step 5 as posted yesterday may need expansion to more files, depending on your logging environment e.g. note the additional asterisk character below:

$ zgrep modular.php /var/log/{httpd,apache2}/*access*

UPDATE 2025-08-27T16:42:00Z

We are still on schedule for normal security release in appx. 12 hours.

Immediate Actions

Users should continue to take the following immediate steps – as posted previously, but with some minor refinement:

  1. Determine if your FreePBX/PBXAct system is exposed to the public internet. Activate firewalls if not the case e.g. configure the FreePBX Firewall module. Lock it down to only your IP address. Disallow the Internet/External zone access to the Web Management interfaces. Check access from another device e.g. your cell phone disconnected from local wifi.
  2. Upgrade to the latest versions of the endpoint module (if it was installed on your system.) See previous UPDATE from yesterday for commands OR if you read this after the endpoint module moves from EDGE to STABLE then perform normal module update (or at least confirm that any automatic update to the latest module version was successful via Admin → Module Admin menu.)

Note: If step 2 does not work, then renew all your commercial module licenses via the Sangoma Portal and try again.

If “endpoint” is NOT installed, then your system is probably NOT at risk of infection - but do please read on!

Users of FreePBX versions from before v16 are encouraged to continue reading as well - affected version histories are still being internally investigated ahead of the CVE publication.

Minimum Infection Detection Check List

There’s been excellent community discussion on the forums regarding the next steps - thank you to all for contributing! The Sangoma FreePBX Security Team recommendation is currently the following minimum check list:

  1. Visit your FreePBX Administrator web interface - is it broken ? Not loading like it used to ? Does /etc/freepbx.conf file still exist - check with this command:
    $ ls -l /etc/freepbx.conf
  2. Look for the tell-tale leftover sign of the exploit - this file should not exist on normal systems: /var/www/html/.clean.sh So check for it like this:
    $ ls -l /var/www/html/.clean.sh
  3. Check Apache logs for POST requests to modular.php - reaching back to at least August 21st. A command like the following should help you quickly look through all the relevant logs on both v16 and v17:
    $ zgrep modular.php /var/log/{httpd,apache2}/access*
  4. Check Asterisk logs for calls to extension 9998 - reaching back to at least August 21st (slight variations in this command may exist between systems):
    $ grep 9998 /var/log/asterisk/full*
  5. Review MariaDB/MySQL logs and tables for MACD of unknown users in the ampusers table - specifically looking for a suspicious ampuser username in the far-left column:
    $ mysql -e "SELECT * FROM ampusers" asterisk

If infection is detected in any of 3-7 above, then TAKE A DEEP BREATH and continue on.

Restoration Procedure

Even if you are not infected, it may be a good time to work through these sample restoration procedures to confirm you can recover quickly in the future:

  1. Preserve existing backups from before the infection - from at least before August 21st - on to separate media from your main backup storage.
  2. Install a new system with sufficient firewalling and fixed version of endpoint module, then restore the backup to it.
  3. Rotate all passwords, including but not limited to: system, SIP trunks, users, extensions, voicemail, UCP, etc.

If you do not have recent backups, then mitigation and clean-up – via steps 1, 2, and 10 – may be possible while you continue to provide basic services to your end users, but it is not advisable. EITHER WAY, CLEAN-UP OR RE-INSTALL, CHECK YOUR CALL DETAIL RECORDS AND PHONE BILL WITH YOUR TELCO, ESPECIALLY INTERNATIONAL CALLING!

Also, it may or may not be necessary for you to archive the infected system for future forensic analysis. If this is the case, then you might consider snap-shotting the infected VM, or taking another full running system backup immediately that includes portions of shared memory, process trees, etc. This procedure is outside the scope of the above minimum guidelines.

UPDATE 2025-08-26T16:57:00Z

Users are still advised to restrict public access to the Administrator Control Panel (ACP).

Additionally, there is now EDGE module fix for testing – please note that this has not gone through full normal QA, but we will be doing so ASAP and including as part of normal security release.

FreePBX users on v16 or v17 can run:

$ fwconsole ma downloadinstall endpoint --edge

PBXAct v16 users can run:

$ fwconsole ma downloadinstall endpoint --tag 16.0.88.19

PBXAct v17 users can run:

$ fwconsole ma downloadinstall endpoint --tag 17.0.2.31

Continue Reading the full topic…

1 Like
4

We are reporting that multiple servers in our infrastructure were compromised, affecting approximately 3,000 SIP extensions and 500 trunks.

As part of our incident response, we have locked all administrator access and restored our systems to a pre-attack state. However, we must emphasize the critical importance of determining the scope of the compromise.

:warning: Can you please confirm whether SIP account and trunk credentials should be considered compromised ??
If so, we will proceed with a complete password rotation across all affected systems…

5

You should consider everything compromised. They were in your system for almost a week doing things. Whether or not they got SIP creds is lower on the list compared to how much damage they did and how many backdoors there might be.

2 Likes
6

Was that just a backup/restore or a full snapshot restore?

7

Further note, although the exploit is breaking some systems (PHP Fatal error: Uncaught Error: Class "Symfony\Component\Console\Application" not found in /var/www/html/admin/libraries/FWApplication.class.php:11 Stack trace: #0 /var/lib/asterisk/bin/fwconsole(66): include() #1 {main} thrown in /var/www/html/admin/ - #41 by gregarican), in some cases it is succeeding without any obvious effects.

I found evidence of the exploit on a FreePBX 17 test system that was otherwise working fine.

The most telling evidence is the presence of the file .clean.sh in /var/www/html. It looks as though the script is supposed to delete itself when done, but it does not.

8

It may not have deleted itself for a few reasons. Additionally, it could have deleted itself and then be re-added by one of the attacker’s scripts to do more cleanup.

If you stat the file and it shows that it was created on the 21st but last modified on the 26th, it was mostly like touched or re-added by the attacker. If it shows the file was added on the 21st but was only accessed on the 26th (not modified) it probably didn’t delete itself due to a permissions issue or not completing fully when it ran but it keeps trying to run.

1 Like
9

Full backup restore.

10

Then you really didn’t restore the system to a pre-compromised state. You just reinstalled the FreePBX modules and configs but didn’t touch anything on the wider system that could be compromised.

1 Like
11

@penguinpbx Just for clarify for all levels of users, this update is to fix the RCE exposure? I.e. lock down the exploit that was used to gain access to the system. It in no way cleans up or removes the compromises on systems that already have been compromised.

1 Like
12

So this was a exploit in the Commercial End Point Manager module. So if this module was not installed systems are safe correct? Since its a commercial module we can not see what was changed and what the exploit was in the module.

1 Like
13

Is this issue only with freepbx16/17 with endpoint manager installed? if so, how does blocking /admin affect the exploit, if the issue is with endpoint? If I add a block to /admin in nginx, will that mitigate the exploit? or do I need to block port 1443?

14

My system is FreePBX and does not have Endpoint Manager installed.

15

Installed or licensed? Did you actually go into module admin and uninstall the endpoint manager?

1 Like
16

Good point, but I can’t get into the web interface to double check. Indeed, it might be installed.

17

What version of endpoint manager module is at fault ?

If the PBX firewall does not allow PBX Management to Internet zone, can we consider that PBX safe ?

You seem to have published a fix but there is a huge lack of information or transparency here.

18

fwconsole ma downloadinstall endpoint --edge

PHP Fatal error: Uncaught Error: Class ‘Symfony\Component\Console\Application’ not found in /var/www/html/admin/libraries/FWApplication.class.php:11
Stack trace:
#0 /var/lib/asterisk/bin/fwconsole(66): include()
#1 {main}
thrown in /var/www/html/admin/libraries/FWApplication.class.php on line 11

19

The Security Advisory is indeed a bit strange… They are talking about Administrator Control Panel (ACP)… But it seems a vulnerability in the Endpoint Manager module.

Meaning if we don’t have that module installed, all good?
fwconsole ma list | grep endpoint should return nothing.

20

The EDGE module fix provided should protect future installations from infection, but it is not a cure for existing systems. Existing 16 and 17 systems may have been impacted, if they a) had the endpoint module installed and b) their FreePBX Administrator login page was directly exposed to a hostile network e.g. the public internet.