EN PT-BR
← Voltar ao feed
high cloud_services

Pentest of a major cloud provider chains k0s Konnectivity RCE and overlay-network flaws into full tenant isolation bypass

1 fonte(s) · 1 atualização(ões) · publicado 27/10/2026 09:00 · coletado há 5 dias

Kaspersky Security Services researchers detail a vulnerability chain found in a bug bounty pentest of an anonymized major cloud provider, which broke tenant isolation and could have given control of the whole cloud. Starting as a regular tenant, they escaped a privileged pod on a managed Kubernetes (k0s v1.25.16+k0s.0) worker node, abused Konnectivity to get RCE on the control plane, and escalated to root. From there the flat overlay network (100.64.0.0/10) exposed other tenants' managed services (Kafka, Redis, PostgreSQL, Valkey, MySQL) and the provider's SaltStack infrastructure. The provider fixed all issues, and Mirantis confirmed the Konnectivity vulnerability. The case placed second at Russian Pentest Award 2026 and was presented at SAS 2026 on October 22, 2026.

Entenda a falha

A vulnerabilidade

The most severe flaw is in the k0s fork of konnectivity-server, the Konnectivity component that tunnels between a Kubernetes control plane and its worker nodes. The article tested k0s v1.25.16+k0s.0 and names no fixed version. An attacker with root on a worker node and its Konnectivity service account token can reach port 8132 on the control plane. They get an SSRF primitive that leads to remote code execution there, as a low-privileged user (UID 997). Mirantis, the company behind k0s, confirmed the vulnerability, and no CVE is given for it. The chain also relies on a privileged-pod policy gap, an OverlayFS privilege escalation, a flat overlay network and unauthenticated internal services. Separately, CVE-2026-25243 is a heap overflow in Valkey's RESTORE command with legacy hash-zipmap encoding, which gives an arbitrary write primitive. The affected and fixed Valkey versions are not stated.

Como funciona

A worker node's Konnectivity agent connects to the AgentService Connect method on port 8132 and sends a stream of Packet messages. When the server receives a DIAL_REQ packet from the agent, it treats it as valid and passes it to the matching handler, which calls net.Dial() on the control plane side. Because the agent is not trusted, this lets a compromised node make the control plane open connections on its behalf. Those connections can reach network targets and host UNIX sockets such as the D-Bus system socket. Through D-Bus the researchers could ask systemd to run a user service, which produced a callback from the control plane.

Por que é vulnerável

In konnectivity-server, a DIAL_REQ coming from an agent is accepted and dialed without restriction, so a worker node, which sits on the less-trusted side, can direct the control plane to connect anywhere, including local UNIX sockets. The article does not describe the fix. The wider chain came from weak isolation: cluster policies allowed privileged pods with host namespaces, the overlay network 100.64.0.0/10 was flat, and internal services such as VictoriaMetrics, VictoriaLogs and etcd had no authentication. Cloud-init also printed root SSH private keys into logs.

Onde está

The article points to the AgentService Connect method and the DIAL_REQ handling that calls net.Dial() in the k0s fork of konnectivity-server (derived from apiserver-network-proxy), and to the RESTORE command with legacy hash-zipmap encoding in Valkey for CVE-2026-25243.

Como foi descoberta

Kaspersky Security Services researchers found the issues during a pentest of an anonymized major cloud provider, run under an official bug bounty program with the threat model of a regular tenant. They reported to the provider under responsible disclosure, and the provider fixed all issues. Mirantis confirmed the Konnectivity vulnerability. The case won second place at Russian Pentest Award 2026 and was presented at SAS 2026 on October 22, 2026. Securelist published the write-up on October 27, 2026.

Explicação gerada por IA a partir da matéria e dos artigos, em 27/10/2026 11:18.

Detalhes técnicos

  • Initial access: cluster policies allowed privileged pods with host namespaces; nsenter gave root on the worker node. A Konnectivity service account token and the kube-apiserver address (192.168.0.4, port 8132) were found on the host.
  • Konnectivity SSRF/RCE: the k0s fork of konnectivity-server (from apiserver-network-proxy) accepted DIAL_REQ packets from agents and called net.Dial() on the control plane, giving an SSRF primitive that reached host UNIX sockets. Via D-Bus (running as UID 997), the researchers enabled lingering and used StartTransientUnit to create a user systemd service, obtaining a callback from the control plane.
  • Privilege escalation: on Ubuntu 22.04 (kernel 5.15.x) with user namespaces enabled, a known OverlayFS bug let a python3 copy keep cap_setuid, yielding root.
  • Flat overlay network: an unauthenticated VictoriaMetrics API (/api/v1/targets) listed control plane hosts of other tenants. Unauthenticated VictoriaLogs (/select/logsql/query) exposed logs of all managed resources, including root SSH private keys that cloud-init printed to stdout. These keys allowed SSH access to other tenants' clusters.
  • Kafka: a JMX Registry on port 9999 was exposed to the shared network, allowing a malicious MBean to be loaded via MLet and giving RCE.
  • Redis: the redis-exporter /scrape target parameter could be pointed at an attacker host to capture the exporter's Redis credentials, which gave access to other tenants' instances.
  • PostgreSQL: unauthenticated etcd (port 2379) held the Patroni configuration. Modifying archive_command and adding standby_cluster triggered command execution on other tenants' databases. S3 backup credentials covering all databases in the cloud were also found.
  • SaltStack: from root on the control plane, a custom pillar script (_pillar/somebase.py) was vulnerable to error-based SQL injection via grains. It exposed the cloudsmth schema and the salt-masters table with Salt master API tokens, which allow commands on all minions. The attack was not developed further, by agreement with the vendor.
  • Valkey: CVE-2026-25243, a heap overflow in RESTORE with legacy hash-zipmap encoding, led to an arbitrary write primitive. The researchers worked around systemd sandboxing, planted an SSH key and escalated with the GRO Frag LPE.
  • MySQL: dropping and recreating a table with dynamic privileges gave admin rights. CRLF injection in the config via the provider API plus a malicious UDF gave RCE, and a root-run mysql-watcher.service was abused through a client auth plug-in for root.

