Privileged-pod chain bypassed tenant isolation in anonymized cloud
Original title: An insecure neighbor: how a vulnerability chain led to an isolation bypass in cloud infrastructure
A regular tenant reached worker-node root on managed Kubernetes v1.25.16+k0s.0; the provider fixed every reported issue.
Kaspersky researchers describe a bug-bounty test of an anonymized major cloud in which a normal tenant escaped a managed Kubernetes worker, abused Konnectivity, and chained further logic flaws into a full tenant-isolation bypass. Privileged pods with host namespaces were allowed, giving root on the node via nsenter, and a Konnectivity token reached the control-plane tunnel on port 8132. The provider was notified and the researchers say every issue was fixed. The case took second place at Russian Pentest Award 2026 and was presented on October 22 at SAS 2026.
Unconfirmed: The provider is anonymized, so affected customers cannot be identified from the report.
- The tested cluster version was v1.25.16+k0s.0.
- kube-apiserver was at 192.168.0.4, with Konnectivity on port 8132.
- DIAL_REQ packets made the control plane call net.Dial() toward attacker-chosen targets.
- k0s disables user pods on control-plane nodes by default.
Impact: Tenant isolation bypass from a regular cloud tenant
| Product | Affected |
|---|---|
| managed Kubernetes (k0s) | v1.25.16+k0s.0 |
- ATT&CK
- T1611 Escape to Host
- Products
- Kubernetesk0sKonnectivity
- Organizations
- Kaspersky
From the original article
15 min read at securelist.com
A Kaspersky expert presents a cloud isolation bypass case honored at Russian Pentest Award 2026. Learn how vulnerabilities in Kubernetes, Konnectivity, and the overlay network lead to RCE and compromise of other tenants' services.
By Matvey Bukhtoyarov, Kaspersky Security Services · securelist.com
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.