TL;DR
| CVE | CVE-2026-20204 |
| Severity | CVSS 7.1 HIGH |
| Vendor | Splunk |
| Product | Splunk Enterprise, Splunk Cloud Platform |
| Vuln Type | Remote Code Execution (file upload to apptemp) |
| Auth Required | Yes (low-privilege user, no admin/power role needed) |
| Patch | Upgrade to Enterprise 10.2.1+, 10.0.5+, 9.4.10+, 9.3.11+ |
| Advisory | SVD-2026-0403 |
What This Vulnerability Is
In Splunk Enterprise versions below 10.2.1, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the `admin` or `power` Splunk roles could potentially perform a Remote Code Execution (RCE) by uploading a malicious file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory due to improper handling and insufficient isolation of temporary files within the `apptemp` directory.
The National Vulnerability Database assigned this issue a CVSS base score of 7.1, placing it in the HIGH category. The identifier CVE-2026-20204 was published on 2026-04-15T16:16:34.490.
- CVE Identifier
- CVE-2026-20204
- CVSS Base Score
- 7.1 / 10.0 (HIGH)
- Published
- 2026-04-15T16:16:34.490
- NVD Entry
- https://nvd.nist.gov/vuln/detail/CVE-2026-20204
- MITRE Entry
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-20204
Who Is Affected
Based on the vulnerability data published by NVD, the following products and configurations are identified as affected:
- Specific affected products are listed in the NVD entry. Review the CPE data for your stack.
If your organization uses any of the above, this vulnerability applies to your environment. Even if your specific version is not listed, review the full CPE match data to confirm.
Detection: Sigma Rule
The following Sigma rule detects suspicious file uploads to the Splunk apptemp directory, which is the attack vector for CVE-2026-20204.
title: CVE-2026-20204 - Suspicious File Upload to Splunk apptemp
id: 8f3a2c1e-4b5d-4e6f-9a7b-1c2d3e4f5a6b
status: experimental
description: Detects file creation in the Splunk apptemp directory by non-admin processes, indicating potential RCE exploitation via CVE-2026-20204
author: Sherlock Forensics
date: 2026/04/20
references:
- https://advisory.splunk.com/advisories/SVD-2026-0403
- https://nvd.nist.gov/vuln/detail/CVE-2026-20204
logsource:
product: splunk
category: file_event
detection:
selection_path:
TargetFilename|contains: '/var/run/splunk/apptemp/'
selection_extensions:
TargetFilename|endswith:
- '.py'
- '.sh'
- '.exe'
- '.so'
- '.dll'
- '.tar.gz'
- '.tgz'
- '.spl'
filter_admin:
User|contains:
- 'admin'
- 'splunk-system-user'
condition: selection_path and selection_extensions and not filter_admin
falsepositives:
- Legitimate app installations by non-admin users (rare)
- Automated deployment tools using the apptemp path
level: high
tags:
- attack.execution
- attack.t1059
- attack.t1105
- cve.2026.20204
Detection: Snort/Suricata IDS Rules
These network-level rules detect HTTP requests targeting the Splunk apptemp upload functionality.
# Snort/Suricata rules for CVE-2026-20204
# Detects upload attempts to the Splunk apptemp directory
alert http $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (
msg:"SHERLOCK CVE-2026-20204 Splunk apptemp Upload Attempt";
flow:established,to_server;
content:"POST"; http_method;
content:"/services/apps/local"; http_uri;
content:"apptemp"; http_client_body;
content:"Content-Type|3a| multipart/form-data"; http_header;
classtype:web-application-attack;
sid:2026204001; rev:1;
reference:cve,2026-20204;
metadata:affected_product Splunk_Enterprise, severity high;
)
alert http $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (
msg:"SHERLOCK CVE-2026-20204 Splunk Malicious SPL Upload";
flow:established,to_server;
content:"POST"; http_method;
content:"/services/apps/install"; http_uri;
file_data; content:"PK"; depth:2;
content:".py"; distance:0;
classtype:web-application-attack;
sid:2026204002; rev:1;
reference:cve,2026-20204;
metadata:affected_product Splunk_Enterprise, severity high;
)
Illustrative Exploit Pattern
ILLUSTRATIVE ONLY. This is a simplified representation of the attack pattern for detection engineering purposes. This is not a working exploit.
The attack exploits insufficient isolation of the apptemp directory. A low-privileged user uploads a crafted file that gets processed by Splunk's app installation handler:
# ILLUSTRATIVE — NOT A WORKING EXPLOIT
# Shows the HTTP pattern for detection signature development
# Step 1: Attacker authenticates as a low-privilege user
POST /services/auth/login HTTP/1.1
Host: splunk-target:8089
Content-Type: application/x-www-form-urlencoded
username=lowpriv_user&password=********
# Step 2: Upload crafted archive to apptemp
POST /services/apps/local HTTP/1.1
Host: splunk-target:8089
Authorization: Splunk [session_token]
Content-Type: multipart/form-data; boundary=----exploit
------exploit
Content-Disposition: form-data; name="appfile"; filename="malicious_app.spl"
Content-Type: application/octet-stream
[crafted .spl archive containing payload in bin/malicious.py]
------exploit--
# Step 3: File lands in $SPLUNK_HOME/var/run/splunk/apptemp/
# Step 4: Splunk processes the archive, executing embedded scripts
What to Look for in Your Logs
Splunk Internal Logs
Check Splunk's own audit and internal logs for signs of exploitation:
# Check audit.log for suspicious app install attempts
grep -i "apptemp\|app.*install\|upload.*app" $SPLUNK_HOME/var/log/splunk/audit.log
# Check splunkd.log for unusual file operations in apptemp
grep -i "apptemp" $SPLUNK_HOME/var/log/splunk/splunkd.log
# Search for non-admin users attempting app operations
grep -E "user=((?!admin|splunk-system-user)\S+).*action=(install|upload)" \
$SPLUNK_HOME/var/log/splunk/audit.log
# List files in the apptemp directory (should be empty or minimal)
ls -la $SPLUNK_HOME/var/run/splunk/apptemp/
# Check for recently modified files with executable content
find $SPLUNK_HOME/var/run/splunk/apptemp/ -type f -mtime -7 \
-exec file {} \; | grep -i "script\|executable\|python\|ELF"
Splunk SPL Queries
Run these searches inside Splunk to hunt for exploitation indicators:
# Hunt for non-admin app installation attempts
index=_audit action=install_app NOT user=admin NOT user=splunk-system-user
| stats count by user, info, timestamp
# File creation events in apptemp
index=_internal sourcetype=splunkd component=AppInstall
| search "*apptemp*"
| table _time, user, message
# Unusual REST API calls to app endpoints from low-priv users
index=_internal sourcetype=splunkd_access method=POST uri_path="*/apps/*"
| search NOT user=admin
| stats count by user, uri_path, status
Triage Commands
Run these commands on your Splunk server to determine if you are affected and whether exploitation has occurred:
# 1. Check your Splunk version
$SPLUNK_HOME/bin/splunk version
# Vulnerable versions:
# Enterprise: < 10.2.1, < 10.0.5, < 9.4.10, < 9.3.11
# Cloud: < 10.4.2603.0, < 10.3.2512.5, < 10.2.2510.9,
# < 10.1.2507.19, < 10.0.2503.13, < 9.3.2411.127
# 2. Check if apptemp has unexpected files
ls -laR $SPLUNK_HOME/var/run/splunk/apptemp/
# 3. Check file permissions on apptemp directory
stat $SPLUNK_HOME/var/run/splunk/apptemp/
# 4. List all non-admin users with app install capabilities
$SPLUNK_HOME/bin/splunk list user -auth admin:changeme | \
grep -v "admin\|power" | grep "role"
# 5. Review recent authentication events for low-priv users
grep "login" $SPLUNK_HOME/var/log/splunk/audit.log | \
grep -v "admin" | tail -50
# 6. Check for suspicious cron jobs or scripts
find $SPLUNK_HOME/etc/apps/*/bin/ -name "*.py" -newer \
$SPLUNK_HOME/bin/splunk -exec ls -la {} \;
IOC Hunt List
Use these indicators of compromise to determine whether CVE-2026-20204 has been exploited in your environment:
File System Indicators
- Unexpected files in
$SPLUNK_HOME/var/run/splunk/apptemp/ - Python scripts (
.py) in apptemp with execution permissions - Shell scripts (
.sh) in appbin/directories not matching known apps - Splunk app archives (
.spl,.tar.gz) in apptemp from non-admin users - Modified timestamps on files in
$SPLUNK_HOME/etc/apps/not matching deployment schedule
Log Indicators
audit.logentries showingaction=install_appfrom non-admin userssplunkd.logerrors referencing apptemp path with unexpected file types- REST API access logs showing POST to
/services/apps/localor/services/apps/installfrom non-admin sessions - Authentication logs showing low-privilege accounts with unusual activity patterns
Network Indicators
- HTTP POST requests to Splunk management port (8089) containing
multipart/form-datawith app archives - Outbound connections from Splunk server to unknown C2 infrastructure after app installation
- Unusual data volumes from the Splunk server to external IPs
What to Do About It
Here is what we recommend, in order of priority:
- Check your exposure. Determine whether the affected software or component is present in your environment. Asset inventories and software composition analysis (SCA) tools are the fastest route.
- Apply the patch. If a vendor patch or updated version is available, apply it. Check the references below for vendor advisories.
- Mitigate if patching is not immediate. If you cannot patch right now, evaluate whether network segmentation, access control changes, or configuration adjustments reduce the attack surface for this specific vulnerability.
- Monitor for exploitation. Check whether proof-of-concept exploit code exists. The CISA Known Exploited Vulnerabilities catalog tracks actively exploited CVEs.
- Document your response. Record what you checked, when you patched, and what residual risk remains. This matters for compliance and for incident response if this vulnerability is exploited later.
Why This Matters for Companies Without Security Teams
A CVSS score of 7.1 means this vulnerability is straightforward to exploit, likely to cause significant damage, or both. For startups and small companies operating without a dedicated security team, vulnerabilities at this severity level represent real operational risk rather than theoretical concern.
The challenge is not awareness. Vulnerability databases are public. The challenge is triage: understanding whether a given CVE affects your specific stack, and knowing what to do about it before an attacker does. If you lack the internal capacity to perform that assessment, an external review of your exposure is a concrete next step.
Sherlock Forensics provides vulnerability assessment and penetration testing for organizations that need to understand their attack surface without building a full internal security function.