Cloud Tenant Isolation Failure: How Linked Infrastructure Flaws Exposed Managed Services

The central lesson from this cloud security case is that tenant isolation depends on more than the settings customers can see. A chain of weaknesses inside a provider’s own systems turned access to one managed Kubernetes worker into visibility across a shared network, then exposed data and control paths tied to other customers’ services.

The researchers describe a real-world penetration test of an anonymized cloud provider. The work was submitted through a bug bounty program, and the provider fixed the reported issues. The case received second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. The researcher also presented the work at Security Analyst Summit 2026.

The findings span Kubernetes, Konnectivity, Linux privilege boundaries, monitoring systems, log storage, Kafka, Redis, PostgreSQL, SaltStack, Valkey and MySQL. No single flaw explains the full exposure. The risk came from how the services were connected, what credentials they shared, and how much authority leaked from one component to the next.

Where the chain began

The test began from the position of an external attacker with the privileges of an ordinary cloud tenant. The first target was a managed Kubernetes cluster running v1.25.16+k0s.0. Tenants generally don’t receive direct SSH access to worker nodes in a managed service. Here, however, the cluster allowed a tenant to create a privileged pod with access to host namespaces.

That configuration erased an important boundary. A privileged container could use the host’s process namespace and other host resources, then switch its execution context to the worker node. The researchers reached root on that machine. This initial foothold mattered because the worker had access to infrastructure components and network paths hidden from an ordinary workload.

Examining the worker’s filesystem revealed a Konnectivity service token. Konnectivity provides a tunnel between a Kubernetes control plane and its worker nodes, allowing management traffic to reach nodes that may sit behind network address translation. The token gave the researchers a way to interact with the tunnel service from the worker side.

The team also found the Kubernetes API server address in the node’s kubelet configuration. A scan showed several exposed services, including the API server, an etcd-related port, monitoring endpoints and Konnectivity on port 8132. The key discovery was that the tunnel service accepted traffic from the worker and could initiate connections from the control plane.

Kubelet configuration and API server address

Konnectivity service account token

A tunnel became a control-plane entry point

The researchers built a local environment to inspect the provider’s Konnectivity implementation. The cluster used a fork of apiserver-network-proxy, included with k0s. In this setup, Konnectivity’s AgentService accepted a stream of packets from a worker agent. A packet marked as a dial request supplied a protocol and destination address.

The server treated those requests as valid and called the network dial function from the control-plane side. Since the requesting worker could influence the destination and protocol, the behavior created a server-side request forgery path: the tunnel could be used to make connections from the control plane to other destinations it could reach.

The researchers found that this path extended beyond network services to a local Unix socket: the system D-Bus socket. D-Bus exposed services for system management, login sessions and package handling. The Konnectivity process did not run as root, but its access was still enough to interact with the login manager and enable a user-level systemd session for its own user ID. A transient user service then provided remote command execution in the control-plane process context.

That distinction matters. The tunnel flaw did not immediately grant root on the control plane. It did, however, turn a service intended to connect worker nodes into a route to local control-plane interfaces. The researchers then used a separate Linux privilege escalation flaw to raise their access. The affected host ran Ubuntu 22.04 with a 5.15-series kernel, and user namespaces were enabled. A known OverlayFS issue allowed a file capability to survive namespace manipulation, making it possible to elevate a copied Python interpreter to root.

With root access, the team found a network interface on the 100.64.0.0/10 range and a Salt minion key pair on the host. The first finding exposed a flat overlay network connecting managed services. The second offered a possible route into the provider’s SaltStack management system. These discoveries changed the scope of the assessment: the worker was no longer just a single cluster node, but a vantage point from which shared cloud services could be inspected.

The k0s project’s maintainer, Mirantis, confirmed the Konnectivity vulnerability.

Interaction between the control plane and data plane through Konnectivity

Konnectivity server context and node network interfaces

Shared monitoring and logs widened exposure

The overlay network connected services belonging to many managed resources. Traffic analysis led the researchers to a VictoriaMetrics instance collecting metrics from Kubernetes clusters. Its API exposed target information, including addresses, cluster identifiers, customer labels and service profiles. The researchers say a single query could return a list of control-plane hosts associated with other tenants.

