CVE-2026-20138: Splunk Enterprise · Sensitive Data in Logs
Affects Splunk EnterpriseSource CVE Database V5
Not known to be exploited · CVSS 6.8 Medium · fixed in 10.0.2 : update Splunk Enterprise when convenient.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 27% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 10.0.2, 9.4.7, 9.3.9 +1
CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 18 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade Splunk Enterprise to 10.0.2, 9.4.7, 9.3.9 or 9.2.11.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| SplunkSplunk Enterprise | Affected
| Fixed in
|
| SplunkSplunk Enterprise | Affected
| Fixed in
|
| SplunkSplunk Enterprise | Affected
| Fixed in
|
| SplunkSplunk Enterprise | Affected
| Fixed in
|
AI-suggested
To mitigate CVE-2026-20138, organizations should prioritize upgrading Splunk Enterprise to versions 10.2.0, 10.0.2, 9.4.7, 9.3.9, or 9.2.11 and later, where this issue is resolved. If you cannot patch yet, restrict access to the _internal index strictly to trusted administrators with a clear need, minimizing the number of users who can view sensitive logs. Implement strict role-based access controls (RBAC) and audit access to internal indexes to detect any unauthorized attempts to view sensitive information. Review and sanitize log configurations to prevent logging of sensitive keys or secrets, and consider encrypting log data at rest and in transit. Additionally, rotate Duo 2FA keys if exposure is suspected to invalidate compromised secrets. Monitor Splunk logs and user activities for unusual access patterns or attempts to extract sensitive data. Educate administrators about the risks of exposing secrets in logs and enforce secure logging practices. Finally, consider isolating Duo 2FA integration components and limiting their logging verbosity to reduce sensitive data exposure.
Description
In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the `integrationKey`, `secretKey`, and `appSecretKey` secrets, generated by [Duo Two-Factor Authentication for Splunk Enterprise](https://duo.com/docs/splunk), in plain text.