CVE-2026-20204: In Splunk Enterprise versions Remote code execution Enables Remote Exploitation

CVE-2026-20204 is a high severity vulnerability (CVSS 7.1) identified in the National Vulnerability Database. 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

TL;DR

CVECVE-2026-20204
SeverityCVSS 7.1 HIGH
VendorSplunk
ProductSplunk Enterprise, Splunk Cloud Platform
Vuln TypeRemote Code Execution (file upload to apptemp)
Auth RequiredYes (low-privilege user, no admin/power role needed)
PatchUpgrade to Enterprise 10.2.1+, 10.0.5+, 9.4.10+, 9.3.11+
AdvisorySVD-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 app bin/ 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.log entries showing action=install_app from non-admin users
  • splunkd.log errors referencing apptemp path with unexpected file types
  • REST API access logs showing POST to /services/apps/local or /services/apps/install from 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-data with 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:

  1. 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.
  2. Apply the patch. If a vendor patch or updated version is available, apply it. Check the references below for vendor advisories.
  3. 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.
  4. Monitor for exploitation. Check whether proof-of-concept exploit code exists. The CISA Known Exploited Vulnerabilities catalog tracks actively exploited CVEs.
  5. 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.

References and Further Reading