CVE-2023-32707

What it actually does

This vulnerability allows a low-privileged authenticated Splunk user with a role containing the edit_user capability to elevate privileges to the Splunk admin user by sending specially crafted web requests to Splunk Enterprise or Splunk Cloud Platform. Successful exploitation can grant administrative control over the Splunk application, including the ability to modify users and roles, access indexed data, change configuration, install or modify apps, create scripted or modular inputs, and potentially execute code through administrative Splunk features depending on deployment configuration. The issue affects Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform versions below 9.0.2303.100.

Why it matters to the business

A compromised low-privileged Splunk account can become a full administrative account, giving an attacker control over a central logging and security monitoring platform. This can expose sensitive logs, security telemetry, credentials or tokens stored in Splunk configurations, and business data indexed into Splunk. It can also allow attackers to disable or tamper with detections, hide evidence of broader compromise, disrupt monitoring operations, and use Splunk administration features to pivot further. The high EPSS score and weaponized exploit maturity indicate a meaningful likelihood of real-world exploitation where exposed and vulnerable Splunk instances have users with the required capability.

How an attack unfolds

An attacker first obtains valid credentials for a Splunk account that is not an administrator but has a role containing the edit_user capability. This access may come from phishing, credential reuse, leaked credentials, compromised SSO sessions, or an insider account. The attacker authenticates to the Splunk web interface or API and sends crafted HTTP requests that abuse the vulnerable user-management logic. Instead of being limited to permitted account-management actions, the request causes Splunk to grant the attacker administrative privileges or otherwise assume admin-level authority. With admin access, the attacker can create persistent privileged users or tokens, alter roles, inspect indexed data, install malicious or unauthorized apps, modify alerting and audit settings, and remove or obscure traces of activity in Splunk-visible logs.

How to fix it

Upgrade affected Splunk deployments to a fixed version immediately. Splunk Enterprise should be upgraded to 9.0.5 or later, 8.2.11 or later, or 8.1.14 or later, depending on the supported branch in use. Splunk Cloud Platform should be upgraded to 9.0.2303.100 or later; for Splunk Cloud, confirm the service stack has been updated by Splunk or through the relevant support channel. As an interim mitigation, review all roles that include the edit_user capability and remove that capability from non-administrative or unnecessary roles. Restrict access to Splunk Web and management/API endpoints to trusted networks, enforce SSO/MFA where supported, audit all Splunk users and roles, rotate credentials and tokens if exploitation is suspected, and review installed apps and scripted inputs for unauthorized changes.

How to confirm the fix worked

Confirm the running Splunk version is at or above the fixed release for the deployed branch: 9.0.5+, 8.2.11+, 8.1.14+, or Splunk Cloud Platform 9.0.2303.100+. Validate through Splunk Web, the CLI, package inventory, or REST version endpoints. Review role definitions and verify that edit_user is assigned only where strictly required. Test that a non-admin account with user-management permissions cannot modify its own role, grant itself admin-equivalent capabilities, create admin users, or alter protected user records. Confirm that Splunk Web and management ports are not broadly exposed, and review recent user, role, token, app, and configuration changes for unexpected administrative modifications.

Typical attack path

1. Identify an exposed or reachable Splunk Enterprise or Splunk Cloud Platform instance running a vulnerable version.
2. Obtain valid credentials for a low-privileged Splunk user whose assigned role includes the edit_user capability.
3. Authenticate to Splunk Web or Splunk REST endpoints.
4. Send specially crafted user-management web requests that exploit the privilege-escalation flaw.
5. Gain admin-level privileges within Splunk.
6. Establish persistence by creating or modifying users, roles, authentication tokens, or apps.
7. Access sensitive indexed data, change configurations, disable detections, or tamper with audit-relevant settings.
8. Use administrative Splunk capabilities to support broader intrusion activity or conceal evidence.

How to detect it

Investigate Splunk audit and internal logs for evidence that a non-admin user performed user-management actions, changed roles, gained admin capabilities, created new privileged users, or modified authentication settings. Key log sources include Splunk _audit indexes, internal web access logs, splunkd logs, REST API activity, authentication logs, and configuration change records. Look for edit_user-related activity by accounts that should not administer users, rapid role or capability changes followed by administrative actions, new admin accounts, suspicious token creation, app installation, scripted input creation, modular input changes, and attempts to alter or delete audit-relevant data. Because attackers may use this flaw to hide activity, correlate Splunk audit events with external identity provider logs, reverse proxy logs, VPN logs, EDR telemetry, and network access logs. Give special attention to activity from unusual IP addresses, impossible travel patterns, off-hours sessions, newly seen user agents, or accounts that had low privileges shortly before performing admin actions.

• action=edit_user
• action=create_user
• action=delete_user
• action=edit_roles
• action=edit_role
• action=create_role
• action=delete_role
• capability=edit_user
• role=admin
• roles=admin
• user=* action=edit_user
• user=* action=create_user
• user=* action=edit_roles
• /en-US/manager/*/authentication/users
• /en-US/manager/*/authorization/roles
• /services/authentication/users
• /services/authorization/roles
• /services/authentication/users/*
• /services/authorization/roles/*
• splunkd_access.log
• audit.log
• index=_audit action=edit_user
• index=_audit action=create_user
• index=_audit action=edit_roles
• index=_audit capability=edit_user
• index=_internal source=*splunkd_access.log* /services/authentication/users
• index=_internal source=*splunkd_access.log* /services/authorization/roles

What your security team should do

• Prioritize upgrade or Splunk Cloud version confirmation because exploit maturity is weaponized and EPSS is high.
• Inventory all Splunk Enterprise and Splunk Cloud Platform deployments, including test, development, search head, deployment server, and standalone instances.
• Remove the edit_user capability from any non-admin or broadly assigned roles unless there is a documented operational requirement.
• Hunt for recent privilege changes, new admin users, modified roles, new authentication tokens, and unexpected app installations around and after the vulnerability publication date.
• Restrict Splunk Web and REST management access to trusted administrative networks or VPN paths.
• Enforce MFA or strong SSO controls for Splunk access, especially for accounts with user-management capabilities.
• Rotate Splunk credentials, session tokens, API tokens, and relevant secrets if suspicious privilege changes or account activity are found.
• Review Splunk audit logs and configuration history for attempts to modify users, roles, capabilities, authentication settings, scripted inputs, modular inputs, or apps.
• Verify alerting and monitoring configurations have not been disabled, altered, or suppressed by a newly privileged user.