CVE-2026-20253 is a missing authentication vulnerability in the PostgreSQL sidecar service endpoint in Splunk Enterprise versions 10.2.0 through 10.2.3 and 10.0.0 through 10.0.6. The endpoint accepts file creation and truncation operations from any network-reachable caller without checking credentials. An unauthenticated attacker who can reach the service can write files to the Splunk host, and under certain conditions can use that file write access to escalate to remote code execution on the Splunk application environment.
Splunk released patches on June 10, 2026, fixing the flaw in versions 10.4.0, 10.2.4, and 10.0.7. On June 12, WatchTowr published a detailed technical write-up and a modified proof-of-concept exploit. Splunk updated its advisory on June 18 to confirm limited active exploitation, stating that its PSIRT team had become aware of exploitation in June. CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalog the same day and set a June 21 remediation deadline for federal civilian agencies under BOD 26-04.
Shadowserver Foundation tracks more than 1,400 internet-exposed Splunk Enterprise instances, the majority in North America and Europe. Resecurity confirmed active exploitation and identified specific IOCs including path traversal sequences in requests, PostgreSQL-specific connection parameters in payloads, and unexpected outbound connections from Splunk services to external PostgreSQL servers.
- Upgrade Splunk Enterprise to 10.4.0, 10.2.4, or 10.0.7 immediately. Today is the CISA federal deadline under BOD 26-04.
- If patching cannot happen today, disable the PostgreSQL sidecar service as a temporary mitigation. Splunk confirmed this removes the vulnerable attack surface, though it may affect certain functionality.
- Review Splunk access logs for requests containing path traversal sequences, PostgreSQL connection parameters such as hostaddr, dbname, or port, and unexpected outbound connections from Splunk services to external servers.
- Restrict network access to Splunk management interfaces to trusted internal networks and management infrastructure rather than allowing internet-wide access.
On June 11, 2026, attackers gained access to Klue’s backend infrastructure using a long-dormant API credential that had been created to test a third-party integration prototype which was never ultimately deployed. The credential had remained active with valid access rights despite the integration project having been abandoned. Using this access, the attackers pushed a code update to Klue’s systems that was capable of collecting OAuth tokens that Klue’s customers use to connect their Salesforce environments to the Klue Battlecards application.
Klue detected anomalous activity on June 12 and took steps to remove the malicious code and revoke compromised credentials. The company issued a general customer alert on June 13, though Huntress noted the alert did not specify which customers were affected. Salesforce became aware of unusual activity and announced on June 17 that it had disabled the Klue Battlecards integration across all customer environments as a containment measure.
Huntress, a managed detection and response vendor, published its own incident timeline on June 18 confirming it was among the victims. Huntress staff received extortion emails on June 16, signed by a group calling itself Icarus, threatening to leak stolen data unless negotiations began within 48 hours. ReliaQuest researchers observed the attack pattern in Salesforce API logs, identifying automated Python scripts running bulk query loops for approximately 24 hours and describing the tactics as closely resembling the UNC6395 Salesloft Drift attacks from 2025.
- Revoke and rotate all OAuth tokens, refresh tokens, client secrets, and active OAuth grants associated with the Klue Battlecards integration in your Salesforce environment.
- Audit Salesforce API logs for the period June 11 to 17 for unusual query volume from Klue service accounts, Python-urllib user agent strings, and bulk query patterns using the QueryMore cursor.
- Review and scope all other third-party Salesforce integrations to confirm each holds only the minimum permissions necessary for its function.
- Conduct a broader audit of API credentials and OAuth grants across SaaS integrations for inactive or prototype credentials that retain active access.
AutoGen Studio is Microsoft Research’s open-source user interface for prototyping multi-agent AI systems. Its MCP WebSocket server, running on localhost port 8081, allows the AI agent to invoke tools and execute processes on the host. Microsoft’s Defender Security Research Team identified three weaknesses that chain together.
First, the WebSocket server restricted incoming connections to localhost addresses, blocking connections from ordinary browser tabs. It did not, however, distinguish between a human browser and a headless browser controlled by an AutoGen browsing agent, which inherits localhost identity. Second, AutoGen Studio’s authentication middleware explicitly skipped all paths under the MCP API route, assuming the WebSocket handler would enforce its own checks, which it never did. Third, the WebSocket endpoint accepted a server-params query parameter, decoded it from base64 into a JSON structure, and parsed it into a parameters object that could specify an OS command to execute.
The resulting attack is straightforward: an attacker publishes a web page containing JavaScript that opens a WebSocket connection to the local MCP server and sends a base64-encoded payload specifying an arbitrary OS command. When an AutoGen Studio browsing agent is directed to that page, the agent renders the JavaScript, which executes in a localhost context, successfully connects to the MCP server, and spawns the attacker-specified process on the host under the developer’s own account. Microsoft reported the chain to MSRC, and the AutoGen maintainers hardened the upstream main branch in commit b047730 before the code shipped in any release. Users installing AutoGen Studio via pip install are not affected.
- No end-user patching required. The vulnerable code never shipped in a PyPI release. Users installing via pip are not exposed.
- For organisations building custom AI agent frameworks or deploying development-branch AutoGen Studio: confirm local MCP or tool execution services require authentication and do not trust localhost origin alone as a security control.
- Review any AI agent deployment where the agent can browse arbitrary web pages and also has access to local services or tools that can execute code. Audit what those local services accept and whether they validate the identity and authorisation of the caller.