Splunk Secure Gateway (CVE-2026-20251): jsonpickle Deserialization RCE - A Low-Privilege Account Is All It Takes

A remote code execution vulnerability in the Splunk Secure Gateway app allows any low-privilege Splunk user — no admin role, no power role — to execute arbitrary code on the Splunk server. Tracked as CVE-2026-20251 with a CVSS 3.1 score of 8.8 (High), the flaw stems from unsafe deserialization of KV Store data via the jsonpickle Python library, combined with a validator that can be bypassed by manipulating a single key name. ReactiveZero Security published a proof-of-concept on June 29, 2026.

This is a distinct vulnerability from CVE-2026-20253 (the unauthenticated PostgreSQL sidecar RCE we covered earlier today). CVE-2026-20251 requires an authenticated low-privilege user rather than being pre-auth, but affects a much broader version range — including Splunk Enterprise 9.3.x and 9.4.x branches and Splunk Cloud Platform.

What the Vulnerability Is

The Splunk Secure Gateway (SSG) app provides mobile access to Splunk dashboards and alert notifications. Internally, it stores alert configurations in Splunk's App Key Value Store (KV Store) under a collection called mobile_alerts.

When SSG processes alert data from KV Store, it deserializes the stored JSON using jsonpickle — a Python library that can reconstruct arbitrary Python objects from JSON. The critical property of jsonpickle: a JSON object with a "py/reduce" key causes jsonpickle to call an arbitrary Python callable during deserialization. This is roughly equivalent to Python's pickle — with all the same code-execution risks.

The Validator Bypass

SSG includes a validation function, check_alert_data_valid_json(), intended to reject malicious jsonpickle payloads. It checks whether the JSON contains a "py/object" key and, if so, validates that the object class path starts with "spacebridgeapp" — a namespace prefix for SSG's own classes.

The bypass: the validator only checks "py/object". An attacker who supplies a payload with a "py/reduce" key instead of "py/object" passes the validator entirely, because "py/reduce" is not checked. The exploit structure looks like:

{
  "py/object": "spacebridgeapp.LegitClass",
  "notification": {
    "py/reduce": [
      {"py/type": "os.system"},
      {"py/tuple": ["id > /tmp/pwned"]}
    ]
  }
}

The "py/object" key with the spacebridgeapp prefix satisfies the validator. The sibling "notification" key contains the actual malicious "py/reduce" payload. When SSG later calls jsonpickle.decode(..., safe=True) on this data, safe=True is not effective against py/reduce — it only restricts py/object class instantiation, not reducer-based callable invocations.

Exploitation Flow

1. Attacker authenticates with any low-privilege Splunk account (no elevated roles required, no admin or power).
2. Attacker writes the crafted jsonpickle payload to the mobile_alerts KV Store collection via Splunk's REST API (/servicesNS/nobody/SplunkSpacebridge/storage/collections/data/mobile_alerts).
3. When SSG processes the alert data — which happens automatically during normal operation — jsonpickle.decode() executes the malicious py/reduce payload on the Splunk server.
4. Code executes as the Splunk process user, providing full access to the Splunk installation, indexed data, and any credentials or secrets Splunk can reach.

Affected Versions

Note: Splunk Cloud Platform customers are managed by Splunk. If you're on a supported Cloud tier, your instance should be patched automatically — verify with your Splunk CSM.

Who Is Affected

Any organization running Splunk for SIEM, log aggregation, or security monitoring where:

• Splunk Enterprise is self-hosted at an affected version, AND
• The Splunk Secure Gateway app is installed and enabled (it ships by default with Splunk Enterprise 9.x and 10.x for mobile alert functionality)

The threat model that most concerns defenders: insider threat or phishing of a low-privilege analyst account. A junior SOC analyst with a read-only Splunk account has enough access to exploit this vulnerability. No privilege escalation chain is needed before reaching the RCE step.

Why safe=True in jsonpickle Didn't Help

jsonpickle's safe=True mode restricts which classes can be instantiated via the py/object mechanism. It is not a general deserialization sandbox. The py/reduce mechanism — which invokes Python's __reduce__ protocol — bypasses safe=True entirely, because safe mode was designed for a different threat model. This is a well-understood limitation of jsonpickle that has appeared in multiple vulnerability disclosures over the years; SSG's use of safe=True as a security control reflects an incomplete understanding of the library's attack surface.

The correct fix — now reflected in SSG 3.8.67, 3.9.20, and 3.10.6 — is to not deserialize KV Store data with jsonpickle at all for alert payloads, or to deserialize only after cryptographic signature verification of KV Store writes.

Remediation

Priority action: Update the Splunk Secure Gateway app.

1. Update SSG to the patched version for your Splunk Enterprise branch:
   • SSG 3.10.6 (for Enterprise 10.2.x / 10.4.x)
   • SSG 3.9.20 (for Enterprise 10.0.x)
   • SSG 3.8.67 (for Enterprise 9.3.x / 9.4.x)
2. Update Splunk Enterprise to the corresponding fixed release (9.3.13, 9.4.12, 10.0.7, or 10.2.4). The fixed Enterprise releases bundle the patched SSG version.
3. If immediate patching is not possible: Disable the Splunk Secure Gateway app under Apps → Manage Apps → Splunk Secure Gateway → Disable. This removes the vulnerable alert-processing path. Assess the operational impact; SSG is required for Splunk Mobile, but disabling it does not affect core Splunk search and alerting.
4. Audit KV Store for existing payloads: If you believe exploitation may have occurred before patching, inspect the mobile_alerts KV Store collection for any entries containing py/reduce or py/type keys. A REST API query against /servicesNS/nobody/SplunkSpacebridge/storage/collections/data/mobile_alerts will return the stored JSON for inspection.
5. Review low-privilege account activity: Check Splunk's audit logs (index=_audit) for any REST API writes to the mobile_alerts collection by non-admin users, particularly in the period between June 29, 2026, and your patch date.

Proof-of-Concept Status

ReactiveZero Security published a full PoC exploit on June 29, 2026, on GitHub. The PoC demonstrates end-to-end RCE via a low-privilege Splunk account. Treat this as actively exploitable. The exploit complexity is low — a valid Splunk account and a single REST API call are all that is required.

References

• Splunk Official Advisory SVD-2026-0601: RCE through Deserialization of Untrusted Data in Splunk Secure Gateway
• GBHackers (June 29, 2026): Splunk Secure Gateway RCE Vulnerability
• CybersecurityNews (June 29, 2026): Splunk Secure Gateway App Vulnerability Let Attackers Execute Remote Code
• SecurityWeek: Atlassian, Splunk Patch High-Severity Vulnerabilities