CVE-2023-48085

What it actually does

Nagios XI versions before 5.11.3 contain an unauthenticated remote code execution vulnerability in the command_test.php component. A remote attacker can send a crafted HTTP request that causes the server to execute operating-system commands in the context of the Nagios XI web application user. Because Nagios XI commonly stores monitoring credentials, host inventories, service definitions, notification integrations, and privileged automation hooks, successful exploitation can lead to full compromise of the monitoring server and exposure of sensitive infrastructure data. The CVSS 9.8 rating and network-accessible, low-complexity, no-authentication attack conditions make this a critical issue despite the absence of CISA KEV listing at this time. The EPSS score of 0.75844 indicates a high likelihood of exploitation activity compared with most vulnerabilities.

Why it matters to the business

Compromise of a Nagios XI server can disrupt infrastructure monitoring, blind operations teams to outages or intrusions, expose credentials used to monitor critical systems, and provide attackers with a trusted foothold into internal networks. Since monitoring platforms often have broad visibility and connectivity across production environments, exploitation can have consequences beyond the Nagios server itself, including data theft, service disruption, persistence, and lateral movement. Organizations still running Nagios XI before 5.11.3 remain exposed to a remotely exploitable critical flaw that has been public for a long time, increasing the chance that commodity scanning and opportunistic exploitation will target internet-facing instances.

How an attack unfolds

An attacker first identifies an exposed Nagios XI instance and determines that it is running a vulnerable version prior to 5.11.3. The attacker then sends a crafted HTTP request to the vulnerable command_test.php endpoint. If the server is vulnerable, the request causes attacker-controlled input to be interpreted as an operating-system command. The attacker can use this to run reconnaissance commands, download a payload, establish a reverse shell, create persistence, or access Nagios XI configuration files and stored credentials. After initial code execution, the attacker may enumerate monitored hosts, abuse credentials or plugins, pivot to systems reachable from the monitoring server, disable or tamper with monitoring, and stage further attacks from a trusted management host.

How to fix it

Upgrade Nagios XI to version 5.11.3 or later. If immediate upgrade is not possible, restrict access to the Nagios XI web interface to trusted administrative networks or VPN users only, block direct internet exposure, and apply web application firewall rules or reverse-proxy controls to deny access to command_test.php from untrusted sources. Review Nagios XI server hardening, ensure the web server and Nagios processes run with least privilege, rotate credentials stored in or accessible from Nagios XI if exploitation is suspected, and audit custom plugins or automation that could be abused after compromise. Because no fixed_versions field was provided, use the vendor advisory and release notes as the source of truth, with Nagios XI 5.11.3 or later as the minimum safe version based on the vulnerability description.

How to confirm the fix worked

Confirm the installed Nagios XI version is 5.11.3 or later using the Nagios XI administrative interface, installed package metadata, or version files on the server. Verify that the vulnerable command_test.php endpoint is no longer exploitable and is not accessible from untrusted networks. Review web server access controls, firewall rules, reverse-proxy configuration, and external exposure to ensure Nagios XI is reachable only from approved management paths. Run an authenticated vulnerability scan or vendor-supported validation check where available. After patching, review file integrity and process history to ensure no web shells, modified Nagios plugins, unauthorized users, cron jobs, or suspicious services remain from pre-remediation compromise.

Typical attack path

1. Discover an exposed Nagios XI web interface through scanning, search engines, or asset enumeration.
2. Confirm that the instance is running a vulnerable Nagios XI version earlier than 5.11.3 or that the vulnerable command_test.php endpoint is reachable.
3. Send a crafted HTTP request to command_test.php that injects or triggers operating-system command execution.
4. Execute simple validation commands such as whoami, id, uname, or curl/wget callbacks to confirm code execution.
5. Deploy a web shell, reverse shell, remote access tool, or command-and-control stager under the web server or Nagios process context.
6. Enumerate Nagios XI configuration, monitored hosts, service checks, plugins, credentials, API tokens, and notification integrations.
7. Use obtained access or credentials to move laterally, tamper with monitoring, exfiltrate sensitive configuration data, or disrupt operations.

