Please consider updating core module on v16 & v17 to address this recent hybrid unauthenticated & authenticated issue (CVE-2025-59429). For these and several older FreePBX versions, suggested mitigations are included in the full GitHub Security Advisory (GHSA):
Yes, the fix provided should change both HTTP 8088 and HTTPS 8089 to bind to 127.0.0.1 instead of ::unless you already changed these yourself to something else.
Related, the icon was previously (is still ?) confusing in that area of Advanced Settings, since it looks like the defaults are changed by the installation itself.
Only :: is being changed - so if you bind to an explicit IP, then you should be fine.
Alternatively, it might be that a future iteration of this patch checks the HTTPS Bind Port instead; so, if that is not the default 8089, then leave the HTTPS Bind Address alone (even if it is ::).
Understood, but if by default you are binding to localhost, then anyone who wants to connect a webrtc extension will have to change the binding. Why not use the firewall here instead?
This broke a PBX with webrtc configuration over the weekend. Thanks for that.
I really don’t understand the logic of breaking an entire transport option. Not worth considering given that Sangoma offers a commercial webrtc phone that runs on its own special port? Third parties just deal with the breakage? Not great considering this is the open-source part of the project that is in scope here.
I’m going to double down on this and note… this solution is really lame.
So after your update, if I go in and reset the HTTPS binding address to :: because yes I really want to listen on all interfaces then you’re just going to change it back next time core is updated. Every single time.
Perhaps the frontend should disallow me to enter ::. Or should provide a note saying that if I enter :: then it will be changed to 127.0.0.1 over my wishes. Or there should be a link to purchase Sangoma Phone Desktop.
Last rant. You should know this does not work. If I bind to a specific IP then sangomartapi is broken because it connects to the http server on 127.0.0.1. So I can choose to bind to an IP and can’t use Sangoma Phone Desktop or I can bind to 127.0.0.1 and can’t use any other webrtc phone. Weirdly, I want to use both.
We are looking into a finer-tuned fix, but given the more severe nature of this security issue, it was decided to plug the port hole altogether at this time.
Also, since enable_status=yes is the long-standing default in Asterisk, combined with the general propensity of FreePBX to accept Asterisk defaults whenever there is no good reason to do otherwise, it is perhaps reasonable to assume that some users may be running (legacy ?) HTTP-based monitoring tools that rely on consistent default output from this service (which a locally running agent could still obtain even after the current fix was applied.)
Anyhow, this is a short-term answer to a complicated security question, involving trade-offs between out-of-box default choices. So, thank you for the feedback, as we are still adjusting course on this issue long-term.
I’m annoyed that breaking the webrtc functionnality was chosen rather than (maybe) breaking a monitoring tool.
On a different topic : there are other HTML pages that can be served by the Asterisk HTTP server (eg webenabled=yes in manager.conf). Are those vulnerable too ?