Remediação

  • Isolate managed services to remove network visibility between them (no flat overlay).
  • Enforce strict AppArmor policies for service processes.
  • Monitor the use of potentially vulnerable services.
  • Block privileged pods and host namespace access in managed clusters, bind JMX/RMI to loopback, and never log secrets such as generated SSH keys.

Linha do tempo

  1. securelist.com ↗ · pub. 27/10/2026 09:00 · coletado 27/10 11:00 primeiro registro

    Pentest of a major cloud provider chains k0s Konnectivity RCE and overlay-network flaws into full tenant isolation bypass

    ler a análise desta fonte

    Kaspersky Security Services researchers detail a vulnerability chain found in a bug bounty pentest of an anonymized major cloud provider, which broke tenant isolation and could have given control of the whole cloud. Starting as a regular tenant, they escaped a privileged pod on a managed Kubernetes (k0s v1.25.16+k0s.0) worker node, abused Konnectivity to get RCE on the control plane, and escalated to root. From there the flat overlay network (100.64.0.0/10) exposed other tenants' managed services (Kafka, Redis, PostgreSQL, Valkey, MySQL) and the provider's SaltStack infrastructure. The provider fixed all issues, and Mirantis confirmed the Konnectivity vulnerability. The case placed second at Russian Pentest Award 2026 and was presented at SAS 2026 on October 22, 2026.

    Technical Details

    • Initial access: cluster policies allowed privileged pods with host namespaces; nsenter gave root on the worker node. A Konnectivity service account token and the kube-apiserver address (192.168.0.4, port 8132) were found on the host.
    • Konnectivity SSRF/RCE: the k0s fork of konnectivity-server (from apiserver-network-proxy) accepted DIAL_REQ packets from agents and called net.Dial() on the control plane, giving an SSRF primitive that reached host UNIX sockets. Via D-Bus (running as UID 997), the researchers enabled lingering and used StartTransientUnit to create a user systemd service, obtaining a callback from the control plane.
    • Privilege escalation: on Ubuntu 22.04 (kernel 5.15.x) with user namespaces enabled, a known OverlayFS bug let a python3 copy keep cap_setuid, yielding root.
    • Flat overlay network: an unauthenticated VictoriaMetrics API (/api/v1/targets) listed control plane hosts of other tenants. Unauthenticated VictoriaLogs (/select/logsql/query) exposed logs of all managed resources, including root SSH private keys that cloud-init printed to stdout. These keys allowed SSH access to other tenants' clusters.
    • Kafka: a JMX Registry on port 9999 was exposed to the shared network, allowing a malicious MBean to be loaded via MLet and giving RCE.
    • Redis: the redis-exporter /scrape target parameter could be pointed at an attacker host to capture the exporter's Redis credentials, which gave access to other tenants' instances.
    • PostgreSQL: unauthenticated etcd (port 2379) held the Patroni configuration. Modifying archive_command and adding standby_cluster triggered command execution on other tenants' databases. S3 backup credentials covering all databases in the cloud were also found.
    • SaltStack: from root on the control plane, a custom pillar script (_pillar/somebase.py) was vulnerable to error-based SQL injection via grains. It exposed the cloudsmth schema and the salt-masters table with Salt master API tokens, which allow commands on all minions. The attack was not developed further, by agreement with the vendor.
    • Valkey: CVE-2026-25243, a heap overflow in RESTORE with legacy hash-zipmap encoding, led to an arbitrary write primitive. The researchers worked around systemd sandboxing, planted an SSH key and escalated with the GRO Frag LPE.
    • MySQL: dropping and recreating a table with dynamic privileges gave admin rights. CRLF injection in the config via the provider API plus a malicious UDF gave RCE, and a root-run mysql-watcher.service was abused through a client auth plug-in for root.

    Remediation

    • Isolate managed services to remove network visibility between them (no flat overlay).
    • Enforce strict AppArmor policies for service processes.
    • Monitor the use of potentially vulnerable services.
    • Block privileged pods and host namespace access in managed clusters, bind JMX/RMI to loopback, and never log secrets such as generated SSH keys.