Loading vulnerability…
Sensitive Data Exposure via Logs in Splunk TcpChannel
CVE-2026-20239 is a high-severity information disclosure vulnerability in Splunk Enterprise and Splunk Cloud Platform caused by improper output sanitization in the splunkd TcpChannel logging path. When socket errors occur during TCP communication, the TcpChannel component can write full unparsed input/output buffer contents to WARN-level logs. Those log entries are stored in the _internal index without sanitization, allowing sensitive values present in the buffers, including session cookies and HTTP response bodies, to become searchable through Splunk’s standard search interface. Any authenticated user whose effective role permissions include search access to the _internal index can retrieve this data. Affected versions include Splunk Enterprise 10.2.0 through 10.2.1 and 10.0.0 through 10.0.4, as well as Splunk Cloud Platform builds below 10.3.2512.8, 10.2.2510.11, 10.1.2507.21, and 10.0.2503.13.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation exposes sensitive data written into internal logs, including active session cookies and cleartext HTTP response bodies. An attacker who recovers valid session cookies may impersonate other users, including potentially higher-privileged users, enabling session hijacking, unauthorized access to Splunk data and functions, and possible lateral movement within the Splunk environment or connected systems. The disclosed CVSS vector also indicates potential downstream integrity and availability consequences if stolen sessions are used to perform privileged actions.
If you can’t patch tonight, do this now.
Restrict search access to the _internal index to administrator accounts only and audit all role assignments and inherited permissions to ensure no low-privileged or unintended roles can search that index. Because Splunk grants the most permissive access among assigned roles, review composite role membership carefully. As an interim defensive measure, monitor for unusual searches against internal telemetry and WARN-level TcpChannel log activity until patched versions are deployed.
Patch, then assume compromise.
Upgrade Splunk Enterprise to a fixed release: 10.2.2 or later for the 10.2 branch, and 10.0.5 or later for the 10.0 branch. For Splunk Cloud Platform, ensure the deployment is on a fixed build: 10.3.2512.8 or later, 10.2.2510.11 or later, 10.1.2507.21 or later, or 10.0.2503.13 or later, depending on branch. Splunk Cloud instances should be verified against the patched build numbers, while Splunk Enterprise deployments require manual upgrade by customers.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.