Loading story…
A critical privilege-escalation vulnerability in Kyverno tracked as CVE-2026-54523 allows a low-privileged Kubernetes tenant to gain access across namespaces, including kube-system, by abusing the NamespacedGeneratingPolicy feature. The flaw affects Kyverno 1.18.1 and earlier and stems from missing validation in the CEL-based generator.apply() path, where Kyverno fails to ensure the target namespace matches the policy’s own namespace. Public disclosure included full technical details and proof-of-concept exploit code.
By creating a malicious NamespacedGeneratingPolicy, an attacker can trick Kyverno’s background controller—typically granted cluster-wide RBAC permissions—into generating resources in arbitrary namespaces. That can enable creation of privileged objects such as RoleBindings, potentially leading to admin-level access and broader manipulation of ConfigMaps, NetworkPolicies, and Ingresses across a cluster. The issue is fixed in Kyverno 1.18.2; defenders are urged to upgrade immediately, restrict who can create NamespacedGeneratingPolicy objects, audit existing policies for cross-namespace targets, and monitor sensitive namespaces for unexpected Role or RoleBinding creation. No confirmed in-the-wild exploitation was reported at publication time.
Get the actors, campaigns, and ATT&CK mapping behind it.
2 events from the most recent confirmed update back to the earliest known activity.
CVE-2026-54523 was publicly disclosed with technical details describing how a low-privileged tenant could abuse generator.apply() to make Kyverno create resources in arbitrary namespaces, including kube-system. One reference also states that full proof-of-concept exploit code was released, with no confirmed in-the-wild exploitation reported at the time of publication.
Kyverno addressed CVE-2026-54523, a cross-namespace privilege-escalation flaw, in version 1.18.2. The vulnerability affected versions up to and including 1.18.1 and stemmed from missing namespace authorization in the NamespacedGeneratingPolicy resource generation path.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references 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.
Maintainers of **Kyverno** (a Kubernetes-native policy engine) released fixes for a critical authorization boundary bypass in namespaced Policy `apiCall`, tracked as **CVE-2026-22039** (CVSS **10.0**). The issue is that the resolved `urlPath` is executed using the **Kyverno admission controller ServiceAccount** without enforcing that the request remains within the policy’s namespace, allowing a user who can create a namespaced Policy to coerce Kyverno into making Kubernetes API requests with Kyverno’s own RBAC permissions. This breaks namespace isolation and can enable cross-namespace reads (including **ConfigMaps** and potentially **Secrets**) and cross-namespace or cluster-scoped writes by controlling `urlPath` via context variable substitution. Impact includes potential **privilege escalation to cluster-admin** (e.g., by creating a `RoleBinding` in `kube-system`), data access across tenants, and cluster disruption (e.g., creating malicious **ClusterPolicies**). Affected versions are Kyverno prior to **1.16.3** and **1.15.3**, with patches available in **1.16.3** and **1.15.3**; reporting also notes an additional high-severity **DoS** issue addressed alongside the critical fix (**CVE-2026-23881**).
Jun 29, 2026
Red Hat disclosed **`CVE-2026-73269`**, a critical privilege-escalation flaw in the `cluster-curator-controller` component used by **OpenShift Multicluster Engine for Kubernetes**. The bug allows a tenant with only namespace-level access to create a crafted `ClusterCurator` resource whose `metadata.name` differs from `metadata.namespace`, triggering the controller to create a cluster-scoped `ClusterRoleBinding` and, in some cases, a `RoleBinding` in an arbitrary namespace. Those bindings can attach the tenant’s namespace-local `cluster-installer` service account to the powerful curator role, effectively breaking namespace isolation. Successful exploitation can elevate a local tenant to **cluster-wide privileges**, including access to and manipulation of secrets, management of cluster actions, and deletion of hosted clusters or node pools. The issue carries a **CVSS 3.1 score of 9.9** and affects `multicluster-engine/cluster-curator-controller-rhel9`. Red Hat advised organizations to apply vendor fixes and reduce exposure by restricting creation of `ClusterCurator` resources through RBAC, enforcing matching `metadata.name` and `metadata.namespace` with an admission controller, and reviewing permissions that allow creation of cluster-scoped resources.
Aug 13, 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