"It covers the sequential exploitation of several vulnerabilities and logic errors." — the research that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026.
Escaping the worker node in k0s-managed Kubernetes (v1.25.16+k0s.0)
The chain began with a tenant-level resource in a managed Kubernetes cluster (v1.25.16+k0s.0). The provider’s policies did not block creation of privileged pods with host namespace access, allowing the researchers to run a privileged container, invoke nsenter to target PID 1, and obtain a bash shell on the host. From that host they extracted a Konnectivity service token and the kubelet configuration, which revealed the control-plane address 192.168.0.4 and multiple exposed ports — notably port 8132 where a konnectivity-derived AgentService listened.
SSRF via Konnectivity: from DIAL_REQ to D‑Bus interaction
The konnectivity-derived server accepted DIAL_REQ packets from agents and performed net.Dial() on the control-plane side using the packet’s protocol and address. That behavior produced an SSRF primitive inside the control plane context that could reach internal network services and UNIX sockets. The researchers targeted the system D‑Bus socket and, using busctl and a custom D‑Bus client, retrieved the current process UID and enabled lingering for that UID. With systemd --user sockets available, they used StartTransientUnit to run a curl payload and received a callback from the control plane. Mirantis, the company behind k0s, confirmed the vulnerability in konnectivity.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleFlat overlay network: VictoriaMetrics, VictoriaLogs, Kafka, Redis, and Patroni
Gaining host privileges exposed a flat overlay network (100.64.0.0/10) that made many managed services visible to each other. A VictoriaMetrics instance (100.64.13.37:8429) returned lists of scrape targets whose labels revealed cluster metadata and control-plane hosts for other tenants. VictoriaLogs’ HTTP API permitted unauthenticated queries that exposed system logs, and those logs contained cloud-init output with private root SSH keys.
On managed Kafka hosts the researchers found JMX/RMI services exposed to the overlay. By loading a malicious MLet and MBean (Exec) via the JMX registry they achieved remote command execution in the Kafka JVM because the RMI stub was reachable from the shared network instead of being bound to loopback.
Redis exporters on port 9121 accepted an arbitrary target parameter and attempted to scrape it using the exporter’s own Redis credentials. By pointing scrape requests at attacker-controlled endpoints, the researchers intercepted AUTH commands and recovered credentials for other tenants’ Redis instances. For PostgreSQL/Patroni clusters, an open etcd endpoint allowed write access to Patroni configuration keys; changing archive_command and forcing a standby_cluster setting produced a demotion/restart sequence that executed the injected archive command and yielded host-level RCE. Backup files found on those hosts also contained S3 credentials and lists of backup locations.
SaltStack, SQL injection, and the path to wide control
With root on a control-plane host, the team analyzed the Salt master filesystem and found a custom pillar-processing script (_pillar/somebase.py) that built SQL queries with Python’s query.format(). A Salt minion can trigger pillar refreshes and supply arbitrary grains; that behavior permitted error‑based SQL injection into the production database. Among the exposed tables was cloudsmth.salt-masters, which contained authentication tokens for all Salt masters. Possession of those tokens, the researchers noted, allowed access to the Salt master REST API and execution of arbitrary commands across minions — a single step that could take over VDS, S3, and other managed resources. By agreement with the vendor the attack chain stopped at that point.
What this means for technologists, procurement leaders, and cloud tenants
- Technologists and security teams: the case demonstrates how an SSRF in a control-plane tunnel, privileges on a host, and a flat overlay can be composed into tenant‑isolation bypasses. The researchers recommended isolating managed services, enforcing strict AppArmor policies, and adding monitoring for abnormal use of vulnerable services.
- Procurement leaders and cloud architects: using in-house or forked components (the konnectivity fork in this instance) changes the attack surface; visibility into how vendor-managed control planes handle agent-initiated requests should be a procurement and architecture question.
- Cloud tenants and operators: logs and configuration artifacts (cloud-init output, backup files, exporter targets) can leak high-value secrets such as SSH keys and S3 credentials; shared logging and metrics systems need strict access controls and redaction.
The researchers presented this technical analysis on October 22, 2026 at Security Analyst Summit (SAS 2026) and reported the findings under a responsible-disclosure policy; all issues were fixed. Their work underscores a simple, uncomfortable truth: layered assumptions about isolation can be overturned when multiple small flaws align. The practical takeaway is not theoretical—it is operational: isolate control-plane interactions, minimize cross-tenant visibility on overlays, and treat management-plane telemetry and exporters as sensitive interfaces, not convenience endpoints.
