Loading story…
New technical writeups highlighted how seemingly read-only Kubernetes permissions can be escalated into remote code execution (RCE) by abusing access paths to the kubelet API. Horizon3.ai detailed a technique where a service account granted nodes/proxy GET (often treated as “read-only” for monitoring/log access) can, if it also has network reachability to the kubelet, be leveraged to execute commands in pods on reachable nodes—an outcome the Kubernetes project has largely treated as “working as intended” rather than a traditional vulnerability. The post emphasizes that this can translate into broad cluster compromise in many real environments and points to mitigations such as tightening RBAC and adopting controls aligned with KEP-2862 and vendor RBAC hardening guidance.
Separately, a bug-bounty case study described an end-to-end cloud-native kill chain culminating in Kubernetes takeover: an initial SSRF in a microservice was used to access EC2 instance metadata and steal cloud credentials, which then enabled kubelet API abuse to deploy a rogue privileged pod. From that foothold, the attacker obtained a more powerful Kubernetes service account token and escalated to cluster-admin, resulting in full cluster control and a reported $100,000 responsible disclosure payout. While the initial access vectors differ, both accounts reinforce that kubelet exposure plus permissive RBAC/service-account design can turn “limited” access into cluster-wide impact, making kubelet reachability and nodes/proxy/kubelet-related permissions high-priority review items for Kubernetes security programs.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
7 events from the most recent confirmed update back to the earliest known activity.
Kubernetes announced that v1.36 graduates fine-grained kubelet API authorization to general availability, with KubeletFineGrainedAuthz locked enabled. The change introduces dedicated kubelet subresources such as nodes/metrics, nodes/stats, nodes/log, and nodes/pods to reduce reliance on the overly broad nodes/proxy permission that had enabled kubelet /exec abuse.
Datadog Security Labs published analysis of CVE-2020-8562, describing how a time-of-check/time-of-use flaw in Kubernetes API server proxying can be combined with DNS rebinding to reach restricted destinations such as localhost or cloud metadata endpoints. The article included a proof of concept using a fake Node object and recommended mitigations such as minimum DNS TTL enforcement and Konnectivity.
Horizon3.ai published research showing that a service account with nodes/proxy and verb GET can be abused to reach the kubelet WebSocket /exec endpoint and achieve code execution in arbitrary pods on a node. The post also highlighted that this access pattern is common in default Helm chart deployments and can be stealthier than pods/exec because it may not appear directly in Kubernetes audit logs.
According to Horizon3.ai, the Kubernetes Security Team reviewed the nodes/proxy GET to kubelet exec authorization gap, classified it as 'Won’t Fix (Working as Intended),' and did not assign a CVE. The team reportedly pointed to KEP-2862 as the longer-term approach for reducing reliance on nodes/proxy permissions.
From the privileged pod, the attacker obtained a high-privilege Kubernetes ServiceAccount token that granted cluster-admin permissions, resulting in full cluster compromise. The author says the issue was responsibly disclosed and led to a $100,000 bug bounty payout.
Using node-level credentials, the attacker accessed the Kubelet API and deployed a rogue privileged pod into the Kubernetes cluster. This provided a foothold on the cluster that enabled further privilege escalation.
A cloud-native attack chain began with a server-side request forgery flaw in a microservice, which was used to access EC2 instance metadata and obtain cloud credentials from the underlying node environment. This initial access enabled movement from an application bug into the cloud and Kubernetes control plane context.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
4 references tracked. Mallory keeps watching after this page renders.
kubernetes.io
Open sourcesecuritylabs.datadoghq.com
Open sourcehorizon3.ai
Open sourceinfosecwriteups.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Palo Alto Networks Unit 42 disclosed a dual privilege-escalation chain in **Google Kubernetes Engine (GKE)** that could let an attacker with limited access gain broader control inside Kubernetes environments. The attack path combined weaknesses in monitoring-related configuration and service mesh privileges, allowing unauthorized access to cluster resources and creating a route from a constrained foothold to elevated permissions. The reported chain involved **Fluent Bit** and **Anthos Service Mesh** components, showing how overly permissive configurations and inherited privileges in managed Kubernetes deployments can be linked together for escalation. The findings highlight the risk of misconfigured observability and mesh tooling in cloud-native environments, where service accounts, cluster roles, and add-on integrations can expand an attacker’s reach beyond the initial compromise if not tightly scoped.
Jul 3, 2026
Kubernetes maintainers disclosed five critical vulnerabilities in **ingress-nginx**, including **`CVE-2025-1974`** with a **CVSS 9.8** rating, warning that attackers on the Pod network could abuse configuration injection in the Validating Admission Controller to take over clusters without credentials. The flaws also affect how ingress-nginx builds **NGINX** configuration from crafted Ingress objects, potentially exposing Secrets available to the controller and leading to full cluster compromise. Patched releases **`ingress-nginx v1.12.1`** and **`v1.11.5`** were issued, and operators were urged to upgrade immediately or temporarily disable the Validating Admission Controller until patching is complete. The disclosure adds to broader concerns about Kubernetes networking and multi-tenant isolation, highlighted by **`CVE-2021-25740`**, an unpatchable issue that lets users with permission to modify **Endpoint** or **EndpointSlice** objects redirect service traffic to unauthorized IP addresses. In shared ingress-controller or load-balancer deployments, that behavior can allow one tenant to steer traffic into another tenant’s workloads and bypass intended network boundaries. Security researchers and vendors said the combined risk is highest in clusters that rely on shared ingress infrastructure with broad Secret access, and recommended tightening EndpointSlice permissions, avoiding shared ingress designs in sensitive environments, and evaluating the **Gateway API** as a safer architecture.
Jun 29, 2026
Datadog Security Labs detailed **CVE-2020-8561**, an unpatchable Kubernetes weakness that can turn the `kube-apiserver` into a high-impact server-side request forgery (**SSRF**) proxy. An attacker with valid Kubernetes credentials and elevated privileges, typically `cluster-admin`, can abuse a `ValidatingWebhookConfiguration` object to make the API server send requests to attacker-controlled or internal destinations. By combining that behavior with profiling-enabled log-level changes, the attacker can cause the API server to log full responses from those privileged network requests rather than merely confirming whether a port is reachable. The issue is most dangerous when the Kubernetes control plane sits in a more trusted network segment than worker nodes, including managed Kubernetes environments hosted inside cloud provider networks. Because there is no straightforward code fix, defenders are being urged to reduce exposure through configuration and architecture changes, notably disabling API server profiling with: ```bash --profiling=false ``` and ensuring that SSRF originating from the API server cannot reach sensitive internal services or metadata endpoints.
Jun 29, 2026