5 Kubernetes Threats Behind Real-World Breaches and How to Defend Against Them

As enterprises increasingly rely on Kubernetes (K8s) to power cloud infrastructure, the platform has become one of the most targeted entry points in the threat landscape. Its very architecture introduces a fundamental structural vulnerability, and as a result, high-profile breaches are now following repeatable paths that begin deep inside the cluster.

As workloads, identity, and control planes converge onto a single operational layer, threat actors are turning routine runtime access into broader corporate compromise. A single foothold inside a Kubernetes cluster via a stolen token, an exposed service, or an overpermissioned workload is often enough to reach far beyond it.

Five attack paths explain how this happens and understanding them can prevent a single compromised workload from turning into a seven-figure loss.

1. Stolen service account tokens

When workloads are compromised, mounted service account tokens are exposed. Because these tokens provide authenticated access to the Kubernetes API, acquiring them allows threat actors to reuse workload identities across various cluster components. This structural vulnerability turns a single compromised application into a trusted, authenticated vector for administrative commands.

The Bybit breach illustrated this risk, resulting in the theft of approximately $1.5 billion in customer crypto assets and the exposure of exchange wallet and transaction data.

Threat actors tracked as Slow Pisces carried out the intrusion by targeting a developer account and exfiltrating AWS session tokens to deploy an unauthorized pod. Through routine harvesting of mounted tokens, the pod enabled admin access across the exchange’s cloud infrastructure via Kubernetes-connected workloads.

This unfettered API access ultimately allowed them to pivot silently into core transaction databases, escalating a single endpoint compromise into a catastrophic corporate treasury drain.

2. Exploitation of exposed workloads

Access to Kubernetes environments is frequently achieved through exposed services and applications facing the public internet.

Once an entry point is established, threat actors can run commands directly on the underlying container, operating with the immediate legitimacy of a standard authorized user. This initial footprint grants immediate access to everything the container can see, including local configuration files, embedded credentials, active network connections, and identity permissions within the cluster.

This exposure path materialized at scale during the widespread exploitation of React2Shell (CVE-2025-55182), which led to the compromise of Kubernetes secrets across more than 700 organizations in the government and financial sectors.

Multiple threat actors, including China-nexus groups Earth Lamia and Jackpot Panda, carried out this intrusion by exploiting the vulnerability to reach inside containerized workloads. Once inside, they harvested Kubernetes secrets and established persistent backdoors across government and financial sectors for long-term espionage.

Before software patches could be distributed, threat actors had already achieved persistent access across entire sectors.

3. Overprivileged access and role-based access control (RBAC) abuse

Kubernetes environments frequently assign permissions broader than required for individual workloads to function.

When an individual container is compromised, these excessive privileges transfer directly to the threat actor, determining exactly how far they can move horizontally across the infrastructure. This configuration breakdown transforms a limited runtime foothold into expansive access across core cluster resources.

A mid-2025 intrusion at an unnamed cryptocurrency exchange exposed the severe impact of this flaw, resulting in unauthorized access to internal financial systems and the theft of millions in treasury funds and from customer-facing wallet infrastructure.

Threat actors carried out the intrusion by compromising a developer workstation via spearphishing to deploy a malicious pod, leveraging an overprivileged CI/CD service account token to freely cross namespaces, plant backdoors in production workloads, and pivot into the exchange’s wider environment.

This horizontal progression effectively bypassed all traditional application silos, turning an isolated developer-tier mistake into an expensive, multi-namespace infrastructure lockout.

4. Kubernetes API abuse for lateral movement

With valid credentials in hand, threat actors can operate directly through the Kubernetes API, executing cluster commands in the exact same manner as legitimate administrators.

Such administrative API access allows adversaries to discover secrets, map namespaces, and locate high-value workloads without triggering standard behavioral alerts. This malicious activity blends seamlessly into ordinary, high-volume cluster operations to bypass detection.

The SCARLETEEL operation exposed exactly how easily attackers can exploit this blind spot — using it to drain AWS credentials, steal proprietary software, and expand their reach across connected cloud infrastructure.

Threat actors carried out the attack by exploiting an internet-exposed application inside the Kubernetes cluster, using the compromised container to make API calls that enumerated cloud resources, harvested credentials, and moved laterally across connected AWS accounts — with the API abuse allowing them to operate within legitimate cloud infrastructure.

By masking their reconnaissance commands entirely within normal, high-volume administrative API traffic, they achieved an extended operational dwell time that left legacy defenses completely blind.

5. Cloud escalation beyond the cluster

Kubernetes access frequently serves as a strategic bridge into broader cloud environments. Specifically, stolen workload identities enable movement out of the isolated cluster and into cloud IAM, cloud storage, and critical backend systems.

Because these backend environments are frequently where the most sensitive enterprise assets live, cluster infiltration risks the security of the entire multi-cloud footprint.

The Taiwanese BitoPro intrusion, widely attributed to the Lazarus Group, capitalized directly on this cross-environment trust, resulting in unauthorized transfers from hot wallets and the theft of $11 million in crypto assets.

Threat actors carried out the attack by using compromised session tokens to access cloud infrastructure, leveraging Kubernetes access as a bridge into the broader cloud environment during a wallet system upgrade.

By pushing malicious scripts into the hot-wallet host to intercept active workflows during a scheduled upgrade window, they weaponized the cluster’s trust relationship with the broader cloud layout to cleanly extract the assets.

Improve Visibility, Detection, and Response Across Kubernetes Environments to Elevate Your Security Posture

As AI drives Kubernetes from an operational choice to an enterprise necessity, the target on its back will only grow. Staying ahead of these evolving threats is no longer optional; it requires organizations to detect, contain, and respond to malicious activity faster than ever before.

Fast, effective defense starts with absolute visibility coupled with continuous threat detection and response.  

Traditional security tools struggle to keep pace with the ephemeral, dynamic nature of containers, where workloads, identities, and network paths constantly change. This architectural fluidity creates persistent blind spots in east-west traffic and cross-environment activity, making both detection and response significantly more difficult than necessary.

Because Kubernetes is now a core control plane for cloud and AI infrastructure, security outcomes are determined entirely by how quickly organizations maintain continuous context as signals shift in real-time.

Five Core Requirements for Modern Cluster Security

Addressing the architectural realities of Kubernetes environments and defusing modern attack patterns requires a shift toward real-time, context-aware security.

Organizations must be able to:

• Baseline normal behaviors across clusters: This ensures unusual workload activity stands out immediately, reducing time spent guessing what “bad” looks like.
• Correlate Kubernetes activity with identity data: This allows teams to spot credential abuse in real time, such as a container suddenly acting on a stolen or misused identity.
• Link cluster activity with threat intelligence: This flags communication with known malicious infrastructure, exposing images communicating with nation-state command and control servers.
• Inspect encrypted service-to-service traffic: This ensures that encryption does not become cover for lateral movement or data exfiltration.
• Preserve a full activity history across ephemeral workloads: This ensures investigators can reconstruct what happened, and why, supporting faster response, better auditing, and stronger compliance.

From Compromise to Control

These real-world attack paths demonstrate how initial compromises quickly escalate into full cloud breaches in the absence of strong network visibility, detection, and response capabilities.

Learn how ExtraHop detects threat actors at speed and scale across Kubernetes environments.