CVE-2026-20144: Splunk Enterprise · Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
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 25 Oct 2026, 19:02 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.8 +4
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 2026-10-25.
What to do
Upgrade Splunk to 10.0.2, 9.4.7, 9.3.8 or 9.2.11 (Enterprise); 10.1.2507.11, 10.0.2503.9 or 9.3.2411.120 (Cloud Platform).
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| SplunkSplunk Enterprise | Affected
| Fixed in
|
| SplunkSplunk Cloud Platform | Affected
| Fixed in
|
AI-suggested
To mitigate CVE-2026-20144, organizations should promptly upgrade affected Splunk Enterprise and Splunk Cloud Platform deployments to the fixed versions: 10.2.0 or later for Enterprise and 10.2.2510.0 or later for Cloud Platform, or the respective minimum fixed versions listed. Until upgrades are applied, restrict access to the Splunk _internal index strictly to trusted administrators with a demonstrated need, employing the principle of least privilege. Review and audit roles and permissions regularly to ensure no excessive access is granted. Implement monitoring and alerting for unusual access patterns to the _internal index or conf.log files. Consider encrypting log files at rest and in transit to reduce the risk of unauthorized access. Disable or limit verbose logging of sensitive configuration data where possible, and sanitize logs to avoid storing plaintext sensitive information. Conduct security awareness training for administrators about the risks of sensitive data exposure through logs. Finally, maintain an incident response plan that includes steps for potential compromise scenarios involving authentication mechanisms.
Description
In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.8, and 9.2.11, and Splunk Cloud Platform versions below 10.2.2510.0, 10.1.2507.11, 10.0.2503.9, and 9.3.2411.120, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the the Splunk _internal index could view the Security Assertion Markup Language (SAML) configurations for Attribute query requests (AQRs) or Authentication extensions in plain text within the conf.log file, depending on which feature is configured.