Summary
On 25 August 2021 Wiz researchers Nir Ohfeld and Sagi Tzadik disclosed ChaosDB, a cross-tenant flaw in Azure Cosmos DB that let any customer retrieve the primary access keys, certificates and connection details of several thousand other customers' database accounts, enabling full cross-tenant read, write and delete. The chain abused the Cosmos DB built-in Jupyter Notebook feature, which had been enabled by default since February 2021. A notebook ran attacker C# code as root while Python ran unprivileged, giving container root, after which the attacker removed iptables rules to reach the WireServer (168.63.129.16) and Instance Metadata endpoints. Querying WireServer yielded roughly two dozen Microsoft certificates, including private keys for internal Cosmos DB and notebook services, which were used to authenticate to internal Service Fabric clusters, enumerate every customer's Cosmos DB instance and decrypt their stored COSMOSDB_ACCOUNT_KEY and notebook auth tokens. This was a provider-side flaw under shared responsibility that customers could not patch; it was found and reported by researchers with no evidence of exploitation in the wild.
How to avoid it in your code
- Regenerate Cosmos DB primary and secondary keys, especially after any provider advisory.
- Disable unused Cosmos DB features such as Jupyter Notebooks to shrink attack surface.
- Restrict access with private endpoints and IP firewall rules; avoid public exposure.
- Enable Microsoft Defender for Cloud and audit Cosmos DB access logs for anomalies.
- Isolate sensitive workloads into separate subscriptions to limit blast radius.
References
Related vulnerabilities
All Infra →- CRITICALCLOUD-BUCKET-MONOPOLY-2024
In research disclosed to AWS on February 16, 2024 and presented at Black Hat USA and DEF CON 32 in August 2024, Aqua Security's Nautilus team described a class of S3 bucket-name takeover attacks they called Bucket Monopoly, affecting CloudFormation, Glue, EMR, SageMaker, Service Catalog, and CodeStar. These services auto-created S3 buckets with predictable names built from static prefixes plus the account ID and region, such as cf-templates-{hash}-{region}, aws-glue-assets-{account-id}-{region}, and sagemaker-{region}-{account-id}, where account IDs are discoverable from ARNs, access keys, and public repos. Because S3 bucket names are globally unique, an attacker could pre-create a victim's predictably named bucket in a region the victim had not yet used (a Shadow Resource), then the victim's service would later read attacker-controlled content from it. This enabled data tampering, information disclosure, remote code execution by injecting malicious Glue or CloudFormation content, and in some cases full account takeover via planted admin roles; AWS remediated by adding randomized suffixes to bucket names and enforcing aws:ResourceAccount conditions. The class also covers reuse of abandoned or dangling bucket names that a victim configuration still references.
- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- HIGHCONTAINER-LEAKY-VESSELS-2024
Leaky Vessels was a set of container-escape vulnerabilities disclosed on 31 January 2024 by Rory McNamara of Snyk Security Labs, the headline flaw being CVE-2024-21626 (CVSS 8.6, runc 1.1.11 and earlier). It was an order-of-operations file-descriptor leak in runc's handling of the process working directory (WORKDIR / process.cwd). During container setup runc left an internal file descriptor referencing the host filesystem namespace open before all privileged descriptors were closed, so a malicious image or a build using a malicious Dockerfile or upstream FROM could set the working directory to that leaked descriptor via a path like /proc/self/fd/7. Because chdir occurred before the descriptor was closed, the container process gained a working directory in the host filesystem and could read and write host files, breaking container isolation and escaping to the underlying host. Related Docker BuildKit issues were disclosed alongside it: CVE-2024-23651 (mount cache race), CVE-2024-23652 (build-time arbitrary delete), and CVE-2024-23653 (GRPC SecurityMode privilege check bypass). The flaw was fixed in runc 1.1.12.
- CRITICALCLOUD-AZURESCAPE-2021
On 9 September 2021 Palo Alto Unit 42 researcher Yuval Avrahami disclosed Azurescape, described as the first cross-account container takeover in a public cloud, in which a malicious container on Azure Container Instances could escape and gain control over other customers' containers running on the shared multitenant Kubernetes cluster. ACI ran an outdated container runtime, runC v1.0.0-rc2, which was vulnerable to CVE-2019-5736, letting the attacker break out of the container and execute code as root on the underlying Kubernetes node. From the node the researcher found the bridge pod, which serviced az container exec calls, sent a Kubernetes service-account token in the Authorization header to a Kubelet that also allowed anonymous access; decoding that token (related to CVE-2018-1002102) granted pods/exec rights across all namespaces and control of the api-server, and thus the whole multitenant cluster. This was a provider-side flaw under shared responsibility that customers could not patch; Unit 42 found it and reported it with no knowledge of exploitation in the wild.
- CRITICALK8S-EXPOSED-ETCD
Exposed etcd is a misconfiguration class in which the etcd key-value store backing the Kubernetes API server is reachable on its client port (TCP 2379, with 2380 used for peer traffic) without client-certificate authentication. etcd is the single source of truth for a cluster and stores the entire cluster state, including all Secrets, service-account tokens, credentials, ConfigMaps, and RBAC rules, so reading it bypasses Kubernetes RBAC entirely and writing to it lets an attacker alter cluster state and take over the cluster. etcd shipped insecure by default: it had no authentication before version 2.1 (July 2015) and client-certificate authentication remained off by default for backward compatibility, and its authorization model is effectively all-or-nothing once access is granted. In March 2018, researcher Giovanni Collazo demonstrated the scale by querying Shodan and finding 2,284 etcd servers exposed to the internet without authentication; a short script then harvested roughly 750 MB of data including thousands of passwords, hundreds of AWS access keys, and private keys. The root cause is an etcd endpoint listening on a network-reachable interface without TLS client-certificate authentication enforced.
- CRITICALK8S-INGRESSNIGHTMARE-2025
IngressNightmare was a chain of five vulnerabilities in the Ingress-NGINX Controller for Kubernetes disclosed on 24 March 2025 by the Wiz Research team, the most severe being CVE-2025-1974 (CVSS 9.8), which enabled unauthenticated remote code execution from the pod network. Wiz estimated about 43% of cloud environments were vulnerable and identified over 6,500 publicly exposed clusters, including Fortune 500 organizations. The controller's validating admission webhook ran as an unauthenticated HTTP endpoint reachable by any workload on the pod network, accepting attacker-supplied AdmissionReview requests containing crafted Ingress objects. The supporting CVEs (CVE-2025-24514 auth-url, CVE-2025-1097 auth-tls-match-cn, CVE-2025-1098 mirror UID, CVE-2025-24513 path bypass) injected unsanitized NGINX configuration directives via annotations into a temporary config the controller validated with nginx -t. The attacker uploaded a shared-library payload by abusing NGINX client-body buffering (an oversized Content-Length keeps the request file descriptor open in ProcFS) and then used the injected ssl_engine directive to load that library during validation, achieving code execution in the controller pod whose service account could read all cluster secrets across namespaces, enabling full cluster takeover.