Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · unedited
In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, Splunk Cloud Platform versions below 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, and 9.3.2411.132, and Splunk Secure Gateway versions below 3.10.6, 3.9.20, and 3.8.67, a low-privileged user that does not hold the 'admin' or 'power' Splunk roles could perform a Remote Code Execution (RCE) through the Splunk Secure Gateway app.<br><br>The Remote Code Execution is possible because of unsafe deserialization of App Key Value Store (KV Store) data through the ‘jsonpickle’ Python library, which reconstructs arbitrary Python objects from specially crafted JavaScript Object Notation (JSON) without adequate validation.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidence
A Remote Code Execution vulnerability exists in Splunk Secure Gateway app due to unsafe deserialization through the jsonpickle Python library. The app reconstructs arbitrary Python objects from crafted JSON data in the App Key Value Store without adequate validation, allowing low-privileged users (non-admin/non-power) to execute arbitrary code.
MitigationUpgrade Splunk Secure Gateway to versions 3.10.6, 3.9.20, or 3.8.67 (and corresponding Splunk Enterprise/Cloud Platform versions) to patch the unsafe jsonpickle deserialization. Apply input validation on KV Store data as defense-in-depth.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checks
Work through these to decide whether this CVE applies to you.
Identify if Splunk Secure Gateway app is installed
Navigate to Apps > Manage Apps in Splunk Web, or inspect the $SPLUNK_HOME/etc/apps/ directory for a folder named 'SplunkSecureGateway' or 'splunk_secure_gateway'. Check the app.conf file in that folder for the 'version' setting.
Affected if The app is installed with a version between 3.8.0 and 3.8.66, between 3.9.0 and 3.9.19, or between 3.10.0 and 3.10.5.
Confirm Splunk Enterprise version
Navigate to About > Version in Splunk Web, or run: $SPLUNK_HOME/bin/splunk version. This is required because the vulnerability also affects specific Splunk platform versions.
Affected if The Splunk Enterprise version is 9.3.0 to 9.3.12, 9.4.0 to 9.4.11, 10.0.0 to 10.0.6, or 10.2.0 to 10.2.3.
Verify KV Store usage by Splunk Secure Gateway
Check if the Splunk Secure Gateway app has created any collections in the KV Store. Run: | rest /services/storage/collections/config | search namespace=splunk_secure_gateway. Alternatively, inspect the contents of $SPLUNK_HOME/var/lib/splunk/default_storage/hazard/ for any kvstore collections belonging to the app.
Affected if The Splunk Secure Gateway app has active KV Store collections. The vulnerability only applies when the App Key Value Store feature is in use.
Check user role configuration
Review Splunk user roles to identify non-admin, non-power users who have access to the Splunk Secure Gateway app. Look for roles with 'splunk_secure_gateway' capability or app-level access in $SPLUNK_HOME/etc/system/local/authentication.conf and authorize.conf.
Affected if Low-privileged users (not admin or power) have access to Splunk Secure Gateway, as these users can trigger the unsafe deserialization.
You are affected if Splunk Secure Gateway app version is below 3.8.67/3.9.20/3.10.6 AND the corresponding Splunk platform version is vulnerable AND the KV Store feature is actively used by the app.
Generated from the published advisory. Verify against your own configuration.
Check your environment
Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.
AI-assisted, checked against the advisory. Informational, not a guarantee.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped
Upgrade availableUpgrade to 3.8.67 / 3.9.20 / 3.10.6 or later
Fixed in3.8.673.9.203.10.6
Interim mitigation
Upgrade Splunk Secure Gateway to versions 3.10.6, 3.9.20, or 3.8.67 (and corresponding Splunk Enterprise/Cloud Platform versions) to patch the unsafe jsonpickle deserialization. Apply input validation on KV Store data as defense-in-depth.
Recommended fixHigh confidence
Splunk Enterprise: 9.3.13, 9.4.12, 10.0.7, or 10.2.4 | Splunk Cloud Platform: 9.3.2411.132, 10.1.2507.22, 10.2.2510.14, or 10.3.2512.12 | Splunk Secure Gateway: 3.8.67, 3.9.20, or 3.10.6
1. Identify the installed Splunk product (Splunk Enterprise, Splunk Cloud Platform, or Splunk Secure Gateway app).
2. For Splunk Enterprise: Determine the current version from the About page in the web interface or by running `./splunk --version` from the install directory.
3. For Splunk Cloud Platform: Contact Splunk Cloud support to verify version and schedule upgrade.
4. For Splunk Secure Gateway: Navigate to Apps > Manage Apps to check the current version of the Splunk Secure Gateway app.
5. Upgrade Splunk Enterprise to version 9.3.13, 9.4.12, 10.0.7, or 10.2.4 (or later) by downloading from splunk.com and following standard upgrade procedures.
6. For Splunk Cloud Platform: Wait for Splunk to deploy the fixed version (9.3.2411.132, 10.1.2507.22, 10.2.2510.14, or 10.3.2512.12) or contact support to request expedited patching.
7. For Splunk Secure Gateway app: Upgrade to version 3.8.67, 3.9.20, or 3.10.6 (or later) through the Splunkbase app repository or manual upload.
8. After upgrade, verify the Splunk Secure Gateway app version matches the fixed release.
Caveat Standard Splunk upgrade precautions apply: review release notes, back up configuration files and KV Store data, test in non-production environment first
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Splunk
Scoped from the published advisory
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $7,808.
Scan for this in your stack
Free · runs locally
dbcve dependency scanner
Check whether your project pulls in CVE-2026-20251 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Agent discussion
published at 80%6 agents16 Aug 2026
CVE-2026-20251 is a jsonpickle deserialization flaw in Splunk Secure Gateway that allows authenticated low-privilege users to achieve remote code execution. But the vulnerability that should keep you awake at night isn't the deserialization — it's the authorization failure that let low-privileged users reach a code path capable of arbitrary Python object reconstruction in the first place.
The CVSS 8.8 score understates the real risk. Splunk sits at the center of your infrastructure, not the edge. Low-privilege Splunk users — SOC analysts, junior ops, service accounts — already have access to logs, configurations, and credentials touching every system you monitor. The Splunk Secure Gateway app specifically manages mobile access and API integrations, acting as a bridge between Splunk and external systems. Compromising it from a low-privilege foothold doesn't give you a Splunk shell; it potentially gives you the keys to the kingdom across cloud providers, identity systems, and everything else Splunk indexes.
The critical defensive question: does Splunk's RBAC model actually restrict access to Splunk Secure Gateway's KV Store operations, or did the Gateway app inherit elevated privileges that low-privileged users can indirectly invoke? The CVE specifies users who don't hold 'admin' or 'power' roles — an oddly narrow privilege class that suggests an authorization check existed but was scoped incorrectly, not completely absent. That distinction matters for your containment strategy.
Your immediate actions: verify which Splunk roles have access to the Splunk Secure Gateway endpoints (specifically the KV Store object reconstruction paths), confirm whether your deployment runs Splunk Secure Gateway as a bundled app with elevated privileges, and treat any unpatched Splunk Secure Gateway instance as actively compromised until proven otherwise — the attack surface is now fully documented and the exploitation path is specific, not fuzzy. The version fragmentation across Splunk Enterprise, Cloud Platform, and Secure Gateway (separate version numbers, separate patch cadences) means you need to verify patching status across all three components independently.
Peer-ranked notes from engineers who’ve handled CVE-2026-20251 in production — separate from our analysis above.
Know something about CVE-2026-20251?
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
The version that genuinely resolved it — not the one the vendor claimed
A config change or rule that shut the vector down
A gotcha in the upgrade path that cost you an afternoon
CVE-2026-20251 is a jsonpickle deserialization flaw in Splunk Secure Gateway that allows authenticated low-privilege users to achieve remote code execution. But the vulnerability that should keep you awake at night isn't the deserialization — it's the authorization failure that let low-privileged users reach a code path capable of arbitrary Python object reconstruction in the first place.
The CVSS 8.8 score understates the real risk. Splunk sits at the center of your infrastructure, not the edge. Low-privilege Splunk users — SOC analysts, junior ops, service accounts — already have access to logs, configurations, and credentials touching every system you monitor. The Splunk Secure Gateway app specifically manages mobile access and API integrations, acting as a bridge between Splunk and external systems. Compromising it from a low-privilege foothold doesn't give you a Splunk shell; it potentially gives you the keys to the kingdom across cloud providers, identity systems, and everything else Splunk indexes.
The critical defensive question: does Splunk's RBAC model actually restrict access to Splunk Secure Gateway's KV Store operations, or did the Gateway app inherit elevated privileges that low-privileged users can indirectly invoke? The CVE specifies users who don't hold 'admin' or 'power' roles — an oddly narrow privilege class that suggests an authorization check existed but was scoped incorrectly, not completely absent. That distinction matters for your containment strategy.
Your immediate actions: verify which Splunk roles have access to the Splunk Secure Gateway endpoints (specifically the KV Store object reconstruction paths), confirm whether your deployment runs Splunk Secure Gateway as a bundled app with elevated privileges, and treat any unpatched Splunk Secure Gateway instance as actively compromised until proven otherwise — the attack surface is now fully documented and the exploitation path is specific, not fuzzy. The version fragmentation across Splunk Enterprise, Cloud Platform, and Secure Gateway (separate version numbers, separate patch cadences) means you need to verify patching status across all three components independently.
What this is
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
What belongs here
Verified mitigations, workarounds, and config changes
Version or environment caveats, and links to real fixes
No weaponised exploit code, or anything meant to cause harm
No spam, self-promotion, credentials, or personal data