FreePBX CVE List?

Does anyone know if there is some place that lists CVE vulnerabilities in FreePBX and their current status?

We are currently running FreePBX v15.0.23.11, and we try to keep it fully updated.

As part of our annual business insurance renewal, they ran a scan of our PBX with a tool provided by Corvus and found the following CVE vulnerabilities:

The list is a little longer than I would have expected, and the majority of them are years old.

I’m guessing the FreePBX developers are already aware of these vulnerabilities, so I’m hoping it’s possible to find a complete list of CVE vulnerabilities in FreePBX and whether they have been addressed or not.

The ones I sampled don’t seem to be in FreePBX, although they may be in the SNG7 Linux distribution. Also most or all the ones I sampled don’t seem to be exploitable purely remotely. Quite a few seem to be Apache problems that are only exploitable if third party scripts are installed, which might be an issue for a public web host, but probably not for an embedded one.

1 Like

Thank you so much, @david55. This is exactly why I was hoping there was a central place to find a list of known CVEs for FreePBX and their status. I suspect most of these are not exploitable in the standard FreePBX/SNG7 distro.

FWIW, the Corvus report lists all 16 of these CVEs as “Apache httpd” vulnerabilities with one being flagged as critical and the other fifteen marked as high.

@jfinstrom, thank you for the link to the List of Securities Vulnerabilities page that @tm1000 has created.

I’m a little confused because that page identifies vulnerabilities and has NIST CVSS scores, but does not show any CVE identifiers (that I could find). According to the About the CVE Program page: “Information technology and cybersecurity professionals use CVE Records to ensure they are discussing the same issue, and to coordinate their efforts to prioritize and address the vulnerabilities.”

Does anyone know where to find the corresponding CVE-ID for each of the identified vulnerabilities? Or, maybe there is a reason these vulnerabilities are not in the CVE database?

If anyone knows how to reach @tm1000, I’d love to ask him to add the “Official Bug ticket” ID and in what version(s) of FreePBX it was fixed for each of the vulnerabilities on the List of Securities Vulnerabilities page so you don’t have to click in to each one individually to find that important info.

Until Sangoma gets off their butt and moves off CentOS 7, nothing will make this better. FreePBX 16 is a half assed step to get around CentOS 7, because they manually added PHP7 to their repos, but they did not manually update much else.

Without looking at the detail of each CVE, most will generally not be anything that is actually important unless the system is publicly available to the wider internet. So it will be busywork on your side to push back against idiotic, formulaic, nonsense from the insurance company.

There is no absolute requirement that you use apache2 (httpd) as your webserver.

kudos to @billsimon for

IWFM :smile:

1 Like

Hey @sorvani! :wave: I went through each of the CVEs in the list from my OP. Here is a table of each one’s CVSS score and the message from the changelog where it was fixed.

