0 Day FreePBX Exploit?

I was made aware of a new zero-day FreePBX exploit today - apparently it affects Phone Apps, even if you’re not using Phone Apps in a licensed capacity.

Does anyone have any information on this? Apparently, and earlier post on the subject was pulled down? Do we have any sort of statement from Sangoma or an ETA for a security fix? Should we be closing down the public facing Phone Apps port for all customers?




We’re working on getting a fix pushed out, hopefully within the next 24 hours or so. It’s a very recently introduced problem so only impacts you if you have the following restapps versions installed:

Blocking public traffic to the restapps port on public interfaces is a good mitigation. Or downgrade restapps to anything before those versions is probably a better option.

If you roll back to or you should be ok.

Sorry about the trouble on this, we’re working as quickly as possible to get this resolved.

Matthew Fredrickson

EDIT: @tm1000 thinks that blocking restapps ports is still insufficient from his testing, so downgrading is the best path until the official fix is pushed.


Thanks Matt!

Are any of the v14 modules affected as well?


Any earlier versions of FreePBX (v14, v13, etc) are not impacted. It’s only the 15.x and 16.x versions listed above.

We thought edge versions of 14 might have had some problems but it was a false alarm. 14 is good (edge and stable versions).

1 Like


Can the affected versions be pulled from the mirrors? Looks like they can still be downloaded. Not sure how practical/possible this is without breaking other things…

Also just to note I could not find in the repository, however I was able to grab

[[email protected] ~]# fwconsole ma downloadinstall restapps --tag
No repos specified, using: [standard] from last GUI settings

Unable to update module restapps -, it does not exist:
Updating Hooks...Done
Chowning directories...Done


Nate should work too.

That is 88 and 96 on a “stock” system, right?

You can access restapps through normal http/https ports non specific to the restapps ports themselves (eg port 80 and 443 respectively) because of this blocking traffic to the restapps ports will not protect you unless you block access to all http/https traffic.

Source: I worked with @billsimon on the original POC (Proof of concept) for this new exploit in the now removed (for security not obscurity) thread. My POC worked against admin http/https (80,443) along with the restapps ports. @billsimon and I have been working with Sangoma (@mattf, @lgaetz and @mbrooks respectively). The original attack itself centered around exploiting restapps through the admin interface on https.

Tr;dl, You aren’t getting around this by blocking only the restapps ports. Downgrading the modules as suggested is the only way to prevent being hacked.


Can we disable Phone Apps if we’re not using it, or uninstall/Remove?


fwconsole ma delete restapps
fwconsole reload

Can we get some clarification on this because Ward is over on the voip-info forums saying that this has to do with the freepbx_ha module and a license being triggered. Is this the case? Because then if they need to use freepbx_ha wouldn’t those without that installed (during the OS install) be fine? Or is this a double whammy thing?

As I pointed out last week, the HA module seems to be gone from the mirrors and throws a bunch of errors after I moved systems from 13 to 14. Can’t remove the HA module normally because it can’t be verified since it doesn’t exist in any place the system verifies things.

I do have, what I think, is a serious question. Since the modules being mentioned here are commercial which means only Sangoma developers work on them.

How did a ZERO DAY exploit from almost TWO years ago end up regressed into new updates? This seems like an important thing to pay attention to and not have regression on. Why is QA and testing still a very weak part of this project in 2021 and over a decade into it?

Sangoma will comment in full shortly.

Originally I thought it was freepbx_ha but the exploit in question only masks itself using freepbx_ha after the entry point. So removing ha or disabling it doesn’t really matter because the entry point is the same. Of course Wards comments about this are before the discussion went internal between myself @billsimon and others at Sangoma so Ward only has a view of the first 20 minutes of discussion on this when in reality the discussion went on for another 3 hours.

What this means is freepbx_ha is rather irrelevant. The entry point is the same and is not frrepbx_ha. It would be trivial for another exploit to use the same entry point but mask itself as a completely different module.

In fact according to research @billsimon did you don’t even need freepbx_ha on the system at all.

I want to give Sangoma the opportunity to comment in full so I’m trying to not reveal too much information but I think it’s important some questions are answered so that people don’t feel like “well I don’t have freepbx_ha so I am fine” because that’s a false sense of security. You aren’t fine.

The same way that the updateall function keeps getting regressed to install apps that are not installed.
The same way that usermanager was eating processes and instead of fixing it properly they dumped it to a cron.
The same way said cron was implemented bad and filled up everyone’s inbox over the weekend.

Because there is no QA.


Just like there is no spoon?

1 Like

Hey Tom,

The long and the short of it is that there were some changes that were made in the restapps module recently that were trying to fix a few bugs in phoneapps usage with phones in funny network environments - one of the more recent changes caused this regression.

We did not previously have a unit test written around this particular exploit (mostly due to the fact that there were some significant challenges around unit testing the code due to its former architecture). After this though, we’re going to be dumping a bunch of time into refactoring that code to make it more unit testable and so we can include a test case to cover this and any other similar issues that may come up in the future.

Big apologies again for the trouble around this.

1 Like

Matt, I’m just going to be brutally honest here. I will need to look at the v16 code but everything code wise that I have looked at up until 15 is a frigging mess. There is zero consistency in the coding standards so I’m pretty sure that can have an impact on things.

I mean let us take your Asterisk counterpart as an example. If I look at the code for something I cannot tell that 6 developers have touch the code because it is consistently the same through out. Comments, formatting, structure all the same. On the other hand when looking at FreePBX code you can tell multiple people have touched it because there is zero consistency through out the code. Some of it is formatted in actual readable and logic ways, some may have comments and my favorite is the developers that insist on writing PHP code like JQuery/Javascript with all the code minified in to a few lines with no spacing or readable formats.

So talks about unit tests being written or other such things worries me due to the lack of actual coding guidelines and practices that I’ve seen through the project.

1 Like

Coding and uniformity standards as well as testing info is all documented. They simply aren’t enforced.

At new ventures all of this is enforced with ci. We use static analysis etc and nothing can mainline without passing

Thanks for your honest feedback Tom.

I think as a project we’re trying to move things in a direction where we have a bit more consistency as far as code styles and consistent best practices go. As new contributions go through the code review process, we welcome any and all positive participation in helping with those goals.

Separately from that, automated testing is an area that we have reaped great rewards from on the Asterisk side to provide significant comfort and stability to its code base. It is a personal interest of mine to bring those benefits to FreePBX as well.

Best wishes,
Matthew Fredrickosn