CVE-2026-39938: Critical Unauthenticated LFI in Cacti
| Field | Value |
|---|---|
| CVE ID | CVE-2026-39938 |
| CVSS score | 9.8 |
| Attack vector | Remote, unauthenticated |
| Auth required | None |
| Patch status | Fixed in Cacti 1.2.31 |
TL;DR - Critical unauthenticated LFI affects Cacti 1.2.30 and earlier. - Upgrade internet-exposed and internal Cacti servers to 1.2.31 now. - Exploitation is not confirmed, but severity and lack of auth make this urgent.
What is CVE-2026-39938?
CVE-2026-39938 is a critical vulnerability in Cacti, the open source performance and fault management framework. According to the NVD description, the issue is an unauthenticated local file inclusion (LFI) affecting Cacti versions 1.2.30 and prior. The vulnerability is described as occurring through graph_theme and rrdtool IPC serialization hardening, and it is resolved in version 1.2.31.
From a defender’s perspective, the key risk is straightforward: the bug does not require authentication. That matters more than the exact implementation details when you are triaging exposure. If a Cacti instance is reachable over the network, especially from the internet or from less-trusted internal segments, the lack of an authentication barrier can materially reduce attacker effort and increase scanning interest.
The NVD record assigns a CVSS v3.x base score of 9.8, which places this issue in the critical range. The exact vector string was not available in the provided NVD output, so defenders should avoid assuming any unverified sub-metric. What is verified is the score, the unauthenticated nature of the issue, the affected version range, and the fixed release.
Because the available primary-source text is limited, it is best to describe the flaw conservatively: this is a critical unauthenticated LFI tied to graph_theme handling and rrdtool IPC serialization hardening. Defenders should not overfit their response to one narrow code path. If you run a vulnerable version, assume the whole web application instance is at risk until patched.
Technical Notes
The upstream references tied to the CVE are:
- Patch commit:
https://github.com/Cacti/cacti/commit/9871f0cef9af285398d558c9b3188d5977e01a04 - GitHub Security Advisory:
https://github.com/Cacti/cacti/security/advisories/GHSA-rm7p-qcqm-x5m6
A quick local version check on a Cacti host may look like:
grep -R "define('CACTI_VERSION'" /var/www /usr/share 2>/dev/null
Or, depending on packaging and layout:
php -r "include '/var/www/html/cacti/include/global.php'; echo CACTI_VERSION . PHP_EOL;" 2>/dev/null
If those paths do not match your environment, check your deployment-specific Cacti web root and include directories.
Who is affected?
The affected range that is explicitly confirmed by the NVD description is “versions 1.2.30 and prior.” The fixed version is Cacti 1.2.31. If you operate 1.2.30 or any earlier 1.2.x release, you should treat the instance as vulnerable unless you have independently verified a vendor-backported fix. If you are using distribution packages, that verification matters because package version strings sometimes differ from upstream release numbers.
For most teams, the priority is highest for internet-exposed Cacti systems, followed by systems reachable from user networks, contractor networks, lab segments, or shared management zones. Cacti often has privileged visibility into infrastructure and may hold credentials, topology information, device metadata, monitoring targets, and integration details. Even where an LFI does not directly become code execution, exposure of configuration or sensitive local files can still create follow-on compromise paths.
Internal-only deployments should not be deprioritized too aggressively. In many organizations, “internal” means reachable by broad subnets, VPN users, or compromised endpoints. An unauthenticated flaw in a monitoring platform can be useful to attackers seeking credentials, environment details, or a route into management infrastructure.
If you are unsure about version exposure, assume vulnerable until proven otherwise. That is the safest operational stance because the documented fixed version is specific and available: upgrade to 1.2.31.
| Deployment scenario | Risk guidance |
|---|---|
| Internet-exposed Cacti 1.2.30 or earlier | Highest priority, patch immediately |
| Internal Cacti in shared admin network | High priority, patch quickly and restrict access |
| Segmented Cacti with limited source IPs | Still patch urgently; segmentation helps but does not remove risk |
| Unknown version or inherited appliance build | Assume vulnerable until vendor or package maintainer confirms otherwise |
Exploitation status and defender assumptions
Based on the available research inputs, exploitation in the wild is not confirmed. The vulnerability is not listed in CISA’s Known Exploited Vulnerabilities catalog as of the stated lookup, which means there is no CISA KEV confirmation at this time. That is useful context, but it should not be treated as evidence that no exploitation is happening.
Likewise, no public proof of concept (PoC) was confirmed from the collected primary-source references in this research set. The known references are the official NVD entry, the official Cacti patch commit, and the official GitHub Security Advisory. No exploit repository or public exploit write-up was confirmed in those materials.
In practice, defenders should assume that a critical unauthenticated web flaw in a commonly deployed admin-facing application may attract rapid analysis, especially once a patch exists and a code commit is public. The absence of a confirmed PoC in your current sources only means it was not verified here. It does not mean attackers are unable to reproduce the issue from the fix or advisory.
Operationally, that means your response should be based on exposure and severity, not on waiting for exploitation headlines. For internet-accessible Cacti, immediate patching and short-term access reduction are justified even without public exploitation confirmation.
How to detect exposure and suspicious activity
The first detection step is asset and version discovery. You need to identify every Cacti deployment and confirm whether it is running 1.2.30 or earlier. If you only search CMDB records, you may miss manually deployed instances, inherited virtual appliances, or sidecar monitoring nodes. Use a combination of package inventory, web server virtual host reviews, and network scanning for known Cacti paths.
The second step is request review for suspicious access involving graph_theme, path traversal patterns, and anomalous unauthenticated requests to the Cacti web application. Because the exact exploit request shape is not confirmed in the provided sources, defenders should watch for broad LFI indicators rather than one brittle IOC. Focus on requests containing traversal sequences such as ../, URL-encoded variants, attempts to access sensitive local files, and unusual parameter values associated with theme handling.
You should also review whether the Cacti host exposed sensitive files to the web process and whether outbound alerts or EDR telemetry show post-access follow-on behavior. Even if the vulnerability “only” exposes files, access to configuration or credential material can be enough to enable lateral movement.
Technical Notes
Example web log patterns to review in Apache or Nginx access logs:
"GET /cacti/ HTTP/1.1"
"GET /cacti/*.php?graph_theme=../../../../etc/passwd HTTP/1.1"
"GET /cacti/*.php?graph_theme=%2e%2e%2f%2e%2e%2fetc%2fpasswd HTTP/1.1"
Basic grep hunting on Linux web logs:
grep -RIE 'graph_theme=|(\.\./)|(%2e%2e%2f)|(/etc/passwd)|(/etc/shadow)' /var/log/apache2 /var/log/httpd /var/log/nginx 2>/dev/null
A simple Splunk query for suspicious traversal requests against Cacti paths:
index=web (uri_path="*/cacti/*" OR uri="*/cacti/*")
| search uri_query="*graph_theme*" OR uri_query="*../*" OR uri_query="*%2e%2e%2f*"
| stats count values(src_ip) values(uri) by host
A generic Suricata-style signature example for tuning and validation, not as a definitive exploit signature:
alert http any any -> $HOME_NET any (
msg:"Possible Cacti CVE-2026-39938 traversal attempt";
flow:to_server,established;
http.uri; content:"/cacti/"; nocase;
http.uri; pcre:"/graph_theme=.*(\.\.|%2e%2e)/Ui";
sid:3993801; rev:1;
)
Because the exact exploit syntax is not fully verified in the provided sources, use these as hunting and triage aids, not as complete coverage.
Mitigation and patching guidance
The primary remediation is to upgrade to Cacti 1.2.31, which is the version explicitly identified as resolving the issue. If you maintain Cacti from upstream tarballs or source, ensure the deployed code actually matches 1.2.31 after the change, and do not rely solely on package manager output if you use custom web roots or symlink-based deployments.
If you cannot patch immediately, reduce exposure while scheduling the upgrade. At a minimum, restrict access to the Cacti web interface using a reverse proxy allowlist, VPN-only access, source IP ACLs, or network segmentation. Since the issue is unauthenticated, any reduction in reachable attack surface materially helps. Temporary controls are not a replacement for the fix, but they can shrink the window of exposure.
Teams should also review whether the Cacti instance stores database credentials, SNMP community strings, or integration secrets in files readable by the web application user. If there is any sign of exploitation, treat this as a potential secrets exposure event and rotate credentials accordingly.
Technical Notes
Example upgrade workflow for a source-based deployment should follow your local process, but a conservative Linux-style sequence might look like:
# Back up current deployment and database first
mysqldump -u cacti -p cacti > cacti-backup-$(date +%F).sql
tar -czf cacti-webroot-backup-$(date +%F).tar.gz /var/www/html/cacti
# Deploy fixed release using your approved package/source process
# Then confirm the running version is 1.2.31
php -r "include '/var/www/html/cacti/include/global.php'; echo CACTI_VERSION . PHP_EOL;"
If your environment uses Git to track upstream Cacti source, verify the fixed code reference from the official commit:
git remote -v
git fetch origin
git show 9871f0cef9af285398d558c9b3188d5977e01a04 --stat
Temporary workaround examples while patching is scheduled:
location /cacti/ {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
proxy_pass http://cacti_backend;
}
Or with Apache access control:
<Location "/cacti/">
Require ip 203.0.113.10
Require ip 198.51.100.0/24
</Location>
These workarounds reduce reachability but do not remediate the vulnerability itself. The required fix remains upgrading to Cacti 1.2.31.
References
The authoritative sources confirmed for this article are the NVD entry, the official upstream patch commit, the official GitHub Security Advisory, and the CISA KEV catalog status check. Those are the best current references for affected versions, fixed version, and exploitation status.
- NVD CVE page:
https://nvd.nist.gov/vuln/detail/CVE-2026-39938 - Upstream patch commit:
https://github.com/Cacti/cacti/commit/9871f0cef9af285398d558c9b3188d5977e01a04 - GitHub Security Advisory:
https://github.com/Cacti/cacti/security/advisories/GHSA-rm7p-qcqm-x5m6 - CISA KEV catalog:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
For further reading on related topics, check out our articles on what is CSRF and malware definitions.
If additional upstream advisory detail, exploit analysis, or vendor package backport information emerges later, defenders should revisit detections and compensating controls. As of now, the actionable conclusion is clear: Cacti 1.2.30 and earlier are affected, and 1.2.31 is the fixed release.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.