GBHackers

Splunk Secure Gateway RCE Vulnerability Lets Low-Privileged Attackers Execute Arbitrary Code


A newly disclosed high-severity vulnerability in Splunk Secure Gateway (SSG) allows low-privileged authenticated users to achieve remote code execution (RCE) on affected systems, significantly increasing the attack surface for enterprise Splunk deployments.

This vulnerability, tracked as CVE-2026-20251, has been assigned a CVSS score of 8.8. It arises from the unsafe deserialization of user-controlled data using the Python jsonpickle library.

Splunk Secure Gateway RCE Vulnerability

Research published by ReactiveZero Security reveals that the vulnerability is linked to how SSG processes alert data stored in the KV Store, specifically in the “mobile_alerts” collection.

A low-privileged attacker can inject a specially crafted JSON document via the Splunk REST API. When SSG processes this data, it passes the malicious payload through a flawed validation routine to jsonpickle.decode(), ultimately allowing arbitrary code execution under the Splunk service account.

The root cause lies in two critical issues: a validator bypass and unsafe deserialization. The validation function, check_alert_data_valid_json(), is designed to block malicious structures but incorrectly short-circuits when encountering a permitted key such as “py/object”.

If this key appears first and matches expected prefixes (e.g., spacebridgeapp), the function immediately returns true without inspecting other fields. This allows attackers to embed malicious payloads in sibling keys such as “notification”, which remain unchecked.

Once validated, the data is passed to jsonpickle.decode(…, safe=True). Despite the safe flag, dangerous deserialization paths such as “py/reduce” remain exploitable. Attackers can leverage this to invoke arbitrary Python functions, including system-level commands via the subprocess module.

A typical exploit chain involves writing a malicious document to the KV Store, triggering SSG to process the alert, bypassing validation, and executing the payload during deserialization. Notably, this attack requires only a valid low-privilege Splunk account and does not depend on user interaction.

Below is a simplified proof-of-concept (PoC) demonstrating the vulnerability using a benign command:

import jsonpickle

import subprocess

payload = {
    "py/object": "spacebridgeapp.data.alert_data.Alert",
    "notification": 
        "py/reduce": [
            {"py/function": "subprocess.check_output"},
            {"py/tuple": [["uname", "-a"]]}

        ]

    }

}

encoded = jsonpickle.encode(payload)
decoded = jsonpickle.decode(encoded, safe=True)
print(decoded)

This PoC illustrates how jsonpickle executes subprocess.check_output([“uname”, “-a”]) during deserialization, confirming that the safe=True flag does not prevent exploitation of the py/reduce pathway.

The vulnerability affects multiple versions of Splunk Secure Gateway, including 3.8.x, 3.9.x, and 3.10.x, as well as Splunk Enterprise versions before the patched releases (10.0.7, 10.2.4, and 10.4.0+). Splunk has addressed the issue in SSG versions 3.8.67, 3.9.20, and 3.10.6.

Security experts recommend immediate patching as the primary remediation. Organizations unable to patch immediately should turn off the Secure Gateway app if unused, restrict KV Store write permissions, and enforce strict access controls.

Additionally, developers are advised to avoid deserializing untrusted data using jsonpickle or similar libraries without strict schema validation or class allow-listing.

This vulnerability highlights a recurring security anti-pattern in Python applications: unsafe deserialization of user-controlled data. Even with protective flags enabled, incomplete validation logic can render these safeguards ineffective, resulting in a full system compromise.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.



Source link