That data had operational value beyond monitoring. Labels and target addresses helped identify what each host ran and correlate a node with its cloud resources. The article reports that the same network also exposed VictoriaLogs, whose query endpoint allowed unauthenticated access to logs from managed resources.

Those logs contained a more serious leak. The cloud-init scripts used on Kubernetes control-plane hosts generated private SSH keys for the root account, printed them to standard output and thereby placed them in shared system logs. By matching log entries with host information from metrics, researchers could associate a private key with a target node. The key then allowed privileged SSH access to other tenants’ clusters.

This is a useful example of how observability systems can become part of the production attack surface. Metrics can reveal service placement and topology; logs can capture secrets that were never intended to persist. When the collection systems are reachable across tenant boundaries, their metadata and retained output can undermine the isolation those systems are supposed to help monitor.

Private SSH key found in a VictoriaLogs record

Host process privileges and available Kubernetes actions

Managed data services shared more than a network

The researchers next examined managed Apache Kafka instances on the same overlay. One host exposed a Java Management Extensions registry on port 9999. The registry’s remote method invocation configuration returned a stub that advertised a service address reachable from the shared network. The service was exposed beyond the loopback interface, contrary to the expected restriction described in the report.

That exposure enabled the researchers to load a custom management component into the Kafka Java process and invoke it remotely. The result was command execution on the Kafka host. The practical issue was not a flaw unique to Kafka itself: an administrative Java interface had been reachable across a network shared with other customers’ services.

Java RMI service found on port 9999

Kafka process context and node network interfaces

Redis hosts presented a different weakness. Each had a Redis exporter alongside the database service. The exporter’s scrape endpoint accepted a caller-supplied target and attempted to collect metrics using the credentials it used for its configured Redis instance. By directing the exporter toward a server controlled by the researchers, they could capture the authentication exchange.

The leaked credentials enabled access to other customers’ Redis instances, including the ability to read, change or delete stored data. The researchers also noted that a Redis code execution flaw disclosed during the work could be combined with this access to take control of other services. The account of the case includes a diagnostic image from a Valkey instance alongside the Redis findings.

Redis authentication exchange observed in a request

Diagnostic information from a Valkey instance

PostgreSQL configuration exposed a route to host execution

The PostgreSQL review found database hosts with etcd and Patroni services also reachable on the overlay. Patroni’s REST API required authentication, but etcd did not. A key in etcd held the Patroni configuration, including PostgreSQL archiving settings.

The researchers report that write access to this configuration could change the archiving command, which PostgreSQL runs as part of its write-ahead log archiving process. They also found a way to make the process run without waiting for normal database activity to fill a log segment. In combination, the open etcd service and writable cluster configuration created a path from network access to command execution on the database host.

That access could then be used to reach PostgreSQL instances belonging to other tenants and control their data. The hosts also contained files with credentials for object storage. Those credentials covered backups for the current database and, according to the researchers, backups for other databases in the cloud as well.

The exposure therefore crossed several data layers: cluster coordination settings, live database access and stored backup credentials. Backups often carry the same sensitive records as production systems, while credentials on a database host can extend the effects of a host compromise into storage accounts.

Patroni configuration stored in etcd

PostgreSQL process context and node network interfaces

Database and object-storage access parameters in a backup file

Backup storage locations in object storage

SaltStack turned a local foothold into a cloud-wide concern

Root access on the control-plane node exposed a Salt minion key pair, which led the researchers to examine the provider’s SaltStack setup. They collected files from the Salt master for static review. The Salt software itself was current enough that the team found no applicable known vulnerabilities, but a custom extension on the master contained an unsafe SQL construction pattern.

The extension assembled a database query with string formatting. A minion could request a pillar refresh and supply metadata known as grains. One metadata field flowed into the query without safe parameter handling, allowing SQL injection when the master processed the request. The resulting error behavior gave the researchers a way to inspect database contents.

