Executive Summary
In a responsible-disclosure penetration test of a major cloud provider, researchers demonstrated a complete tenant isolation bypass starting from a standard cloud tenant account. The attack chain began with a privileged Kubernetes pod escape on a managed k0s cluster, pivoted through a Server-Side Request Forgery (SSRF) primitive in the Konnectivity service to achieve remote code execution on the control plane, escalated to root via a known OverlayFS capability bug (Ubuntu 22.04, kernel 5.15), and then traversed a flat overlay network to compromise managed Kafka instances via exposed JMX/RMI, Redis instances via credential-leaking exporters, PostgreSQL clusters via unauthenticated etcd access, and ultimately the entire SaltStack management plane through SQL injection in a custom pillar extension—granting full control of all tenant resources, VDS, S3, and databases. All vulnerabilities were responsibly disclosed and fully remediated before publication.
This incident is directly relevant now because it dismantles the widely held assumption that cloud breaches originate exclusively from tenant misconfigurations. As enterprises accelerate multi-cloud adoption and place increasing trust in managed Kubernetes, database, and messaging services, provider-side logic flaws, flat internal networks, and unauthenticated management APIs represent systemic, cross-tenant blast-radius risks that no customer-side control can mitigate alone.
Why This Matters Now
Cloud providers are under intensifying regulatory scrutiny following a wave of supply-chain and infrastructure-level compromises. This research proves that a single tenant-level foothold can cascade into full cloud-platform takeover through chained logic flaws—none requiring zero-day exploits in the traditional sense. With CISA's Secure Cloud Business Applications (SCuBA) guidance, the EU Cyber Resilience Act, and PCI DSS 4.0 all tightening provider accountability, enterprises must now demand evidence of provider-side network segmentation, east-west traffic controls, and privileged-access governance—not just shared-responsibility attestations.
Attack Path Analysis
An external attacker with regular tenant privileges exploited a misconfigured managed Kubernetes cluster to deploy a privileged pod and escape to the worker node host, then leveraged a Konnectivity SSRF vulnerability to achieve RCE on the control plane. From there, a local privilege escalation via OverlayFS yielded root on the control plane node, exposing a flat overlay network (100.64.0.0/10) that provided unrestricted east-west access to VictoriaMetrics, VictoriaLogs, Kafka JMX, Redis exporters, PostgreSQL/etcd, and SaltStack infrastructure. Sensitive credentials harvested across these services — including SSH private keys, Redis auth tokens, S3 credentials, and Salt master tokens — enabled full tenant isolation bypass and theoretical takeover of all cloud-managed resources.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
The attacker, operating as a legitimate cloud tenant, created a privileged Kubernetes pod with hostPID enabled and a privileged securityContext in the provider's managed Kubernetes cluster (k0s v1.25.16). Using nsenter, they escaped the container to the underlying worker node host, gaining root access. This was possible because the cluster's admission policies did not prevent privileged pod creation — a provider-side misconfiguration, not a tenant misconfiguration.
Related CVEs
CVE-2023-5528
CVSS 8.8A privilege escalation vulnerability in Kubernetes allows a user with patch rights over nodes/pods to escalate to admin privileges via a specially crafted Kubernetes node object, relevant to the privileged pod escape technique described in the article against managed Kubernetes v1.25.
Affected Products:
Kubernetes Kubernetes – < 1.28.4, < 1.27.8, < 1.26.11, < 1.25.16
Exploit Status:
proof of conceptCVE-2023-0386
CVSS 7.8A flaw in the Linux kernel OverlayFS implementation allows an unprivileged local user to escalate privileges to root by exploiting incorrect permission checks during file copy-up operations, matching the OverlayFS privilege escalation technique used on Ubuntu 22.04 with kernel 5.15.x as described in the article.
Affected Products:
Linux Linux Kernel – < 6.2
Canonical Ubuntu – 22.04 LTS with kernel 5.15.x
Exploit Status:
exploited in the wild
MITRE ATT&CK® Techniques
Deploy Container
Escape to Host
Unsecured Credentials: Credentials In Files
Exploit Public-Facing Application
Adversary-in-the-Middle
Network Service Discovery
Command and Scripting Interpreter: Unix Shell
Abuse Elevation Control Mechanism: Setuid and Setgid
Cloud Storage Object Discovery
Valid Accounts: Cloud Accounts
Server Software Component: SQL Stored Procedures
Application Layer Protocol: Web Protocols
Exploitation of Remote Services
Data from Cloud Storage
Impair Defenses: Disable or Modify Tools
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Process Isolation / Boundary Protection / Information System Partitioning
Control ID: SC-39 / SC-7 / SC-32
PCI DSS 4.0 – Network Access Controls / Security Vulnerabilities / Access Control Systems
Control ID: Requirement 1.3 / 6.3 / 7.2
DORA (EU 2022/2554) – ICT Security Policies and Resilience / Detection and Response Capabilities
Control ID: Article 9 / Article 10
NIS2 Directive (EU 2022/2555) – Risk Management Measures / Supply Chain Security and Network Integrity
Control ID: Article 21(2)(a) / Article 21(2)(e)
CISA Zero Trust Maturity Model 2.0 – Workload Isolation and Identity-Aware Access Enforcement
Control ID: Network Pillar: Micro-Segmentation / Identity Pillar: Least Privilege
ISO/IEC 27001:2022 – Segregation of Networks / Secure Development Lifecycle / Capacity Management
Control ID: A.8.22 / A.8.25 / A.8.6
NYDFS 23 NYCRR Part 500 – Penetration Testing / Access Privileges / Security Awareness and Training
Control ID: 500.05 / 500.07 / 500.14
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Cloud infrastructure tenant isolation bypass via Kubernetes privilege escalation and SSRF exposes IT providers to lateral movement, credential leakage, and full multi-tenant control plane compromise requiring Zero Trust Segmentation and East-West Traffic Security controls.
Financial Services
Flat overlay network visibility across managed cloud tenants enables adversaries to intercept Redis credentials, access PostgreSQL clusters, and exfiltrate S3 backups containing sensitive financial data, violating PCI 4.0 and NIST 800-53 SC-7 egress enforcement requirements.
Health Care / Life Sciences
Unencrypted inter-tenant traffic traversal and unauthorized database access across shared cloud infrastructure risk HIPAA 164.312 violations, exposing patient records stored in managed PostgreSQL and Redis instances to credential theft and ransomware exfiltration.
Computer/Network Security
Chained Kubernetes escape, Konnectivity SSRF, SaltStack SQLi, and JMX RCE vulnerabilities demonstrate critical gaps in cloud-native enforcement, demanding Cloud Native Security Fabric deployment and Multicloud Visibility controls to detect anomalous control plane interactions.
Sources
- An insecure neighbor: how a vulnerability chain led to an isolation bypass in cloud infrastructurehttps://securelist.com/cloud-infrastructure-isolation-bypass/121609/Verified
- CVE-2023-5528 Detail - NVDhttps://nvd.nist.gov/vuln/detail/CVE-2023-5528Verified
- CVE-2023-0386 Detail - NVDhttps://nvd.nist.gov/vuln/detail/CVE-2023-0386Verified
- Kubernetes Security Announcement - CVE-2023-5528https://groups.google.com/g/kubernetes-security-announce/c/SJ6KR9LDSRYVerified
- Ubuntu Security Notice CVE-2023-0386https://ubuntu.com/security/CVE-2023-0386Verified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
- apiserver-network-proxy (Konnectivity) project - GitHubhttps://github.com/kubernetes-sigs/apiserver-network-proxyVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
This incident demonstrates how a flat, unsegmented overlay network inside a managed cloud provider transformed a single container escape into a full provider-level compromise spanning all tenants. Aviatrix Zero Trust CNSF would likely have constrained the attacker's reach across internal services and reduced the blast radius available after the initial node escape.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: CNSF workload-aware fabric visibility would likely reduce the reachability available to a newly escaped container, constraining how freely the attacker could interact with adjacent provider infrastructure from the compromised worker node.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely constrain the lateral reachability between the worker node and control plane components, reducing the scope of what the attacker could reach after the initial host escape even if the Konnectivity SSRF flaw itself remained unpatched.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement would likely have constrained the attacker's ability to move freely across VictoriaMetrics, VictoriaLogs, Kafka, Redis, etcd, PostgreSQL, and MySQL from a single compromised control plane node, reducing the number of services reachable in a single lateral sweep.
Control: Multicloud Visibility & Control
Mitigation: Centralized multicloud visibility and control would likely surface anomalous outbound connection patterns from internal managed service hosts, potentially reducing the attacker's ability to maintain undetected persistent callback channels across multiple compromised nodes simultaneously.
Control: Egress Security & Policy Enforcement
Mitigation: Egress security and policy enforcement would likely reduce the attacker's ability to exfiltrate harvested credentials and sensitive data outbound without restriction, constraining which hosts and protocols are permitted to initiate external data transfers from within the managed overlay network.
Had earlier CNSF controls reduced the attacker's lateral reach and egress freedom, the residual impact scope would likely be narrower — fewer harvested credentials, fewer compromised service endpoints, and a reduced ability to pivot from one tenant's assets to another's at provider scale.
Impact at a Glance
Affected Business Functions
- Multi-Tenant Cloud Infrastructure Management
- Managed Kubernetes and Database Services (PostgreSQL, Redis, Kafka, MySQL)
- Customer Data Isolation and Confidentiality
- Cloud Provider Control Plane and SaltStack Configuration Management
Estimated downtime: N/A
Estimated loss: N/A
The vulnerability chain enabled complete tenant isolation bypass across a major cloud provider platform. Exposed data categories include: private SSH keys for root accounts of other tenants' managed Kubernetes control plane nodes (found in shared VictoriaLogs); authentication credentials for Redis instances belonging to other cloud tenants; PostgreSQL database contents and associated S3 backup storage credentials and backup data for all databases in the cloud; SaltStack master authentication tokens providing command execution across all managed minions; full metadata of all managed resources and VDS instances from the cloudsmth database schema (approximately 50 tables); JMX-accessible Kafka instance data with remote code execution capability; and MySQL administrative credentials enabling full database takeover. The research was conducted as part of a responsible disclosure bug bounty program and all vulnerabilities were remediated by the vendor prior to publication. No confirmed data exfiltration by malicious actors was disclosed. The potential impact, if exploited maliciously, would constitute a catastrophic multi-tenant breach affecting all customers of the cloud platform.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce Zero Trust Segmentation on the overlay network: The flat 100.64.0.0/10 overlay network with no east-west controls was the primary enabler of lateral movement across all managed services. Deploying identity-based microsegmentation (CNSF Zero Trust Segmentation / ZTMM.Network) with least-privilege workload-to-workload policies — blocking all unintended service-to-service flows by default — would have contained the breach to the initial worker node and prevented access to VictoriaMetrics, Kafka, Redis, PostgreSQL, and SaltStack.
- • Deploy East-West Traffic Security with anomaly detection: The absence of any workload traffic inspection on the provider's internal overlay network allowed the attacker to enumerate services, intercept credentials, and exploit JMX/etcd/redis-exporter endpoints without detection. Inline east-west traffic security (CNSF East-West Traffic Security / ZTMM.Data + NIST.800-53.SC-7) combined with behavioral baselining would have flagged anomalous cross-tenant service queries, unauthenticated etcd access, and JMX RMI stub interactions as high-priority alerts.
- • Apply Kubernetes Security controls at the admission layer (AKF): The root cause of initial compromise was the absence of pod security admission policies preventing privileged pod creation with hostPID. Kubernetes firewall and namespace enforcement controls (CNSF Kubernetes Security / ZTMM.Applications + NIST.800-53.SC-39) enforcing pod-level identity, disabling privileged containers, and restricting host namespace access would have blocked the container breakout entirely at the Initial Compromise stage.
- • Enforce Egress Security and Policy Enforcement for all managed service nodes: Control plane nodes and managed service hosts (Kafka, Redis, PostgreSQL, MySQL) communicated outbound to attacker infrastructure via curl/reverse shells with no egress filtering. CNSF Egress Security with FQDN filtering and application-to-internet policy enforcement (ZTMM.Data + NIST.800-53.SC-18) would have blocked unauthorized outbound connections from internal managed service nodes, preventing payload download, callback establishment, and data exfiltration to attacker-controlled endpoints.
- • Leverage Multicloud Visibility and Control to detect anomalous control plane interactions: Repeated DIAL_REQ packets to UNIX sockets via Konnectivity, unauthenticated bulk queries to VictoriaMetrics and VictoriaLogs, and SQL injection attempts via Salt grains all represent anomalous control plane behaviors. Centralized traffic observability and anomaly detection (CNSF Multicloud Visibility / ZTMM.CrossCutting.Visibility + NIST.800-53.AU-6) with alerting on suspicious automation patterns and malformed protocol requests would have surfaced attacker activity during Privilege Escalation and Lateral Movement stages before credentials were harvested.



