CVE-2023-46214

What it actually does

Splunk Enterprise versions below 9.0.7 and 9.1.2 improperly sanitize user-supplied XSLT. When a malicious stylesheet is processed by the Splunk instance, the XSLT processor can be abused to execute attacker-controlled code or access sensitive local resources, resulting in remote code execution in the security context of the Splunk service. The CVSS vector indicates network reachability, low attack complexity, no privileges required, but user interaction is required; successful exploitation can compromise confidentiality, integrity, and availability of the Splunk instance.

Why it matters to the business

A compromised Splunk instance can expose highly sensitive operational, security, and business telemetry because Splunk often centralizes logs from many systems. An attacker who gains code execution may steal indexed data, alter searches or dashboards, deploy persistence, pivot using credentials or tokens stored on the server, disrupt monitoring, or impair incident response visibility. The high EPSS score and weaponized exploit maturity indicate elevated real-world exploitation likelihood, even though the issue is not currently listed in CISA KEV.

How an attack unfolds

An attacker targets a vulnerable Splunk Enterprise deployment and submits a crafted XSLT payload through functionality that accepts or processes user-provided XSLT. The payload is designed to abuse unsafe transformation behavior so that, when Splunk processes it, the underlying XSLT engine performs unintended actions such as reading local files, making outbound requests, or invoking code execution paths. Because user interaction is part of the CVSS assessment, exploitation may involve convincing an authorized user or workflow to import, open, preview, or process the malicious transformation. Once execution is achieved, the attacker runs commands as the Splunk service account, collects configuration files and credentials, accesses indexed log data, establishes persistence through scripts or app modifications, and may use the compromised server as a foothold into connected infrastructure.

How to fix it

Upgrade Splunk Enterprise to version 9.0.7, 9.1.2, or later. Splunk Cloud customers should confirm their stack has received the vendor-managed fixed release. If immediate upgrade is not possible, restrict access to Splunk management and user-facing interfaces to trusted networks and authenticated users, disable or tightly control any functionality that allows XSLT upload or transformation, review installed apps that process XML/XSLT, and enforce least privilege for the Splunk service account. Rotate Splunk credentials, tokens, and integration secrets if exploitation is suspected. Apply compensating controls such as WAF rules, file integrity monitoring on Splunk app/config directories, and outbound network egress controls from Splunk servers.

How to confirm the fix worked

Confirm the running Splunk Enterprise version is 9.0.7, 9.1.2, or later by checking the Splunk UI, CLI, or version file. Validate that no vulnerable nodes remain in clustered search heads, indexers, deployment servers, heavy forwarders, or standalone instances. Review whether any custom apps or workflows still allow untrusted XSLT processing. Attempt a controlled negative test using benign XSLT with restricted external entity, file, or extension-function behavior to confirm unsafe processing is blocked. Verify file permissions and service account restrictions, and ensure Splunk Cloud environments show the patched service version from Splunk support or administrative release information.

Typical attack path

1. Identify an exposed or reachable Splunk Enterprise instance running a version below 9.0.7 or 9.1.2.
2. Locate a workflow, endpoint, app, or feature path that accepts XSLT input or causes XSLT processing.
3. Deliver a malicious XSLT payload directly or through a social-engineered workflow requiring a user to process the content.
4. Trigger XSLT transformation on the Splunk server.
5. Achieve command execution or sensitive file access in the context of the Splunk service account.
6. Enumerate Splunk configuration, authentication material, apps, indexed data, and connected integrations.
7. Deploy persistence by modifying Splunk apps, scripts, configuration, scheduled searches, or startup behavior.
8. Exfiltrate data, tamper with logs/searches, or pivot to other systems using recovered credentials or tokens.

How to detect it

Review Splunk internal logs, web access logs, operating system audit logs, EDR telemetry, and network egress records for evidence of malicious XSLT processing or post-exploitation activity. Focus on the period before patching and any time suspicious XML, XSL, XSLT, or app uploads occurred. In Splunk logs, look for requests or errors referencing XSLT transformations, XML parsing, suspicious file upload activity, app installation or modification, and unexpected administrative actions. On the host, investigate child processes spawned by Splunk services, especially shells, scripting runtimes, download utilities, archive tools, or reconnaissance commands. Check Splunk app and configuration directories for recently modified files, unexpected scripts, malicious transforms, new scheduled searches, altered authentication settings, or unauthorized apps. Network telemetry should be reviewed for outbound connections from Splunk servers to unfamiliar IPs, especially immediately after XML/XSLT-related requests or errors. Because Splunk may be the logging platform itself, preserve logs externally where possible and compare endpoint/network telemetry against Splunk records for signs of log tampering or deletion.

• .xsl
• .xslt
• <xsl:stylesheet
• <xsl:transform
• xsl:include
• xsl:import
• document(
• unparsed-text(
• java.lang.Runtime
• Runtime.getRuntime
• ProcessBuilder
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• /opt/splunk/var/log/splunk/web_access.log
• /opt/splunk/var/log/splunk/splunkd.log
• /opt/splunk/etc/apps/
• /opt/splunk/etc/system/local/
• $SPLUNK_HOME/var/log/splunk/web_access.log
• $SPLUNK_HOME/var/log/splunk/splunkd.log
• $SPLUNK_HOME/etc/apps/
• $SPLUNK_HOME/etc/system/local/
• C:\Program Files\Splunk\var\log\splunk\web_access.log
• C:\Program Files\Splunk\var\log\splunk\splunkd.log
• C:\Program Files\Splunk\etc\apps\
• C:\Program Files\Splunk\etc\system\local\

What your security team should do

• Prioritize patching to Splunk Enterprise 9.0.7, 9.1.2, or later because exploit code is weaponized and EPSS indicates high exploitation probability.
• Inventory all Splunk Enterprise roles, including search heads, indexers, deployment servers, heavy forwarders, and test systems, for vulnerable versions.
• Limit Splunk web, management, and app upload interfaces to trusted administrative networks until all instances are patched.
• Audit recent XSLT, XML, app, lookup, dashboard, and configuration uploads or modifications for suspicious content.
• Hunt for command execution, unexpected child processes, outbound connections, and file changes originating from Splunk processes.
• Review and rotate Splunk administrative credentials, session tokens, HEC tokens, deployment server credentials, and integration secrets if suspicious activity is found.
• Enable or tune file integrity monitoring for Splunk app directories, configuration files, scripts, and startup-related paths.
• Ensure incident responders treat Splunk compromise as high impact because it may affect log integrity and security monitoring visibility.