List of Securities Vulnerabilities

There were security vulnerabilities before 2016 however we have only maintained this list from 2016 forward.

• 2023-08-28 SECURITY: Potential Rest Phone Apps Authentication issue

• 2022-04-12 SECURITY: Potential RCE Issue

• 2021-12-21 SECURITY: Potential Rest Phone Apps RCE

• 2021-10-06 SQL Injection vulnerability in Superfecta Module

• 2021-09-15 XSS Injection vulnerability in Voicemail Module

• 2021-09-15 XSS Injection vulnerability in TTS, Blacklist, Bulk handler and UCP Module

• 2021-09-15 SQL Injection in Asterisk Manager Users Module

• 2020-11-03 Sangomaconnect API Vulnerability

• 2020-08-17 SQL Injection In cdr module

• 2020-08-17 SQL Injection In cel module

• 2020-08-17 XSS Vulnerability In logfiles

• 2020-03-12 SECURITY: Potential Rest Phone Apps RCE

• 2020-01-09 Multiple XSS vulnerabilities in Backup & Restore Module

• 2020-01-09 XSS Injection vulnerability in Superfecta Module

• 2020-01-09 XSS Injection vulnerability in Call Event Logging module

• 2019-12-03 Multiple XSS Vulnerabilities

• 2019-12-03 Remote Command Execution

• 2019-11-20 Remote Admin Authentication Bypass

• 2018-09-11 DISA SQL Injection

• 2018-09-11 Core Stored XSS

• 2018-09-11 Framework Reflected XSS

• 2018-05-15 Information Disclosure CVE

• 2016-08-09 CVE Remote Command Execution with Privileged Escalation

• 2016-07-18 File Delete - Directory Traversal in Delete in Music on Hold

• 2016-07-18 Time Variant SHA1 Check in User Manager

• 2016-07-18 Multiple XSS

• 2016-01-06 SQL Injection CVE

If you think you have found a security vulnerability in FreePBX,  we would love to work with you to get it resolved! If you have a security issue to report, please visit this page Security Information

First Contact

The first thing for you to do is to email redacted@redacted.com, and please include as many details as possible. This includes such things as code snippets and a proof of concept (if you have one). We will evaluate the report and send a non-automated response within 3 (US) business days.

This follow-up may request additional information and require additional time for evaluation if enough detail was not originally supplied.  Once verified a private issue will be created visible only to staff and you as the reporter. You will need an account on http://issues.freepbx.org.

Investigation and Resolution

The time this takes will vary greatly based on the amount of detail provided and the ultimate complexity of the issue. The goal is to verify and resolve issues as quickly as possible but there is no guaranteed amount of time. The goal for the entire process is to be at or below Google's Project Zero standard of 60 days, but we expect to be able to work with the CERT standard of 45 days from report to full public disclosure. 

Initial Public Disclosure

Once an issue has been verified and fixed an abstract public disclosure will be released. This disclosure will have the following items:

1. Name of component affected

2. Affected versions

3. Fixed versions

4. Credit to the person who discovered the issue (if permitted by the researcher)

5. A CVE if available.

This disclosure will be made via our wiki (http://wiki.freepbx.org), Our Forums (http://community.freepbx.org) and through social media such as http://twitter.com/FreePBX. 

Mitigation Period

A minimum mitigation period of 14 days is normally requested to allow the public to act on the information and update as necessary to resolve the reported issue.

Full Disclosure

After the agreed on mitigation period has expired, the reporter may make public full details including proof of concepts and other data to various mediums. Functional details of the exploit will not be released (by us) on our wiki, forums or issue tracker. 

Fixed Versions

Current stable, unreleased future versions, and one major release behind will receive security updates.

When possible issues will be fixed as far back as practical, but this may not be practical.

Exploits for older versions may not be fixed. It is recommended that users run on the latest version of FreePBX.

Bounty

Sangoma at its full discretion may compensate reporters of a fully verified vulnerability that has not been previously patched. To be eligible for bounty consideration the reporter MUST follow the guidelines above.  The bounty can be paid in Bitcoin (or equivalent crypto-currency) if the security researcher wishes to remain anonymous.