Cloudflare fixed a flaw in Cloudflare Containers that let a paying customer read data other customers' containers left behind on the same shared server. Cloudflare Sandboxes, sold for running untrusted code including AI-agent code, was affected too. Each container gets a disk built with Linux thin provisioning in 64-kilobyte blocks; when a container was deleted, its blocks returned to a shared pool set to skip wiping before reuse. A new container writing only a little into a reused block left the rest holding the previous customer's data, though the attacker could not choose whose. Accomplish reported it on September 4, and Cloudflare says no customer action is needed.
Researchers at Truffle Security reported that after four years of collecting leaked Amazon Web Services keys, they found 768 that still grant full control over a company's cloud account, with a median age of about five years. The keys were exposed in places like public code and configuration and were never rotated, so they remain live long after the people who created them have likely forgotten them. A single valid key with broad permissions can let an attacker read data, spin up resources, and move through a cloud environment. The finding is a reminder that leaked long-lived credentials remain one of the most durable and overlooked paths into cloud accounts.
Wiz Research disclosed CosmosEscape, a critical flaw chain in Microsoft's Azure Cosmos DB that could have given an attacker read and write access to every customer database on the service, including Microsoft's own. Starting from a crafted query against an attacker-controlled Gremlin database, the researchers escaped the query sandbox using .NET reflection, ran code on a shared gateway, and retrieved a platform-wide signing secret they call the Cosmos Master Key. That key let them fetch the access key for any Cosmos DB account on demand, reaching even private, network-isolated databases. Microsoft assigned CVE-2026-66803, fixed the issue across all regions, and found no evidence of abuse. Nothing needs patching by customers.
Researchers showed that confused deputy weaknesses persist in Google Cloud and Microsoft Azure, where a trusted service can be tricked into acting on an attacker's behalf against resources it should not reach. The pattern shows up when one service holds broad permissions and accepts instructions or identifiers from a less-trusted source without verifying who is really asking, which can enable cross-tenant access or privilege escalation. It is the same class of issue behind recent findings in enterprise agent and integration tooling, where a component with a user's permissions follows attacker-supplied input. The takeaway is architectural: identity and authorization must be checked at every trust boundary, not assumed from the calling service.
TrustStrike Labs