Exemplified doubts about CVSS implementations

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):

Interestingly, this one ranked lower in GitHub CVSS v4.0 “Base” score than some other vulnerabilities published yesterday, but my alternative score introduced last month better captures the risk:

  • Current CVSS v4.0 Base score is 7.5 (High)
  • Current CVSS v4.0 more complete score is 4.6 (Medium)
  • Alternative CVSS v4.1 score is 4.6 (Medium)

The Asterisk HTTP status page is exposed by FreePBX and is available by default on v16 via any bound IP address at port 8088.

So you’re changing the defaults, right?

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 :clockwise_vertical_arrows: icon was previously (is still ?) confusing in that area of Advanced Settings, since it looks like the defaults are changed by the installation itself.

By binding 8089 to local host you are refusing webrtc (WSS) clients except for Sangoma Phone desktop.

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?

Hi,

Does anyone know why the Asterisk HTTP Status page was not disabled instead of changing the bind address ?

Regards,

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

:winking_face_with_tongue:

Patches welcome!

Another idea offered previously in this thread: Exemplified doubts about CVSS implementations - #5 by penguinpbx

Or, you could manually override in the included http_custom.conf file e.g.

bindaddr=::

But, if you do so, then you’d maybe/probably also want this in there:

enable_status=no

Please share if that works for you.

@penguinpbx @kgupta was this not sufficient?

1 Like

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 ?

Setting the bindaddress field to ::0 listens on all interfaces and doesn’t get overwritten.

(::0 is equivalent to :: …)

I also added

enable_status=no

to http_custom.conf.

1 Like

Thanks for the tip @billsimon.

I’m still worried about the other html pages available from the Asterisk HTTP server, does anyone know if they’re part of this vulnerability ?