Multiple security fixes were released for various FreePBX modules over the past couple of weeks, covering all supported versions 15, 16 and 17. Most major security fixes were for issues that were years in the making – some had existed in the code base for over a decade, in both open source and commercial modules, including SQL-injections and Cross-Site Scripting vulnerabilities. Before reading this article further, please take time to update your systems and follow the latest stream of published FreePBX Security Advisories via the FreePBX security-reporting repository on GitHub to review the details, including exploit detection, Indicators of Compromise (IoC), mitigation suggestions, and (for the curious) hyperlinks to problematic commits from the past.
Overview
This article discusses meta-issues surrounding security fixes in FreePBX, investigates vulnerability scoring tools, and offers some ideas for improvements. System Administrators should walk away with a better understanding of terms like CVE, CWE, CVSS (including the differences between Base and other metrics), and EPSS.
Why so many fixes recently compared to before?
There are a few thoughts and opinions on the recent – and forthcoming – pace of security fixes:
- More automation than in the past. Researchers are increasingly turning to AI/LLM tools to fuzz and attack systems of all stripes. Optimists might rejoice in the arms race with Quality Assurance teams, as they are sure to improve supported software products in the long run, particularly in the world of long-lived open source projects like FreePBX, Asterisk, Debian and Linux.
- GitHub security reporting. Sangoma’s move to improve security reporting policies in late 2023 is bearing fruit across our entire ecosystem. As discussed at AstriCon 2025, the FreePBX move to GitHub followed the Asterisk move to GitHub, but we learned and shared a lot internally – making it easier to report, manage and work together on security issues in private spaces designed and curated for this purpose. These common tools are also more familiar to more individuals from outside the projects, and we are seeing a real-time improvement in code quality because of these changes.
- Dedication of resources to the project. As FreePBX continues to expand into the wider market for telephony systems, particularly in K12 and hospitality sectors, the positive impact on Sangoma revenue is ensuring that we can continue to increase the number of dedicated FreePBX & PBXact engineering, support, sales, marketing and advocacy staff 🤠.
- Renewed focus on Quality Assurance. Sangoma staff are keen to improve QA in FreePBX, specifically including more attention to detail in legacy portions of the code base. There are internal self-audits to ensure that we visit entire classes of functions, such as the various SQL wrappers in different modules. You may also notice increased focus on potential security issues in recent comments on pull requests — particularly PRs generated by AI.
Why do the bugs seem more severe?
The bug that stings most
is usually the last one
that you got bit by.
To consider severity, it is helpful to recognize that what is critical for some users is barely a vulnerability to others. Perhaps the latter took steps to avoid the issue by way of more stringent firewall rules, or sandboxing things into isolated virtual machine environments, or binding services to localhost then tunneling over SSH to forward HTTP ports, or maybe they just don’t care. ¯\_ (ツ)_/¯ But not you! You’re reading this and learning more about what to do!!
Every issue can have a description – which can contain many subjective opinions. Categorizing and measuring issues so you know when (or not) to act is an important part of the stewardship of active open source projects like FreePBX. There are several tools we can apply to software in this context.
What are the GitHub Security Advisory (GHSA) tools we can use?
Currently, the GitHub security issue reporting subsystem provides integrated controls for the following two popular tools for working with Common Vulnerabilities and Exposures (CVEs) – one qualitative and one quantitative – as well as an easy button to request a new sequential CVE number when the time comes.
1. Common Weakness Enumerator (CWE)
The CWE is a standardized key-value pair of numbered weaknesses, along with a brief title or description. There can be one or many CWEs on the same issue. In 2025, there’s over 900 to choose from, which can take considerable time to sort through, although some are not weaknesses but instead either views or categories (so used only indirectly.)
Examples include:
2. Common Vulnerability Scoring System (CVSS) Base metrics
The CVSS is a numerical score from 0.0 to 10.0, with 10.0 reserved for the most critical issues. The score is calculated by combining the contributions from several different metrics, including for example “Attack Vector”, “User Interaction”, “Privileges Required” and more. Conveniently, these individual metrics can be displayed as part of the CVSS vector string.
CVSS is currently at version 4.0, but GitHub defaults to version 3.1 with a drop-down option to select either v3 or v4. GitHub also provides more generic terms that map to score ranges, such as:
- Low (0.1 – 3.9)
- Moderate (4.0 – 6.9)
- High (7.0 – 8.9)
- Critical (9.0 – 10.0)
(These broad textual severity ranges are handy for discussions as well as quick initial assessments before a full analysis and scoring later on.)
Any new ideas for FreePBX CVSS vector strings and scores?
In the author’s opinion – not yet shared with the CVSS Special Interest Group (SIG) – one thing CVSS v4.1 or v5.0 might consider is some elevation gain for the “Privileges Required” component scoring. The current v3/v4 options for “None, Low or High” are labeled reasonably, but often there is only a small difference between them when it comes to the total score.
For example, a Critical score of 10.0 in CVSS v4 can be achieved for the following vector string, which shows “Privileges Required = None” (emphasis added on the PR:N field):
However, choosing either “Low” or “High” for “Privileges Required” still gets you a Critical score, BOTH THE SAME AT 9.4 (emphasis shown below on the PR:L and PR:H part of the vector string):
The links above lead directly to the sample CVSS v4 online calculator, which parses the vector string into the numerical score.
Also in the future, FreePBX GHSA/CVE descriptions should try to go beyond the current Base metrics supported by GitHub and include Supplemental, Environmental, and Threat metrics into the numerical score. The official CVSS 4.0 calculator page does this already! Especially noteworthy are the impacts on the scores for “Exploit Maturity” (E) when “Unknown” or “Attacked” vs. “Proof Of Concept (POC)” – toggling from either E:X or E:A down to E:P can take an issue from 10.0 to 9.3, for example (emphasis on E:P shown at the end of the vector string):
FreePBX users
should expect to see more parts
of CVSS.
–
Wider vector strings
using the full spec metrics
are in our future.
–
Let’s try v4 scores
with Exploit Maturity
in GHSAs.
Alternative 4.1
Another idea is to provide an “alternative” CVSS score, using a multiplier/divider out of some key metrics, specifically, elevating “Privileges Required” to control more of the final score. It’s like this rough patch idea to the calculator I put together quickly to help rapidly distinguish between authenticated vs. unauthenticated vulnerabilities.
The patch might clobber a few things, but right out of the gate, considering Base metrics only, it scores PR:N > PR:L > PR:H e.g. instead of 10/9.4/9.4 for N/L/H you get 10/7.2/5.8. In plainer language that considers FreePBX nomenclature, that translates to:
- No login required is still a 10 Critical
- Regular user login required is now 7.2 High instead of 9.4 Critical
- Administrator login required is now 5.8 Medium instead of 9.4 Critical
…which is probably much more in-line with expectations among many FreePBX professionals, especially those who are comfortable uploading new PHP modules via the Administrator Control Panel.
Wait! Alternative 4.1 gets better when you score the Threat metrics, too.
See below graphics for how the “Privileges Required” interaction with “Exploit Maturity” is affected for an “Unreported” level (E:U). These examples of the official (4.0) and suggested patch-based (4.1) calculations of the following vector string show a sample drop from CVSS score of 7.6 to 2.0 (the vector string is linked to the official calculator, with emphasis added to PR:H and E:U):
THAT’S HUUGE! Yes, it is the same vector string. (The extra U in HUUGE is for Unreported i.e. issue was found but no Attacked or Proof-of-Concept exploit was presented 😉
Other changes are visible throughout most combinations of PR and E – the below chart shows 4.0 -> 4.1 deltas from the following templated vector string (with emphasized question marks as placeholders):
CVSS:4.0/AV:N/AC:L/AT:N/PR:?/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:?
| PR | E | 4.0 | 4.1 | Delta |
|---|---|---|---|---|
| H | U | 7.6 | 2.0 | -5.6 |
| L | U | 7.7 | 4.7 | -3.0 |
| N | U | 9.1 | 9.1 | 0.0 |
| H | P | 8.5 | 4.3 | -4.2 |
| L | P | 8.6 | 5.5 | -3.1 |
| N | P | 9.3 | 9.3 | 0.0 |
| H | A | 9.4 | 5.8 | -3.6 |
| L | A | 9.4 | 7.2 | -2.2 |
| N | A | 10.0 | 10.0 | 0.0 |
What is the probability that critical security issues will affect my equipment?
The CVSS score is not always the best for this purpose. You could run a system full of CVSS 10’s that is isolated enough to avoid problems. Or the exploit might be so complicated that it rarely succeeds. Or it could be so long after the CVE was released that almost everybody’s systems are patched.
The additional Supplemental, Environmental, and Threat metrics mentioned before and included at the end of the CVSS vector string – but not yet part of the score in GitHub, which only uses Base metrics – are one way to inspect the situation.
Another interesting method to gauge probability of attack and help you prioritize what to shore-up first is the Exploit Prediction Scoring System (EPSS). Like CVSS, EPSS is also developed by the Forum of Incident Response and Security Teams (FIRST). But where EPSS differs is that instead of humans doing the scoring like CVSS, the EPSS probability percentage is continuously calculated for CVEs by machine learning algorithms crunching numbers from many sources. Practically, the EPSS percentage likelihood of attack changes over time as mitigations are deployed – including at the network level – whereas the CVSS score is often more fixed.
For example, the recent FreePBX SQL injection issue shows an overall decreasing EPSS over time, although the CVSS v4 Base score is still 10.
How do I know if my system is affected?
Each CVE has different IoC and mitigations to consider, depending on the affected version. This can be a laborious process. Sometimes it involves inspecting backups to confirm you didn’t back up infected data, such as embedded JavaScript or unknown user accounts.
Bulk IoC detection
FreePBX has long provided a “validate” tool to help check for multiple IoC – and clean them – similar to a root kit hunter. This tool is not always up-to-date with the latest exploits, but it might be enough to let you take a (better) backup, allowing for a faster restoration process on to a new installation elsewhere:
$ fwconsole validate ; # find issues
$ fwconsole validate --clean ; # fix issues
Regular, tested
backups today are good for
restores tomorrow.
Dashboard alerts
If you recently logged in to your FreePBX system Administrator Control Panel (ACP), then at the top of the Dashboard in the System Overview block, you may notice something like the following:
Clicking on the “There are 2 modules vulnerable to security threats” message should expand to a big red alert frame like this:
Clicking the RESOLVE button in the lower-left corner of the frame will open the Module Admin page, allowing you to update your FreePBX modules via normal mechanisms.
Sometimes updates – whether standard or security updates – will change something on your system that may require further manual intervention on your part. In these situations, you may notice new yellow notifications appearing in the System Overview on the Dashboard after the update.
Regarding the API Key Regeneration Notification
If you aren’t using the API module, e.g. not using GraphQL, then you don’t need to take much action. However, you might consider reviewing the firewall settings to confirm that the API/GraphQL ports are blocked from external access.
Once you process the alerts per your own security policies and press the big red “Apply Config” button in the upper-right corner of the ACP, then you can close out the individual frame-boxed alerts by clicking the “-” or “x” icons in the upper-right corner of the messages. That should result in a much more pleasant System Overview display:
Email notifications
If you didn’t set up email notifications at the same time you first logged in to your new FreePBX system, then you can adjust later in the ACP under Admin -> Module Admin -> Scheduler and Alerts menu by clicking the appropriate buttons:
Version 15 EOL extension to October 1st
Due to the recent major security issues and significantly increased researcher interest, we’ve moved the End Of Life date for FreePBX 15 from September 1st, 2025, to October 1st, 2025, and corresponding updates were made to the calendar on the FreePBX Versions page of the wiki. Please continue to update your systems and strongly consider an immediate move to either version 16 or 17. Also, be sure to tune into our webinar on September 18th to learn more about the upgrade process and ask any questions you may have in real time.