Loading story…
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:
--profiling=false
and ensuring that SSRF originating from the API server cannot reach sensitive internal services or metadata endpoints.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
Datadog Security Labs published an analysis showing how CVE-2020-8561 can be chained with profiling-enabled log-level changes to expose full responses from privileged network requests made by the Kubernetes API server. The report recommended disabling API server profiling and limiting control-plane network reachability to reduce impact.
Kubernetes documented CVE-2020-8561 for a vulnerability in which an authenticated user with sufficient privileges can abuse a ValidatingWebhookConfiguration to trigger server-side requests from the kube-apiserver. The issue was recognized as effectively unpatchable because it stems from intended API server behavior rather than a simple code flaw.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
1 reference tracked. Mallory keeps watching after this page renders.
Map 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.
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.
Jun 29, 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
Belgium's Centre for Cybersecurity warned organizations to patch **Kubernetes ingress-nginx** immediately after disclosure of an arbitrary code execution issue affecting the widely used NGINX Ingress Controller. The flaw, tracked as **`CVE-2026-3288`**, is a high-severity configuration injection vulnerability that lets an authenticated user with permission to create or modify Ingress resources inject arbitrary **nginx** directives through a crafted double quote in the Ingress path field, potentially leading to remote code execution and exposure of secrets accessible to the controller. Sysdig reported that **`CVE-2026-3288`** was fixed on March 9, 2026 and stemmed from an incomplete remediation of the related **`CVE-2026-24512`**. According to the company, sanitization had been added to one code path but omitted from another, while built-in validation relied on an incomplete blocklist that attackers could bypass with payloads such as `return` directives. Affected releases include ingress-nginx versions before **`v1.13.8`**, **`v1.14.4`**, and **`v1.15.0`**; defenders were urged to upgrade, tighten **RBAC** permissions for Ingress changes, and monitor Kubernetes audit logs for signs of exploitation.
Jun 29, 2026