CVE-2025-24367

What it actually does

Cacti contains an authenticated remote code execution flaw in graph creation and graph template handling. A user who can log in to Cacti can abuse legitimate template or graph-management functionality to cause attacker-controlled PHP content to be written into the web-accessible application directory. Once the PHP file exists under the web root, the attacker can request it over HTTP and execute code with the privileges of the web server user, potentially allowing command execution, file access, credential theft, persistence, and lateral movement from the monitoring server.

Why it matters to the business

A compromised Cacti server can expose sensitive monitoring data, network topology, device credentials, SNMP community strings, API tokens, and operational telemetry. Because Cacti commonly monitors routers, switches, firewalls, servers, and business-critical infrastructure, exploitation can give attackers a valuable foothold for broader internal reconnaissance and disruption. The vulnerability has weaponized exploit maturity, a high EPSS score, and has been public for an extended period, so internet-accessible or broadly reachable Cacti deployments should be treated as high-priority even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first obtains valid Cacti credentials, either through phishing, credential reuse, default or weak passwords, prior compromise, or access to a low-privileged account. After authentication, the attacker uses graph creation and graph template features in a way that causes Cacti to write PHP content into a location served by the web server. The attacker then sends an HTTP request to the newly created PHP file, triggering server-side execution. From there, the attacker can run commands as the web server account, deploy a web shell, read application configuration files, harvest database credentials, access monitored-device secrets, stage additional tools, and use the Cacti host as an internal pivot point.

How to fix it

Upgrade Cacti to version 1.2.29 or later. For Git-based deployments, ensure the code includes commit c7e4ee798d263a3209ae6e7ba182c7b65284d8f0 or a later fixed revision. After upgrading, review the Cacti installation directory and web root for unauthorized PHP files, restore application files from trusted packages where possible, and rotate credentials stored or used by Cacti if compromise is suspected. Restrict Cacti administrative and graph-template management access to trusted users only, enforce MFA where supported through the identity provider or reverse proxy, and limit network access to the Cacti interface using VPN, allowlists, or administrative network segmentation. Configure the web server to prevent execution of user-writable files where feasible and ensure filesystem permissions do not allow the web server process to write arbitrary executable PHP files into the application root.

How to confirm the fix worked

Confirm the running Cacti version reports 1.2.29 or later, or verify the deployed Git revision includes c7e4ee798d263a3209ae6e7ba182c7b65284d8f0 or a later fixed commit. Validate that authenticated users cannot create or modify graph templates in a way that writes executable PHP files into the web-accessible Cacti directory. Inspect the Cacti web root for recently created or modified PHP files that are not part of the official release package. Compare the deployed file tree against a clean Cacti 1.2.29 distribution. Review web server configuration to confirm untrusted upload or generated-content paths do not execute PHP. If a vulnerability scanner is used, ensure it performs version detection and, where appropriate, authenticated checks rather than relying only on unauthenticated banners.

Typical attack path

1. Identify a reachable Cacti instance and confirm the application is running a vulnerable version prior to 1.2.29.
2. Obtain valid Cacti credentials through credential theft, password spraying, reuse, phishing, or compromise of an existing user account.
3. Authenticate to the Cacti web interface.
4. Abuse graph creation or graph template functionality to cause attacker-controlled PHP content to be written under the Cacti web root.
5. Request the attacker-created PHP file over HTTP to execute code on the server.
6. Establish persistence, commonly through a web shell, scheduled task, cron entry, modified application file, or secondary payload.
7. Read Cacti configuration and database-access files to recover credentials and monitored infrastructure details.
8. Use the compromised monitoring server for internal reconnaissance, credential harvesting, lateral movement, or operational disruption.

How to detect it

Look for signs that an authenticated user created or modified graph templates shortly before a new PHP file appeared in the Cacti web directory and was then requested over HTTP. Relevant sources include Cacti application logs, Cacti database audit/history tables if enabled, web server access logs, web server error logs, PHP-FPM or Apache module logs, operating system authentication logs, process creation telemetry, file integrity monitoring, EDR alerts, and shell history for the web server account. Hunt for POST requests to Cacti graph and template management endpoints followed by GET or POST requests to unusual PHP filenames in the Cacti path. Review file creation and modification timestamps under the Cacti installation directory, especially PHP files not present in the official distribution. Investigate web server child processes spawning shells or command-line utilities, outbound connections from the Cacti server to unfamiliar hosts, and access to configuration files such as include/config.php. If exploitation is suspected, examine whether the attacker read credentials from Cacti configuration or database content and whether those credentials were used elsewhere.

• POST /cacti/graph_templates.php
• POST /cacti/graphs_new.php
• POST /cacti/graphs.php
• GET /cacti/*.php?cmd=
• POST /cacti/*.php
• /var/www/html/cacti/*.php
• /usr/share/cacti/site/*.php
• /usr/share/cacti/*.php
• /var/www/cacti/*.php
• include/config.php
• /var/www/html/cacti/include/config.php
• /usr/share/cacti/site/include/config.php
• apache2 -> /bin/sh
• httpd -> /bin/sh
• php-fpm -> /bin/sh
• www-data /bin/sh
• www-data /bin/bash
• apache /bin/sh
• apache /bin/bash
• nginx /bin/sh
• nginx /bin/bash
• c7e4ee798d263a3209ae6e7ba182c7b65284d8f0

What your security team should do

• Immediately inventory all Cacti deployments and prioritize externally reachable, internet-adjacent, or shared administrative instances.
• Upgrade all affected Cacti instances to 1.2.29 or later, or deploy a fixed Git revision including c7e4ee798d263a3209ae6e7ba182c7b65284d8f0.
• Because exploitation is weaponized and EPSS is high, treat vulnerable authenticated exposure as urgent even without current KEV listing.
• Review Cacti user accounts, remove stale accounts, enforce least privilege, and investigate recent logins from unusual IP addresses or geographies.
• Hunt for unexpected PHP files in the Cacti web root and compare the application directory against a known-good release.
• Rotate Cacti database credentials, monitored-device credentials, SNMP community strings, API tokens, and any secrets accessible to the Cacti application if exploitation is suspected.
• Restrict access to the Cacti web interface to trusted administrative networks, VPNs, or identity-aware proxies.
• Enable centralized logging for Cacti, web server access logs, web server error logs, PHP logs, operating system process creation events, and file integrity monitoring.
• Add detections for authenticated graph/template changes followed by requests to newly created PHP files under the Cacti path.
• If suspicious PHP files or command execution artifacts are found, preserve forensic evidence before cleanup and perform full incident response scoping.