A tester who rented an ordinary managed Kubernetes cluster at a major cloud provider ended up able to run code on the provider's control plane, read logs from every managed resource and take over other tenants' clusters, databases and message queues. Matvey Bukhtoyarov of Kaspersky Security Services has published the full chain, found during an official bug bounty engagement. The provider, which Kaspersky has anonymized, was notified and all of the issues were fixed.
The case matters because it cuts against a comfortable assumption: that cloud breaches are mostly the customer's fault, from misconfigured storage or open ports. Here every weak link sat on the provider's side. The research took second place in the System Hacking (Web and Logic) category at Russian Pentest Award 2026 and was presented at Kaspersky's Security Analyst Summit on October 22.
From a privileged pod to the control plane
The tester started with the access any paying customer has. The managed cluster, running k0s v1.25.16, did not stop tenants from creating privileged pods with access to host namespaces, so a single pod plus the nsenter command gave root on the worker node. On that node sat a token for Konnectivity, the component that tunnels traffic between a Kubernetes control plane and its worker nodes.
Reading the source of the Konnectivity server fork used by k0s, Bukhtoyarov found it accepted connection requests (DIAL_REQ packets) arriving from the worker side and opened them from the control plane, with the attacker choosing the protocol and address. That server-side request forgery reached local UNIX sockets, including D-Bus, which the tester used to start a systemd user service and get a callback from the control plane. Mirantis, the company behind k0s, confirmed the vulnerability. A known OverlayFS privilege escalation bug on the Ubuntu 22.04 host then gave full root.
A flat network shared by every customer
Root on the control plane exposed an interface on a 100.64.0.0/10 overlay network that turned out to be flat, with visibility into all managed services. From there the chain branched out:
- Monitoring: a VictoriaMetrics instance listed control plane hosts belonging to other tenants, and VictoriaLogs allowed unauthorized queries over all logs. Those logs held root SSH private keys that cloud-init scripts printed to stdout, giving full control of other tenants' clusters.
- Kafka: a JMX registry on managed Kafka hosts, whose RMI stub host should have been bound only to loopback, was reachable on the shared network and allowed loading a custom MBean for remote code execution.
- Redis: the redis exporter's scrape endpoint accepted any target and connected with its own Redis credentials, so pointing it at an attacker's listener captured passwords that opened other customers' Redis instances.
- PostgreSQL: etcd running beside managed Patroni clusters had no access restrictions, and write access to the stored Patroni configuration allows setting archive_command to a command of the attacker's choice.
The tester also recovered a salt-minion key pair from the control plane host, which Kaspersky says significantly expanded the attack surface by reaching the cloud's own management layer through SaltStack.
Isolate tenants, not just workloads
Kaspersky's findings point to concrete fixes for anyone running managed Kubernetes: block privileged pods and host namespaces for tenants, treat worker-side Konnectivity traffic as untrusted, bind admin interfaces such as JMX to loopback, require authentication on etcd and monitoring APIs, and keep secrets out of boot logs. Above all, a shared overlay network should not let one tenant's compromised node see everyone else's services. Related cross-tenant risks have surfaced before in Kubernetes storage drivers and over-privileged Kubernetes operators.
None of these weaknesses would have been catastrophic alone. Chained across a network that trusted every neighbor, they turned one rented cluster into a key ring for the whole cloud.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.