Loading story…
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).
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
Subsequent reporting emphasized the CVSS 10.0 severity of CVE-2026-22039 and noted that the same Kyverno update also fixed CVE-2026-23881, a high-severity denial-of-service issue that could crash the engine through unbounded memory consumption. The report reiterated that affected versions were 1.16.2 and earlier and 1.15.2 and earlier.
Public advisories described CVE-2026-22039 as a critical Kyverno flaw that lets an authenticated user who can create a namespaced Policy coerce Kyverno into making Kubernetes API requests beyond the policy's namespace. The disclosures noted impacts including cross-namespace reads, possible cluster-scoped writes, and effective escalation toward cluster-admin privileges.
Kyverno maintainers released security updates 1.16.3 and 1.15.3 to fix CVE-2026-22039, a critical authorization boundary bypass in namespaced Policy apiCall handling. The patch adds stricter validation to prevent cross-namespace targeting and closes a path to privilege escalation via the admission controller ServiceAccount.
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.
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.
Jul 17, 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
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