How to detect it

Investigate whether exploitation has already occurred by reviewing Nagios XI web server access logs, error logs, audit logs, system authentication logs, process execution telemetry, EDR alerts, shell history, cron entries, and file integrity data. Focus on requests to command_test.php, especially from unfamiliar IP addresses, requests using POST, requests containing shell metacharacters or encoded command payloads, and requests followed closely by outbound connections from the Nagios server. On Linux hosts, examine /var/log/httpd/access_log, /var/log/httpd/ssl_access_log, /var/log/httpd/error_log, /var/log/apache2/access.log, /var/log/apache2/error.log, /var/log/secure, /var/log/auth.log, and Nagios XI application logs where present. Hunt for web server or Nagios processes spawning command shells or utilities such as bash, sh, curl, wget, nc, ncat, python, perl, php, chmod, chown, or base64. Inspect web directories, plugin directories, and temporary directories for newly created PHP files, executable scripts, reverse-shell tools, or unusual files owned by the web server user. Correlate suspicious HTTP requests with outbound DNS, HTTP, HTTPS, or raw TCP connections, new local users, modified sudoers files, changed Nagios plugins, altered service checks, unexpected cron jobs, and credential access activity. If exploitation is suspected, preserve logs and a forensic image before cleanup, rotate credentials accessible to Nagios XI, and review downstream systems monitored by the server for lateral movement.

• command_test.php
• /nagiosxi/includes/components/ccm/command_test.php
• /usr/local/nagiosxi/html/includes/components/ccm/command_test.php
• POST /nagiosxi/includes/components/ccm/command_test.php
• GET /nagiosxi/includes/components/ccm/command_test.php
• /var/log/httpd/access_log
• /var/log/httpd/ssl_access_log
• /var/log/httpd/error_log
• /var/log/apache2/access.log
• /var/log/apache2/error.log
• /usr/local/nagiosxi/html/
• /usr/local/nagios/libexec/
• /usr/local/nagiosxi/var/
• apache.*command_test.php
• httpd.*command_test.php
• apache2.*command_test.php
• httpd.*bash
• httpd.*sh
• httpd.*curl
• httpd.*wget
• httpd.*nc
• httpd.*ncat
• apache2.*bash
• apache2.*sh
• apache2.*curl
• apache2.*wget
• apache2.*nc
• apache2.*ncat
• nagios.*bash
• nagios.*sh
• nagios.*curl
• nagios.*wget
• nagios.*nc
• nagios.*ncat

What your security team should do

• Treat all internet-facing Nagios XI instances running versions earlier than 5.11.3 as high-priority remediation targets.
• Upgrade Nagios XI to 5.11.3 or later and verify the version after maintenance is complete.
• Immediately restrict Nagios XI web access to trusted administrative networks, VPN, or zero-trust access controls; do not expose it directly to the internet.
• Search historical web server logs for requests to command_test.php, especially POST requests, suspicious shell metacharacters, and requests followed by outbound connections from the Nagios server.
• Hunt for unexpected child processes spawned by the web server or Nagios XI processes, including sh, bash, curl, wget, nc, python, perl, php, or chmod.
• If suspicious activity is found, isolate the server, preserve logs and disk artifacts, rotate credentials stored in Nagios XI, review monitored host credentials, and rebuild from trusted media if compromise is confirmed.
• Audit Nagios XI plugins, scripts, scheduled tasks, users, API keys, notification integrations, and configuration files for unauthorized changes.
• Add SIEM detections for command_test.php access and for web-server processes spawning command interpreters or network utilities.
• Because the EPSS score is high, continue monitoring for opportunistic exploitation even though this CVE is not currently listed in CISA KEV.