CVE-2026-20251: Splunk Remote Code Execution via KV Store Deserialization

Technical summary

CVE-2026-20251 exploits unsafe deserialization in the Splunk Secure Gateway app through the jsonpickle Python library. The vulnerability resides in how KV Store data is processed when retrieved and deserialized. The jsonpickle library reconstructs arbitrary Python objects from JSON without sufficient validation, allowing an attacker to craft malicious JSON payloads that instantiate dangerous classes. Since KV Store data can be accessed by low-privileged users, an attacker can inject malicious serialized objects that execute code during deserialization. This is a classic deserialization RCE pattern (CWE-502) where untrusted data is reconstructed into executable code without sanitization.

Business impact

This vulnerability poses an immediate and severe risk to any organization running Splunk. Because it requires only basic user credentials and can result in complete code execution, a disgruntled employee or attacker with low-level access could gain full control of Splunk infrastructure. Given that Splunk often serves as a central logging and monitoring platform, compromise could lead to log tampering, data exfiltration, lateral movement to monitored systems, and loss of visibility into security events. Organizations relying on Splunk for compliance reporting and incident response face potential regulatory violations and operational blindness during active attacks.

Affected systems

Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13 are vulnerable. Splunk Cloud Platform versions below 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132 are affected. Splunk Secure Gateway versions below 3.10.6, 3.9.20, and 3.8.67 are vulnerable. Organizations using any combination of these products with versions at or below the affected thresholds must treat this as critical. The vulnerability spans multiple product lines, making comprehensive inventory and patch assessment essential.

Exploitability

Exploitability is straightforward: the attack requires network access to the Splunk instance and valid, low-privileged user credentials. No authentication bypass is needed, and the attack vector is network-based with low complexity. An attacker with basic Splunk user permissions can craft and submit malicious KV Store data. The absence of adequate input validation means the jsonpickle library will deserialize arbitrary Python objects, leading directly to code execution. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects this: any authenticated user can achieve complete system compromise without user interaction. However, the vulnerability is not yet listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, suggesting active in-the-wild exploitation may not yet be widespread, though this should not delay patching.

Remediation

Immediate patching is mandatory. Update Splunk Enterprise to version 10.2.4, 10.0.7, 9.4.12, or 9.3.13 depending on your deployment track. For Splunk Cloud Platform, apply versions 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, or 9.3.2411.132. For Splunk Secure Gateway, upgrade to 3.10.6, 3.9.20, or 3.8.67. Test patches in a non-production environment first, as Splunk updates sometimes affect custom configurations or searches. Concurrently, review KV Store access controls and minimize the number of low-privileged users who can write to KV Store data. Consider disabling or restricting the Splunk Secure Gateway app if it is not actively in use.

Patch guidance

Prioritize patching Splunk Secure Gateway first, as the app itself contains the vulnerable deserialization logic. For Splunk Enterprise and Cloud Platform, follow your vendor's standard upgrade procedures, testing in staging environments before production rollout. Review Splunk's security advisories for any dependencies or configuration changes introduced in patched versions. After patching, validate that Secure Gateway functions correctly and that integrations with external applications still work. Splunk typically provides detailed release notes specifying compatibility and any manual remediation steps required.

Detection guidance

Monitor for abnormal KV Store access patterns, particularly writes from low-privileged users. Look for large or unusual JSON payloads being written to KV Store. Enable Splunk's internal logging and audit trails to track KV Store operations. Search for Python exceptions or deserialization errors in Splunk logs that might indicate failed exploitation attempts. Network-level detection should flag unexpected outbound connections from Splunk services following KV Store operations. Additionally, monitor process execution on the Splunk server for unexpected child processes spawned by the Splunk service, which would indicate successful code execution. Implement behavioral detection rules that flag unusual process creation or system calls originating from the Splunk process.

Why prioritize this

This vulnerability merits emergency prioritization due to its combination of low privilege requirements and complete code execution impact. Unlike typical RCE flaws requiring admin credentials, this enables privilege escalation embedded in the exploitation path. The CVSS score of 8.8 (HIGH) reflects the severe consequences, and the network-based attack vector makes it accessible without physical access or social engineering. As Splunk sits at the nexus of security visibility, its compromise directly enables attackers to blind security teams and tamper with forensic evidence. Organizations should treat this as a P0 or P1 issue requiring patching within 24-48 hours for internet-facing instances.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH severity) combines network accessibility (AV:N), low attack complexity (AC:L), and low privilege requirements (PR:L) with high impact across confidentiality, integrity, and availability (C:H/I:H/A:H). The score accurately reflects the real-world severity: any low-privileged user can execute arbitrary code, leading to complete system compromise. The sole mitigating factor preventing a 9.0+ score is the requirement for some level of valid user authentication, which is nonetheless easy to obtain through password reuse, social engineering, or insider threats. In practice, organizations should treat this as critically severe.

Frequently asked questions