Loading story…
Splunk documented and later retired detections for protocol impersonation and weak-encryption scenarios tied to improper certificate handling in its platform and Python3 client libraries. The detections targeted use of insecure default self-signed certificates and SSL validation cases where certificate checks were enabled without hostname verification, conditions associated with CVE-2022-32152 that could allow man-in-the-middle interception, data alteration, and unauthorized access.
The retired analytics searched splunkd logs for X.509 certificate warnings and highlighted hosts, certificate common names, components, and log levels linked to unsafe TLS use. Splunk said the issue has been patched in current releases, recommended upgrading to Splunk 9, and advised replacing default self-signed certificates and enabling full TLS hostname validation; the risk aligns with the broader ATT&CK concept of adversaries abusing or obtaining digital certificates under T1588.004 to support impersonation and trusted communications.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Splunk removed the hunting detections "Splunk protocol impersonation weak encryption selfsigned" and "Splunk protocol impersonation weak encryption simplerequest" from its Threat Research content library, stating the associated CVEs had been patched in current releases and noting the removals in content library version 5.6.0.
Splunk disclosed SVD-2022-0601, stating that Python httplib and urllib libraries shipped with Splunk Enterprise before 9.0 and Splunk Cloud Platform before 8.2.2203 did not validate server certificates against CA stores by default. Splunk directed Enterprise customers to upgrade to 9.0 or later and enable TLS host name validation, while it patched and monitored affected Splunk Cloud instances and said it had no evidence of external exploitation at publication.
MITRE ATT&CK published the Enterprise sub-technique T1588.004, Obtain Capabilities: Digital Certificates, which is later referenced by Splunk detections related to certificate misuse and protocol impersonation risks.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
5 references tracked. Mallory keeps watching after this page renders.
research.splunk.com
Open sourceresearch.splunk.com
Open sourcedocs.splunk.com
Open sourcesplunk.com
Open sourceattack.mitre.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Splunk removed two security analytics tied to `CVE-2022-32151` after stating the underlying issues were patched in current releases. The retired detections had been designed to flag Splunk forwarder connections where `ssl=false` and to identify weak TLS certificate-validation settings in Python `httplib` and `urllib` components across search heads and peers. Splunk warned that these conditions could expose sensitive data, allow interception or manipulation of traffic, and in some cases enable attackers to download or publish forwarder bundles, creating a path to arbitrary code execution. The risks align with the broader ATT&CK technique **T1001.003: Protocol or Service Impersonation**, which covers malware and intrusion sets that disguise command-and-control traffic as legitimate services or protocols such as TLS and HTTP. MITRE documents how adversaries use fake TLS handshakes, spoofed record headers, and benign-looking HTTP headers, cookies, URI parameters, and POST bodies to evade inspection. In Splunk environments, weak or absent encryption can make that kind of impersonation harder to distinguish from normal traffic, which is why the detections had focused on missing encryption and certificate-validation weaknesses before being deprecated in version `5.6.0`.
Aug 12, 2026
Splunk has removed several security analytics from its Threat Research content library after the underlying vulnerabilities were patched in current releases, including detections tied to path traversal, SPL injection, CSRF, unauthorized admin account creation, and Analytics Workspace data exfiltration. The retired content covered **CVE-2022-26889**, **CVE-2022-43566**, **CVE-2023-22942**, and **CVE-2023-22933**, with detections aimed at spotting exploitation attempts in on-premises deployments through internal access logs, audit searches, and REST API queries. The withdrawn detections had been designed to identify attacks such as crafted `../` traversal requests, abuse of the Splunk Secure Gateway `kvstore_client` endpoint, suspicious `sid` query activity in Analytics Workspace, and the presence of nonstandard administrative accounts that could indicate persistence or privilege escalation. Splunk said some analytics were deprecated because they were patched and no longer maintained, while at least one lookup file editing path traversal detection was removed because it did not accurately detect malicious activity and was ineffective against obfuscated requests; several notices also warned of false positives, disabled-by-default status, and limited usefulness without manual investigation.
Aug 12, 2026
Splunk released security updates for **Splunk Enterprise**, **Splunk Cloud Platform**, and **Splunk Secure Gateway** to address eight vulnerabilities, including two high-severity issues. The most serious flaw, **`CVE-2025-20229`**, can allow authenticated remote code execution through unauthorized file upload and execution, while **`CVE-2025-20231`** can expose sensitive data because session data and authentication tokens may be logged in plaintext and protected with improper permissions. Splunk documentation for managing app and add-on objects is relevant because the attack surface includes application components and uploaded objects within Splunk environments. The update also fixes several medium-severity weaknesses, including **CSRF**, an **SPL security bypass with command execution**, unauthorized access to sensitive data, and unauthorized system changes. Splunk further remediated vulnerabilities in bundled third-party components including **idna**, **certifi**, **requests**, **urllib3**, **cryptography**, **axios**, and **Jinja2**. Organizations using affected versions have been urged to upgrade promptly, and exposure from **`CVE-2025-20231`** can also be reduced by disabling the **Splunk Secure Gateway App** until patches are applied.
Jul 24, 2026