Key takeaways
- An authorized penetration testing engagement proved that chaining Kubernetes configuration oversights, proxy tunnel flaws, and flat overlay networking can completely compromise multi-tenant cloud isolation.
- Missing admission controllers on managed Kubernetes worker nodes permitted unprivileged tenant workloads to schedule privileged pods and escape to host-level execution via nsenter.
- An architectural flaw in the k0s Konnectivity fork processed agent-supplied DIAL_REQ packets without authorization checks, creating a control plane SSRF primitive that enabled D-Bus and systemd manipulation.
- A flat Carrier-Grade NAT overlay network (100.64.0.0/10) exposed internal observability tools, where VictoriaLogs stored plaintext root SSH private keys emitted during cloud-init provisioning.
- Lateral movement across unsegmented internal networks facilitated Remote Code Execution on managed Kafka clusters, credential harvesting via redis-exporter, and database takeover through unauthenticated Patroni etcd stores.
A multi-stage exploit chain demonstrated that subtle misconfigurations and logic errors within a cloud provider’s managed Kubernetes architecture can completely dismantle multi-tenant cloud isolation. Conducted during an authorized penetration testing engagement on a major cloud platform, the research showed how an external tenant with standard access could escape an unhardened Kubernetes worker node, abuse an architectural flaw in the Konnectivity control plane tunnel, and pivot across an unsegmented internal overlay network. By compounding vulnerabilities across observability collectors, data stores, and central configuration infrastructure, an adversary could achieve total administrative takeover of neighboring tenant workloads and foundational cloud control systems.
The findings, documented in Kaspersky Security Services research published on Securelist and presented by security researcher Matvey Bukhtoyarov at the Security Analyst Summit (SAS 2026), earned second place at the Russian Pentest Award 2026. While enterprise security teams frequently assume cloud breaches stem primarily from customer misconfigurations, this assessment confirmed that critical boundary failures can originate directly within provider infrastructure. Following responsible disclosure, the cloud provider remediated all identified vulnerabilities.
Initial Foothold: Worker Node Escape and Konnectivity SSRF
The engagement followed the threat model of an external attacker provisioned with standard tenant privileges. The initial vector targeted the provider’s managed Kubernetes service, which deployed worker nodes running k0s version 1.25.16 (a minimalist Kubernetes distribution maintained by Mirantis). Although cloud providers routinely restrict tenant Secure Shell (SSH) access to underlying worker nodes, the cluster lacked admission controller policies restricting container privilege levels.
Because Pod Security Standards and admission webhooks were absent, the researchers deployed an unconstrained pod specifying hostPID: true and privileged execution. Running the standard utility nsenter targeting process ID 1 broke container isolation, yielding root-level access on the underlying worker node operating system.
Inspecting the host filesystem revealed the service account token for Konnectivity (the Kubernetes apiserver-network-proxy component), which tunnels traffic between the control plane and data plane. Extracting the cluster API server address (192.168.0.4) from the kubelet configuration and scanning open ports identified standard endpoints alongside port 8132, hosting the Konnectivity AgentService.
In standard operations, Konnectivity creates a reverse tunnel so control plane components can communicate with worker nodes behind network address translation (NAT). However, source code analysis of the k0s Konnectivity fork revealed an architectural vulnerability in its gRPC Connect method. When the server received a DIAL_REQ packet from a connected worker node, the internal packet handler passed the requested protocol and target address directly to the Go standard library function net.Dial() on the control plane host:
func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) {
dialReq := pkt.GetDialRequest()
conn, err := net.Dial(dialReq.Protocol, dialReq.Address)
}Because the proxy server accepted agent-initiated dial requests without verifying authorization, the mechanism functioned as an arbitrary Server-Side Request Forgery (SSRF) primitive executed within the control plane context. This allowed reaching internal network services and local UNIX domain sockets on the master node.
Routing traffic to the local system bus socket (/run/dbus/system_bus_socket) enabled interaction with the D-Bus interface. Invoking SetUserLinger on org.freedesktop.login1.Manager enabled persistent session lingering for the unprivileged service user (UID 997), granting access to the user-level systemd control socket. Calling StartTransientUnit within org.freedesktop.systemd1.Manager subsequently launched an ephemeral background service running a reverse shell payload, achieving arbitrary code execution on the control plane.
The control plane host ran Ubuntu 22.04 with Linux kernel 5.15.x. Because user namespaces were enabled, an unpatched OverlayFS flaw allowed manipulated file capabilities (cap_setuid+eip) to persist across namespace boundaries. Preparing a setuid copy of the Python 3 interpreter escalated privileges from UID 997 to root on the master node.
Overlay Traversal: How Flat Networks Expose Tenant Telemetry
Root privileges on the control plane host exposed an internal network interface, eth2, configured within the 100.64.0.0/10 subnet (the Carrier-Grade NAT address space defined by RFC 6598). Architectural inspection revealed that the cloud provider operated a flat, unsegmented overlay network connecting all managed services across different tenants.
Analyzing outbound metric collection traffic identified queries directed to an internal VictoriaMetrics instance on port 8429. Querying the public API endpoint at /api/v1/targets returned Prometheus-compatible metadata labels for every scraped workload across the cloud. The labels exposed internal IP addresses, cluster identifiers, virtual dedicated server (VDS) IDs, and specific customer account numbers.
Adjacent to the metrics platform, an unauthenticated VictoriaLogs service was accessible on port 9428. The /select/logsql/query endpoint permitted arbitrary log filtering across aggregated cloud log streams. Examining cluster deployment logs revealed that the provider’s default cloud-init orchestration scripts generated root SSH private keys for managed nodes and printed them to standard output during provisioning. Because initialization stdout was automatically ingested into shared observability storage, attackers could query VictoriaLogs for active private keys, correlate target cluster metadata via VictoriaMetrics labels, and establish direct root SSH access to other tenants’ Kubernetes control planes.
Managed Service Exploitation: Attacking Kafka, Redis, and PostgreSQL
Because the flat 100.64.0.0/10 overlay network permitted unrestricted routing between tenant boundaries, the researchers analyzed the security posture of other managed database and messaging services.
As highlighted in recent threat reporting on multi-stage cloud breaches, isolation boundaries rarely fail from a single catastrophic flaw; attackers chain mundane service oversights across security domains:
| Managed Service | Exposed Interface | Vulnerability Mechanism | Blast Radius |
|---|---|---|---|
| Apache Kafka | TCP 9999 (JMX Registry) | Unauthenticated RMI Registry enabling dynamic javax.management.loading.MLet MBean loading |
Remote Code Execution inside Kafka JVM across tenant clusters |
| Redis / Valkey | TCP 9121 (redis-exporter) |
Input validation logic flaw in /scrape?target= forwarding cached production credentials |
Plaintext credential interception; unauthorized read/write access to tenant databases |
| PostgreSQL (Patroni) | TCP 2379 (etcd Distributed Store) | Unrestricted etcd write access allowing manipulation of cluster configuration parameters | Arbitrary shell execution via PostgreSQL archive_command and full database compromise |
| SaltStack Infrastructure | TCP 8000 (Salt Master REST API) | SQL injection in custom pillar script (_pillar/somebase.py) via minion grains |
Extraction of global master authentication tokens and cloud-wide orchestration takeover |
On managed Apache Kafka nodes, the Java Management Extensions (JMX) Registry was bound to the overlay network rather than 127.0.0.1. Interacting with the Remote Method Invocation (RMI) endpoint allowed creating an MLet component to dynamically load a compiled malicious MBean JAR from an external HTTP server, executing arbitrary commands under the Kafka service account.
On managed Redis instances, hosts exposed Prometheus redis-exporter on port 9121. The exporter implementation accepted an arbitrary target parameter and connected using authentication credentials configured for the local Redis instance. Pointing the query to an attacker-controlled listener caused the exporter to transmit an AUTH command containing the production Redis password in plaintext, granting full access to customer cache data.
Managed PostgreSQL clusters utilized Patroni for high availability, pairing PostgreSQL with an internal etcd cluster on port 2379. While Patroni’s REST API enforced authentication, access to etcd was completely unrestricted. The researchers modified /v2/keys/service/<cluster>/config to inject a malicious command into PostgreSQL’s archive_command parameter. Injecting a standby_cluster block triggered a primary demote-cluster routine and forced restart, causing PostgreSQL to execute the shell command during write-ahead log (WAL) archiving. Local backup configurations on PostgreSQL hosts also contained hardcoded S3 credentials exposing global backup repositories containing database snapshots for all cloud tenants.
Administrative Takeover: Exploiting SaltStack Infrastructure and Production Databases
The compromised control plane node hosted an active salt-minion agent containing valid cryptographic authentication keys for the central SaltStack management plane. Using the Salt client utility, the team dumped the Salt master filesystem by executing cp.list_master and recursively fetching files via cp.get_file.
While the underlying SaltStack software was fully patched against known CVEs, static analysis of custom provider extensions uncovered a critical vulnerability in _pillar/somebase.py. The module dynamically constructed SQL queries using Python string formatting (query.format(...)) incorporating minion-controlled grains. Because any Salt minion could trigger a pillar refresh while supplying arbitrary grain metadata, an attacker could inject SQL payloads inside the some_id grain attribute, executing queries directly against the provider’s production management database (prod-cloud).
Exploiting this error-based SQL injection exposed core schemas, including cloudsmth (indexing metadata for all virtual dedicated servers and customer resources) and salt-masters. The salt-masters table stored active API authentication tokens. Using these tokens, the researchers authenticated to the Salt master REST API on port 8000 and confirmed arbitrary command execution across every connected minion in the cloud infrastructure.
Secondary Vectors: Exploiting In-Memory Caches and Database Engines
Beyond the primary Kubernetes chain, the assessment uncovered parallel initial access vectors through standalone managed database engines.
Managed Valkey instances (running version 7.2.11, alongside Redis 7.2.4 on Ubuntu Noble) were vulnerable to CVE-2026-25243, a memory corruption flaw within the RESTORE command handler. When parsing legacy hash-zipmap structures, the validator accepts a 5-byte length representation for short keys, but the subsequent parser misinterprets internal bytes as value length encodings. This mismatch creates an out-of-bounds write that corrupts adjacent heap chunks, yielding an arbitrary write primitive.
Although Valkey operated under systemd sandbox restrictions (including ProtectSystem=strict and NoExecPaths=/), the /tmp directory retained write permissions. Altering process memory logic allowed staging and executing a payload from /tmp, planting an authorized SSH key to escalate privileges via local kernel exploits.
Similarly, managed MySQL deployments permitted initial privilege escalation through database logic errors. A default database user could drop and recreate administrative tables (mysql.user and mysql.global_grants). After restarting the database and establishing an administrative user, researchers exploited a Carriage Return/Line Feed (CRLF) injection flaw in the cloud management API to clear secure_file_priv and redirect plugin_dir. Staging a custom User Defined Function (UDF) shared library (sys_eval) enabled command execution under the MySQL daemon account. Full host compromise occurred by poisoning the client configuration file (/etc/mysql/my.cnf) with an authentication plugin that executed when an administrative maintenance service (mysql-watcher.service) connected as root.
Bottom line
The research demonstrates that multi-tenant cloud security cannot rely on container boundaries or virtual machine isolation alone when internal management networks remain flat and unauthenticated. A defensible cloud architecture requires defense-in-depth across multiple operational layers:
- Enforce Kubernetes Admission Controls: Managed Kubernetes platforms must strictly apply Pod Security Standards to disallow privileged containers, host namespace sharing (
hostPID,hostNetwork), and root mounts for tenant workloads. - Harden Internal Tunnels: Control plane proxies such as Konnectivity must reject agent-initiated dialing requests directed at internal host ports, loopback interfaces, or local UNIX domain sockets.
- Implement Strict Overlay Microsegmentation: The underlying overlay network (such as RFC 6598 carrier-grade NAT blocks) must enforce tenant-level microsegmentation to eliminate lateral network visibility between different customers and centralized provider telemetry.
- Enforce Authentication on Internal Telemetry and Storage: Observability endpoints (VictoriaMetrics, VictoriaLogs, Prometheus) and coordination datastores (etcd) must mandate mutual TLS and strict role-based access controls rather than relying on network perimeter assumptions.
- Scrub Provisioning Telemetry: Cloud orchestration mechanisms like
cloud-initmust never write sensitive credentials, such as root SSH private keys, to standard output or unencrypted logs. - Sanitize Management Infrastructure Inputs: Central orchestration platforms like SaltStack must treat all metadata received from managed nodes—including minion grains—as untrusted input and enforce parameterized database queries to prevent injection attacks.
