Post cover image

August 16, 2026

FreePBX CVE-2025–57819: From Unauthenticated SQL Injection to Remote Code Execution

A vulnerability in a PBX system is more than just a web application security issue.

By Raj Kumar M

5 min read

A compromised PBX can expose extensions, call-routing information, voicemail, SIP configuration, administrative accounts, and the underlying server itself.

In August 2025, a critical vulnerability was disclosed in the FreePBX Endpoint module. CVE-2025–57819 allows an unauthenticated attacker to exploit SQL injection in the Endpoint module and, through a chain of database manipulation and scheduled task execution, achieve remote code execution.

NVD currently rates the vulnerability 9.8 Critical under CVSS 3.1 and records a 10.0 Critical CVSS 4.0 score from the CNA. The vulnerability is associated with CWE-89 (SQL Injection) and CWE-288 (Authentication Bypass Using an Alternate Path or Channel). It is also listed in CISA's Known Exploited Vulnerabilities catalog.

What Is FreePBX?

FreePBX is an open-source, web-based graphical management interface for Asterisk.

Asterisk provides the underlying PBX and VoIP functionality, while FreePBX provides a web interface through which administrators can configure and manage that functionality.

For example, administrators can use FreePBX to manage:

  • Extensions
  • SIP devices
  • Trunks
  • Call routing
  • IVR
  • Voicemail
  • Ring groups
  • Conferences
  • Endpoint provisioning

A simplified architecture looks like this:

                    Administrator
                          |
                          v
                  FreePBX Web Interface
                          |
                          v
                    Apache / PHP
                          |
              +-----------+-----------+
              |                       |
              v                       v
       FreePBX Framework          FreePBX Modules
                                      |
                                      v
                               Endpoint Manager
                                      |
                                      v
                               MariaDB / MySQL
                                      |
                                      v
                                   Asterisk

The important part for this vulnerability is the modular architecture.

FreePBX functionality is divided into modules, and the Endpoint module provides functionality related to managing and provisioning supported VoIP endpoints.

This module is at the center of CVE-2025–57819.

What Is CVE-2025–57819?

CVE-2025–57819 affects the FreePBX Endpoint module.

The vulnerability is caused by insufficient sanitization of user-supplied data. Under affected configurations, an attacker can reach the vulnerable functionality without normal authentication and use SQL injection to manipulate database content.

The official vulnerability description summarizes the impact as:

Unauthenticated Access
        |
        v
Database Manipulation
        |
        v
Remote Code Execution

The CVE is associated with:

CWE-89 — SQL Injection and CWE-288 — Authentication Bypass Using an Alternate Path or Channel

The affected Endpoint versions are:

FreePBX 15  → versions before 15.0.66
FreePBX 16  → versions before 16.0.89
FreePBX 17  → versions before 17.0.3

The corresponding fixed versions are:

15.0.66
16.0.89
17.0.3

These versions are documented by NVD and the FreePBX security advisory.

Where Is the Vulnerability?

The vulnerable functionality is associated with the Endpoint module.

The main HTTP entry point involved in the attack is:

/admin/ajax.php

However, /admin/ajax.php is not itself the vulnerable SQL function.

It acts as an AJAX dispatcher.

The request specifies the Endpoint module through the module parameter.

The important value is:

FreePBX\modules\endpoint\ajax

Therefore, the request flow can be represented as:

HTTP Request
     |
     v
/ admin/ajax.php
     |
     | module=FreePBX\modules\endpoint\ajax
     v
Endpoint AJAX Handler
     |
     v
Input Processing
     |
     v
Database Query

The relevant module is located under:

/admin/modules/endpoint/

with the AJAX implementation under:

/admin/modules/endpoint/ajax.php

This distinction is important when analyzing the source code.

Understanding the Vulnerable Request

A simplified request looks like this:

POST /admin/ajax.php

with parameters such as:

module=FreePBX\modules\endpoint\ajax
command=model
template=x
model=model
brand=<user-controlled input>

The complete flow can be represented as:

/admin/ajax.php
      |
      v
module=FreePBX\modules\endpoint\ajax
      |
      v
command=model
      |
      v
brand=<input>
      |
      v
Endpoint functionality
      |
      v
SQL processing

The parameter that becomes particularly interesting during SQL injection testing is:

brand

The brand Parameter

The brand parameter is processed by the Endpoint functionality.

From a security-testing perspective, we want to determine whether our input is treated purely as data or whether it can influence the SQL statement.

The expected secure flow would be:

