Summary
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.
How to avoid it in your code
- Patch runc to 1.1.12 or later and update Docker/BuildKit to versions bundling the fix.
- Only build from and run trusted base images; treat untrusted images and Dockerfiles as hostile.
- Run containers unprivileged with dropped capabilities and a read-only root filesystem.
- Apply seccomp, AppArmor, or SELinux profiles and use user namespaces to harden isolation.
- Scan images for known-vulnerable runtimes and monitor for unexpected host-filesystem access.
References
Related vulnerabilities
All Infra →- HIGHCLOUD-CLOUDSQL-PRIVESC-2023
On 24 May 2023 Dig Security disclosed a privilege-escalation chain in Google Cloud SQL for SQL Server, originally reported to Google in February 2023, that let an attacker escalate from a limited database role to full system administrator and reach the host operating system. The chain first abused a gap in GCP's security hardening to add the attacker's user to DbRootRole, an elevated GCP admin role that nonetheless lacked full SQL Server permissions, then exploited a further misconfiguration in the role permission architecture to grant the SQL Server sysadmin role and obtain complete control of the database engine. With sysadmin rights the researchers reached the underlying container and host OS, letting them list privileged paths, read sensitive files and extract secrets, including internal GCP data and credentials related to the managed service. This was a provider-side flaw under shared responsibility that customers could not patch; Google remediated it in April 2023 and it was found and reported by researchers with no evidence of exploitation in the wild.
- 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.
- CRITICALCLOUD-CHAOSDB-2021
ChaosDB, disclosed in 2021, was the kind of cloud vulnerability that is supposed to be impossible: a flaw in Microsoft Azure's Cosmos DB database service that let any customer steal the access keys to thousands of other customers' databases. Cloud platforms promise that tenants are isolated from each other; ChaosDB broke that wall. Researchers found that a built-in notebook feature, enabled by default, could be escalated to grab Microsoft's own internal certificates, which in turn unlocked the keys to every Cosmos DB account on the platform. It is a stark reminder that even in the cloud, the isolation between tenants is itself a piece of software that can have bugs, and one you cannot patch yourself.
- HIGHCVE-2021-34527
A remote code execution flaw in the Windows Print Spooler service allows an authenticated domain user to load a malicious printer driver DLL and execute code as SYSTEM, both locally and remotely. A working proof-of-concept was accidentally published before a patch existed, so Microsoft assigned a new identifier and shipped out-of-band fixes. Because nearly every Windows host, including domain controllers, runs the spooler, it gave attackers a near-universal lateral-movement and privilege-escalation primitive. It was exploited in ransomware intrusions by Vice Society, Conti, and Magniber.
- CRITICALINFRA-CAPITALONE-2019
In 2019, a former Amazon engineer stole the personal data of about 100 million Americans from Capital One, and she did it through a chain of cloud-security mistakes that has since become a teaching classic. A misconfigured web application firewall could be tricked into making requests on the attacker's behalf, a flaw called server-side request forgery. She pointed it at a special internal address that every AWS server can reach, the one that hands out the server's temporary cloud credentials, grabbed those credentials, and because they were far more powerful than they needed to be, used them to download Capital One's data straight out of its storage. It is the textbook SSRF-to-cloud-takeover chain, and the reason AWS hardened that metadata service afterward.
- 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.