The most useful schema held metadata for managed resources and virtual servers. Another table contained authentication tokens for Salt masters. Those tokens could be used with the Salt REST interface to run commands on minions across the cloud. The researchers say they stopped short of using that access further, by agreement with the provider.

Even without continuing, the chain had reached the provider’s central management layer. The team’s assessment was that the database access and Salt tokens could have enabled control over a broad range of services, including virtual servers and object storage. That is the clearest illustration in the report of why management credentials deserve a different level of protection from ordinary service credentials: their reach can span many tenants and product types.

Files found on the Salt master

Database error during pillar processing

Tables in the cloud resource metadata schema

Salt master authentication tokens in database records

Other paths through Valkey and MySQL

The report describes two further routes into managed hosts. The Valkey instances used version 7.2.11, with build details matching an Ubuntu Noble x86_64 package. The researchers associated that version with CVE-2026-25243, a flaw in how the RESTORE command handled serialized hash data. A mismatch between validation and parsing could cause a heap overwrite and potentially allow controlled memory modification.

The researchers say they reproduced the issue and worked around service sandbox restrictions. The Valkey service had controls that blocked standard shell execution and restricted filesystem access, but its temporary directory remained writable and executable behavior could be redirected through it. The team established a separate access path and then looked for ways to raise privileges on the host.

This example shows why process sandboxing needs to be assessed against the whole service environment. A restriction that blocks one route to command execution may still leave another path through writable directories, service configuration or a second local weakness. The case also illustrates the limits of judging exposure from a version string alone: the researchers used the reported build identifier to establish which binary was running.

Valkey process context and Salt metadata

The MySQL path began with a database user that lacked administrator privileges. The provider’s application logic nevertheless allowed it to replace system privilege tables. After a database restart, a newly created account received broad administrative rights. The researchers then used a configuration update path that accepted line breaks to alter MySQL settings, including file and plug-in locations.

With those settings changed, they could write and load a custom database extension to execute commands on the host. A second weakness completed the escalation: a background service ran the MySQL client with elevated privileges and loaded configuration from a file the researchers could influence. When the service restarted, the injected plug-in ran in that higher-privilege context.

The MySQL case is a reminder that database isolation is not just about SQL permissions. Administrative APIs, configuration validation, plug-in loading and background service behavior all affect the boundary between a database account and its host. A user that appears constrained in the database can still become a host-level risk if surrounding control paths permit configuration changes or privileged clients load attacker-influenced components.

Command execution through a MySQL extension

What the case says about cloud isolation

The provider’s problems were not limited to customer misconfiguration. The chain crossed weaknesses in cluster admission controls, a tunnel service, host privilege boundaries, flat network design, unauthenticated monitoring APIs, secret handling, database configuration and custom management code. Each defect expanded what the next one could reach.

That makes tenant isolation an end-to-end property. A Kubernetes policy can prevent risky pods, but that protection has to hold on every cluster. A tunnel service needs to validate which side may request connections and which destinations it can reach. Monitoring and logging systems need access controls that match the sensitivity of their data. Service networks need boundaries that prevent one customer’s managed resource from probing another’s administrative interfaces.

Credential handling is another recurring weakness. The report found private SSH keys in logs, Redis credentials that could be redirected to an attacker-controlled destination, object-storage credentials on database hosts and Salt master tokens in a database accessible through an injection flaw. Rotating exposed secrets is only one part of the response; providers also need to reduce where credentials are stored, how long they persist and which services can retrieve them.

The researchers say the provider received recommendations to isolate managed services so they couldn’t see one another across the network, apply strict AppArmor restrictions to service processes, and monitor how potentially vulnerable services are used. Those measures map directly to the failures described: network segmentation limits lateral visibility, process restrictions reduce the value of a foothold, and service monitoring can reveal unexpected access patterns.

The provider fixed the reported issues, according to the researchers. The remaining question for cloud buyers and operators is how those fixes were validated across the full service fleet. In a managed platform, a patch to one component doesn’t establish that the tenant boundary is sound. The stronger signal is whether providers can show that identity, network access, credentials and observability data remain isolated when one service is compromised.