CVE CVSS Score v2 Gained Access Vulnerability Type(s) Product Version Fixed Change Description
CVE-2017-3167 7.5 None Bypass a restriction or similar apache2 2.4.26 important: ap_get_basic_auth_pw() Authentication Bypass (CVE-2017-3167)
CVE-2017-7679 7.5 None Overflow apache2 2.4.26 important: mod_mime Buffer Overread (CVE-2017-7679)
CVE-2021-39275 7.5 None apache2 2.4.49 low: ap_escape_quotes buffer overflow (CVE-2021-39275)
CVE-2021-44790 7.5 None Overflow apache2 2.4.52 important: Possible buffer overflow when parsing multipart content in mod_lua of Apache HTTP Server 2.4.51 and earlier (CVE-2021-44790)
CVE-2022-22720 7.5 None apache2 2.4.53 important: HTTP request smuggling vulnerability in Apache HTTP Server 2.4.52 and earlier (CVE-2022-22720)
CVE-2022-23943 7.5 None apache2 2.4.53 important: mod_sed: Read/write beyond bounds (CVE-2022-23943)
CVE-2022-31813 7.5 None Bypass a restriction or similar apache2 2.4.54 low: mod_proxy X-Forwarded-For dropped by hop-by-hop mechanism (CVE-2022-31813)
CVE-2021-26691 7.5 None Overflow apache2 2.4.48 low: mod_session response handling heap overflow (CVE-2021-26691)
CVE-2022-1292 10.0 None Execution Code OpenSSL 3.0.4 Fixed a bug in the c_rehash script which was not properly sanitising shell metacharacters to prevent command injection.
CVE-2016-7480 7.5 None Denial Of ServiceExecute CodeOverflow php 7.0.12 Fixed bug #73257, Fixed bug #73258 (SplObjectStorage unserialize allows use of non-object as key).
CVE-2016-3078 7.5 None Denial Of ServiceOverflow php 7.0.6 Fixed bug #71923 (integer overflow in ZipArchive::getFrom*).
CVE-2016-4344 7.5 None Denial Of ServiceOverflow php 7.0.4 Fixed bug #71637 (Multiple Heap Overflow due to integer overflows in xml/filter_url/addcslashes).
CVE-2016-4345 7.5 None Denial Of ServiceOverflow php 7.0.4 Fixed bug #71637 (Multiple Heap Overflow due to integer overflows in xml/filter_url/addcslashes).
CVE-2016-4346 7.5 None Denial Of ServiceOverflow php 7.0.4 Fixed bug #71637 (Multiple Heap Overflow due to integer overflows in xml/filter_url/addcslashes).
CVE-2019-9641 7.5 None php 7.3.3 Fixed bug #77509 (Uninitialized read in exif_process_IFD_in_TIFF).
CVE-2017-8923 7.5 None Denial Of Service php 7.4.24 Fixed bug #73122 (Integer Overflow when concatenating strings).

Here are links to the change logs for Apache2, OpenSSL, and PHP:

I pulled the CVSS score and Vulnerability type from the website. On the NVD - Search and Statistics page, all 16 CVEs are listed as 9.8 Critical which didn’t seem terribly useful to me.

@dicko, thank you so much for the link. I’m reluctant to get too far away from the standard FreePBX install and configuration though since it makes it harder to get help when things are all custom rolled. But, if the insurance company plays hardball, it’s good to know I have a workable path forward.

Do you or @sorvani know @tm1000? I’m still scratching my head on why the List of Securities Vulnerabilities page doesn’t use CVE IDs and doesn’t include a list of CVEs that are known to apply.

FWIW, it sure looks like the 16 vulnerabilities identified by the Corvus scan are still open given the version numbers of the products deployed in FreePBX v15.0.23.11:

> httpd -v; openssl version; php -v
Server version: Apache/2.4.6 (CentOS)
Server built:   Apr  2 2020 13:13:23
OpenSSL 1.0.2k-fips  26 Jan 2017
PHP 5.6.40 (cli) (built: Jan 22 2019 23:51:52)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

It’s not just Insurance companies that are hidebound, currently Sangoma’s FreePBX ( the ‘distro’) still relies on no longer supported code or deprecated usage, naming some . . .

PHP 5.6
RedHat as the underlying OS
OpenSSL 1.0.2
Fail2Ban 0.8
Asterisk Macros

You will probably need to wait for them to catch up to staunch the continual audit bitching from “those that bitch” :wink:

Is there anyone trying to bring FreePBX into the modern world? Where’s the main thread on this issue, dicko? This is definitely off topic from my OP asking for a list of FreePBX CVE vulnerabilities, but it’s definitely important. (Five of the open CVEs are from 2016. :nauseated_face:)

Are we talking FreePBX or Sangoma’s FreePBX ‘distro’ ?

Apart from the asterisk macro thing (the pot and the kettle live next door now, go figure :wink: ), FreePBX itself can happily now run with current open-source OS’s, PHP 7.4 Fail2Ban 0.11 OpenSSL 1.1.1n , current apache 2.4.54 nginx 1.22.0

Incron and cron like services are better handled by systemd