User Input
    |
    v
Validation
    |
    v
Prepared SQL Statement
    |
    v
Database

The vulnerable behavior allows attacker-controlled input to reach SQL processing in an unsafe way:

User Input
    |
    v
brand
    |
    v
Endpoint AJAX Handler
    |
    v
SQL Processing
    |
    v
Database

That creates the SQL injection primitive.

Confirming the SQL Injection

Before attempting to demonstrate the full impact, I first wanted to establish whether the brand parameter was actually influencing SQL execution.

For this purpose, a time-based SQL injection can be used in an authorized lab.

A controlled test introduces a database-side delay:

brand=x' ;SELECT SLEEP(5); --

The concept is straightforward.

A normal request should return quickly:

Normal Request
      |
      v
SQL Query
      |
      v
Fast Response

A request that causes the database to execute the delay should take significantly longer:

Injected Request
      |
      v
SQL Query
      |
      v
SLEEP(5)
      |
      v
Delayed Response
curl -s -o /dev/null -w 'sleep5 POST: %{time_total}s\n' -X POST \ 'http://<LAB-HOST>/admin/ajax.php?module=FreePBX%5Cmodules%5Cendpoint%5Cajax&command=model&template=x&model=model&brand=x%27%20%3BSELECT%20SLEEP(5)%3B%20--%20' \ -H 'X-Requested-With: XMLHttpRequest' \ -H 'Origin: http://<LAB-HOST>' \ -H 'Referer: http://<LAB-HOST>/admin/config.php'

The important portion is: brand=x' ;SELECT SLEEP(5); --

None

The response-time difference provides evidence that the supplied input is reaching SQL processing.

At this point, we have established the first major component:

Attacker-Controlled Input
          |
          v
     brand parameter
          |
          v
     SQL Injection

But SQL injection is not the end of the story.

The next question is:

What can the attacker do with the database access obtained through this vulnerability?

From SQL Injection to Database Manipulation

SQL injection becomes much more serious when the compromised database contains functionality that can influence application behavior.

The high-level chain is:

SQL Injection
      |
      v
Database Manipulation
      |
      v
Application-Controlled Data
      |
      v
Further Exploitation

During analysis of the FreePBX environment, the cron_jobs functionality becomes particularly interesting.

The reason is simple:

Database
   |
   v
cron_jobs
   |
   v
FreePBX Scheduled Task
   |
   v
Command Execution

This creates a bridge between the database and operating-system-level execution.

the describes the same general exploitation path: using the SQL injection to insert a row into the cron_jobs table, with the scheduled job then executing a supplied command.

Why cron_jobs Matters

A database table normally contains data.

But if application logic treats database records as instructions, modifying those records can become much more powerful.

In this case:

SQL Injection
      |
      v
Insert cron_jobs record
      |
      v
FreePBX processes the record
      |
      v
Scheduled command execution

This is the point where the SQL injection can be chained toward code execution.

The important security concept is:

The database is not only storing information; certain database records influence what the application executes.

SQL Injection → Scheduled Execution

At a high level, the attack becomes:

                   SQL Injection
                          |
                          v
                  Database INSERT
                          |
                          v
                     cron_jobs
                          |
                          v
                  Scheduled Task
                          |
                          v
                   Command Execution

In my authorized lab environment, I used this behavior to demonstrate the next stage of the attack chain.

None

This demonstrates that the vulnerability is capable of going beyond simply reading database information.

From Scheduled Execution to RCE

Once attacker-controlled data reaches a mechanism capable of executing commands, the exploitation chain reaches its final stage.

The simplified chain is:

SQL Injection
      |
      v
Database Manipulation
      |
      v
Scheduled Execution
      |
      v
Command Execution
      |
      v
Remote Code Execution

At this point, the attacker is no longer limited to manipulating database content.

The underlying server can potentially be controlled through the resulting execution primitive.

None

For validation in an authorized lab, a harmless command such as hostname or id can be used to demonstrate that execution has reached the underlying operating system.

can demonstrate that execution has reached the underlying operating system.

Complete Attack Chain

              CVE-2025-57819
                     |
                     v
          Unauthenticated Access
                     |
                     v
              /admin/ajax.php
                     |
                     v
       Endpoint AJAX Module
                     |
                     v
              brand parameter
                     |
                     v
              SQL Injection
                     |
                     v
         Database Manipulation
                     |
                     v
                cron_jobs
                     |
                     v
          Scheduled Execution
                     |
                     v
           Command Execution
                     |
                     v
                    RCE