If you rely on any commercially licensed modules including sysadmin or the firewall, then they have you by the short and curlies :slight_smile:

@dicko, I want to respond, but not on this thread. If there’s not another thread on the topic you’re discussing, should I just open a new one? -Mark

feel free to express yourself any way you feel comfortable with

It’s important to understand that simplistic security scanners are going to flag Apache as vulnerable in some cases when it has already been patched against the vulnerability. The reason is explained at Security Backporting Practice - Red Hat Customer Portal

Simple version number scanners see Apache/2.4.6 and do not see that it has had patches applied to it through the RedHat backport process.

Apache 2.4.6 isn’t really 2.4.6…

# httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built:   Apr  2 2020 13:13:23
[[email protected] ~]# rpm -q httpd

it’s actually Apache 2.4.6-93! (on a fully-updated FreePBX distro)

As you can see it was compiled in April 2020 so this should satisfy the Apache CVEs before then (you’d have to go through the release notes and check), though you have several on your list that were published after April 2020, so those obviously aren’t resolved.


@billsimon, thanks, and I couldn’t agree more. In fact, that is exactly what I wrote back to the insurance company about their Corvus scan.

My issue here is that without someplace for us to go to to get a definitive list of known vulnerabilities, we’re all just guessing about our security position. I’m hoping others would like CVE numbers added to the List of Securities Vulnerabilities page. :cowboy_hat_face:

FWIW, here’s what my system has to say about package versions:

$ rpm -q httpd -q openssl

Looks like we have a fully-updated FreePBX distro. Woo hoo! :tada::tada:

That still doesn’t get us to the 2.4.54 release where all eight of the identified apache vulnerabilities have been addressed.

FWIW, I did go through all of the official Apache release notes. The fixes aren’t incorporated on a date of compilation, but on a release number. So, the CVEs before April 2020 have definitely not been addressed. :pensive:

Andrew (tm1000) is no longer with Sangoma. You’ll need to reach out to Sangoma to find out who the current maintainer of that page is.

You need to look up the release notes on RedHat’s site, not Apache’s.

Google for “redhat fix CVE-2017-3167”

take the top link to Red Hat Customer Portal - Access to 24x7 support and knowledge

It says it is fixed:

Red Hat Enterprise Linux 7 httpd Fixed RHSA-2017:2479 August 15, 2017

Follow that link and click the tab for Updated Packages and you see it’s fixed in httpd-2.4.6-67.el7_4.2.x86_64.rpm

So if you’ve got 2.4.6-93 > 2.4.6-67 you’re good…

Is this a pain? Yes. RedHat/CentOS sucks. Use Debian! But if you need to use EL then this is the way to check your versions when the audit flags you.


I’ve posted this before, but this link is often helpful in these scenarios. You will also want to look into Red Hat back-ports security releases without bumping the release number. Read this article for details: Security Backporting Practice - Red Hat Customer Portal


I believe based on very old information @mbrooks is doing the distro stuff. @kgupta2 heads up most of the FreePBX dev stuff including publishing.

Project managers currently are @lgaetz For FreePBX (the open source project, not the SNG distro) and @jcolp for the Asterisk project.

None of this matters if you don’t understand the following concepts which have been covered here.

  1. The FreePBX Distro is named SNG 7 and is a commercial product. It is NOT the same as FreePBX the open source project
  2. SNG 7 is an “Enterprise Linux” derivative based and is much like CentOS with different branding
  3. The term “Enterprise Linux” is used to not get sued by the redhat people
  4. All “EL” distros are built from Redhat packages with branding stripped for trademark compliance
  5. Redhat backports bug and security fixes and maintain their own stable branches.
  6. Security scanners should be a starting point NOT a final say. Almost all CVE reports will have a proof of concept. TRY THE EXPLOIT AND SEE IF IT WORKS
  7. If you are still reading this we have been trying to reach you about your cars expiring warranty

In any case security should be left up to security professionals typically. If you hired someone rather than running a script, most of this post wouldn’t be required.