Kyverno
Monthly
Cross-namespace information disclosure in Kyverno before 1.19.1 allows an authenticated low-privilege tenant to read resources from other namespaces by abusing the apiCall context entry in namespaced Policy resources. The attacker crafts percent-encoded dot-segments in urlPath so that Kyverno's validation and execution stages interpret the path inconsistently, ultimately using the admission controller's ServiceAccount credentials to fetch data across the namespace boundary. Exploitation requires the ability to create or modify namespaced Policy resources and a multi-tenant deployment where namespace isolation is the security boundary; no public exploit identified at time of analysis, and a vendor patch is available in Kyverno 1.19.1.
Privilege escalation in Kyverno before 1.19.1 allows an authenticated Kubernetes namespace tenant with Policy/apiCall authoring rights to escape namespace isolation and create objects as Kyverno's admission-controller ServiceAccount. The attacker supplies percent-encoded directory-traversal sequences in the Policy apiCall urlPath to bypass the per-namespace clamp, enabling creation of cluster-wide MutatingWebhookConfiguration objects or PolicyException objects in the kyverno namespace, with a path to cluster-admin escalation. No public exploit identified at time of analysis; vendor patch available in 1.19.1.
Server-side request forgery in Kyverno before 1.19.1 lets a user who can author a ClusterPolicy or GlobalContextEntry with a non-CEL context[].apiCall.service call force the admission controller to issue GET/POST requests to an arbitrary destination, including cloud metadata endpoints, loopback, and any in-cluster service, thereby reading cloud instance credentials and reaching internal endpoints from Kyverno's network position. The vulnerable legacy executor and the GlobalContextEntry external-API path use a plain net/http client with no egress blocklist and no validation of the configured service URL, and they unconditionally attach Kyverno's projected ServiceAccount token to the attacker-chosen destination (the token is audience-scoped, limiting replay value). Exploitation requires high privileges because the attacker must already be able to write cluster-scoped policy objects (PR:H); the bar drops to a lower-privileged resource submitter only in the non-default case where a deployed policy templates the service URL from the admission resource. There is no public exploit identified at time of analysis, and the vendor rates the issue 8.3 (High) under CVSS 4.0.
Kyverno 1.14.0 through 1.19.0 fail open in a way that lets unsigned or untrusted container images be admitted to a Kubernetes cluster: the ImageValidatingPolicy evaluator silently ignores the spec.images and spec.allowedValues fields of a PolicyException, so any exception whose policyRefs and matchConditions match a resource disables image signature verification for that entire resource rather than only for the named images or values. An authenticated user with Kubernetes API rights sufficient to deploy or modify workloads covered by such an exception (CVSS PR:L) can therefore bypass signature enforcement without obtaining any new privileges - the flaw simply turns a narrow, trust-anchored carve-out into a blanket exemption. No public exploit code identified at time of analysis, and the vendor has released a fix in Kyverno 1.19.1; scope is limited to clusters that actively enforce signature verification through ImageValidatingPolicy and define matching PolicyExceptions.
Cross-namespace information disclosure in Kyverno 1.16.0 through 1.19.0 lets an authenticated tenant with RBAC permission to create namespaced policy objects read the full cached contents of cluster-scoped GlobalContextEntry resources - including data from namespaces they have no RBAC access to - by invoking globalContext.get() in a CEL policy. The root cause is that the globalcontext.Lib CEL library is registered in the policy environment without the namespace confinement applied to its sibling libraries (resource.Lib, http.Lib, configMap loader), and no admission validation blocks the call. Exploitation requires a multi-tenant cluster with a GlobalContextEntry configured and caching data the tenant cannot otherwise read, so the blast radius is bounded by those preconditions and the flaw is inert on single-tenant clusters or clusters with no GlobalContextEntry; no public exploit identified at time of analysis, and the issue is fixed in Kyverno 1.19.1.
Policy enforcement bypass in Kyverno v1.9.0 through v1.12.7 lets an authenticated Kubernetes user evade an enforce-mode ClusterPolicy when two overlapping PolicyExceptions apply to the same rule, because the less-restrictive exception wins. An attacker who can name a workload to match a permissive exception pattern (for example '*ingress*') can deploy resources the policy was meant to block, such as Pods with hostPath volumes. The vendor GHSA advisory (GHSA-gg4x-fgg2-h9w9) includes working reproduction manifests; there is no CISA KEV listing and no confirmed in-the-wild exploitation.
Server-side request forgery in Kyverno's Kubernetes admission controller (all versions before 1.18.0) enables any authenticated cluster user to redirect the admission controller's privileged HTTP client to cloud metadata endpoints (e.g., AWS IMDS at 169.254.169.254), internal ClusterIP services, and loopback addresses by injecting malicious URLs through JMESPath variable substitution in ClusterPolicy `apiCall.service.url` definitions. Critically, this is non-blind SSRF: response bodies are reflected back to the attacker through admission error messages visible in kubectl output, enabling direct credential and data exfiltration in a single API call. A fully functional proof-of-concept is published in GHSA-qr4g-8hrp-c4rw; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Credential leakage in Kyverno's apiCall service mode automatically forwards the Kubernetes admission controller's ServiceAccount bearer token to any external HTTP endpoint referenced in a policy, including attacker-controlled servers. Affecting Kyverno before 1.16.4 (fix version disputed - see confidence notes), this insecure-by-default behavior requires only policy-creation privileges to exploit: a low-privileged user crafts a ClusterPolicy pointing apiCall.service.url at an attacker-controlled host, then triggers a matching admission event, causing Kyverno to self-exfiltrate its SA token. No public exploit is confirmed in CISA KEV, but a working proof-of-concept with full reproduction steps is embedded in the GitHub security advisory GHSA-8wfp-579w-6r25.
Cross-namespace privilege escalation in Kyverno 1.18.0-1.18.1 lets any tenant who can create a NamespacedMutatingPolicy in their own namespace force the cluster-privileged admission controller to generate resources (ConfigMaps, Secrets, NetworkPolicies, RoleBindings) in arbitrary namespaces, including kube-system. The nmpol CEL compiler unintentionally exposes the generator library to matchConditions, and neither the mpol validator nor GenerateResources enforces namespace scope on the generator.apply() target. A working proof-of-concept is published in the vendor advisory (GHSA-79gf-7frw-68m9); there is no KEV listing or evidence of active exploitation, and the issue is fixed in 1.18.2.
A type assertion bug in Kyverno's forEach mutation handler crashes the cluster-wide background controller into CrashLoopBackOff and blocks admission controller operations, causing denial of service for policy-matched resources. Any authenticated user with Policy or ClusterPolicy creation permissions can trigger the crash by creating a malformed policy. The vulnerability affects Kyverno versions prior to 1.17.2 and 1.16.4, is limited to the legacy policy engine (CEL-based policies unaffected), and persists until the malicious policy is deleted. Vendor-released patches available with confirmed fix commits on GitHub.
Kyverno's apiCall feature automatically attaches the admission controller's ServiceAccount token to HTTP requests without validating the destination URL, enabling authenticated attackers to exfiltrate tokens to attacker-controlled servers and achieve full cluster compromise through webhook configuration tampering. Affects Kyverno versions prior to 1.18.0-rc1, 1.17.2-rc1, and 1.16.4. Vendor-released patches available across all three affected version branches. EPSS data not provided, but the vulnerability enables privilege escalation from low-privilege Kubernetes user to cluster admin via token theft, representing critical risk in multi-tenant environments.
Cross-namespace privilege escalation in Kyverno 1.17.x allows authenticated namespace administrators to bypass RBAC controls and read ConfigMaps from any Kubernetes namespace. The vulnerability exploits unvalidated `configMap.namespace` field in Kyverno's ConfigMap context loader, enabling attackers to leverage Kyverno's privileged service account permissions. This is a regression following incomplete fix for CVE-2026-22039, which addressed the same issue in `apiCall` context but missed the ConfigMap loader. Patch available in version 1.17.2. CVSS 7.7 with Changed Scope indicates significant multi-tenant cluster risk; EPSS data not available but the regression nature and RBAC bypass impact warrant immediate patching in multi-tenant environments.
Kyverno versions 1.16.0 and later contain a server-side request forgery vulnerability in unrestricted CEL HTTP functions that allow attackers to make arbitrary HTTP requests from the Kyverno controller, potentially accessing internal services and metadata endpoints. The vulnerability affects Kubernetes clusters running vulnerable Kyverno versions with policies utilizing CEL-based HTTP operations, with no CVSS or EPSS data currently available to quantify severity.
Kyverno versions up to 1.16.3 is affected by allocation of resources without limits or throttling (CVSS 7.7).
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass and unauthorized cluster operations.
Server-side request forgery in Kyverno's APICall feature (all versions before 1.16.2) enables any user holding namespace-level Policy creation rights to weaponize Kyverno's cluster-wide, high-privilege ServiceAccount as a confused deputy - directing it to issue HTTP requests to arbitrary internal endpoints including cloud IMDS at 169.254.169.254. Responses, potentially containing other tenants' database passwords, API keys, and cloud IAM role credentials, are surfaced in the PolicyReport and are readable by the attacking tenant, completely collapsing multi-tenant isolation. No public exploit has been identified at time of analysis, though the attack path is straightforward and the impact in shared Kubernetes clusters is severe.
Server-side request forgery in Kyverno's Service Call feature (versions before v1.13.4) allows any cluster user holding ClusterPolicy creation rights to exfiltrate arbitrary Kubernetes resource data - including Secrets - by directing policy apiCall requests to an attacker-controlled external server. The vulnerability stems from a missing URL validation that permits the apiCall/service block, documented for in-cluster services, to resolve and POST data to internet-accessible endpoints. Publicly available exploit code exists in the form of a working PoC ClusterPolicy published in the GHSA advisory; no active exploitation is confirmed via CISA KEV.
Kyverno is a policy engine designed for cloud native platform engineering teams. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable. Public exploit code available.
Kyverno is a policy engine designed for cloud native platform engineering teams. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploitable. Public exploit code available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 8.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. No vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
An image signature validation bypass vulnerability in Kyverno 1.8.3 and 1.8.4 allows a malicious image registry (or a man-in-the-middle attacker) to inject unsigned arbitrary container images into a. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.
Cross-namespace information disclosure in Kyverno before 1.19.1 allows an authenticated low-privilege tenant to read resources from other namespaces by abusing the apiCall context entry in namespaced Policy resources. The attacker crafts percent-encoded dot-segments in urlPath so that Kyverno's validation and execution stages interpret the path inconsistently, ultimately using the admission controller's ServiceAccount credentials to fetch data across the namespace boundary. Exploitation requires the ability to create or modify namespaced Policy resources and a multi-tenant deployment where namespace isolation is the security boundary; no public exploit identified at time of analysis, and a vendor patch is available in Kyverno 1.19.1.
Privilege escalation in Kyverno before 1.19.1 allows an authenticated Kubernetes namespace tenant with Policy/apiCall authoring rights to escape namespace isolation and create objects as Kyverno's admission-controller ServiceAccount. The attacker supplies percent-encoded directory-traversal sequences in the Policy apiCall urlPath to bypass the per-namespace clamp, enabling creation of cluster-wide MutatingWebhookConfiguration objects or PolicyException objects in the kyverno namespace, with a path to cluster-admin escalation. No public exploit identified at time of analysis; vendor patch available in 1.19.1.
Server-side request forgery in Kyverno before 1.19.1 lets a user who can author a ClusterPolicy or GlobalContextEntry with a non-CEL context[].apiCall.service call force the admission controller to issue GET/POST requests to an arbitrary destination, including cloud metadata endpoints, loopback, and any in-cluster service, thereby reading cloud instance credentials and reaching internal endpoints from Kyverno's network position. The vulnerable legacy executor and the GlobalContextEntry external-API path use a plain net/http client with no egress blocklist and no validation of the configured service URL, and they unconditionally attach Kyverno's projected ServiceAccount token to the attacker-chosen destination (the token is audience-scoped, limiting replay value). Exploitation requires high privileges because the attacker must already be able to write cluster-scoped policy objects (PR:H); the bar drops to a lower-privileged resource submitter only in the non-default case where a deployed policy templates the service URL from the admission resource. There is no public exploit identified at time of analysis, and the vendor rates the issue 8.3 (High) under CVSS 4.0.
Kyverno 1.14.0 through 1.19.0 fail open in a way that lets unsigned or untrusted container images be admitted to a Kubernetes cluster: the ImageValidatingPolicy evaluator silently ignores the spec.images and spec.allowedValues fields of a PolicyException, so any exception whose policyRefs and matchConditions match a resource disables image signature verification for that entire resource rather than only for the named images or values. An authenticated user with Kubernetes API rights sufficient to deploy or modify workloads covered by such an exception (CVSS PR:L) can therefore bypass signature enforcement without obtaining any new privileges - the flaw simply turns a narrow, trust-anchored carve-out into a blanket exemption. No public exploit code identified at time of analysis, and the vendor has released a fix in Kyverno 1.19.1; scope is limited to clusters that actively enforce signature verification through ImageValidatingPolicy and define matching PolicyExceptions.
Cross-namespace information disclosure in Kyverno 1.16.0 through 1.19.0 lets an authenticated tenant with RBAC permission to create namespaced policy objects read the full cached contents of cluster-scoped GlobalContextEntry resources - including data from namespaces they have no RBAC access to - by invoking globalContext.get() in a CEL policy. The root cause is that the globalcontext.Lib CEL library is registered in the policy environment without the namespace confinement applied to its sibling libraries (resource.Lib, http.Lib, configMap loader), and no admission validation blocks the call. Exploitation requires a multi-tenant cluster with a GlobalContextEntry configured and caching data the tenant cannot otherwise read, so the blast radius is bounded by those preconditions and the flaw is inert on single-tenant clusters or clusters with no GlobalContextEntry; no public exploit identified at time of analysis, and the issue is fixed in Kyverno 1.19.1.
Policy enforcement bypass in Kyverno v1.9.0 through v1.12.7 lets an authenticated Kubernetes user evade an enforce-mode ClusterPolicy when two overlapping PolicyExceptions apply to the same rule, because the less-restrictive exception wins. An attacker who can name a workload to match a permissive exception pattern (for example '*ingress*') can deploy resources the policy was meant to block, such as Pods with hostPath volumes. The vendor GHSA advisory (GHSA-gg4x-fgg2-h9w9) includes working reproduction manifests; there is no CISA KEV listing and no confirmed in-the-wild exploitation.
Server-side request forgery in Kyverno's Kubernetes admission controller (all versions before 1.18.0) enables any authenticated cluster user to redirect the admission controller's privileged HTTP client to cloud metadata endpoints (e.g., AWS IMDS at 169.254.169.254), internal ClusterIP services, and loopback addresses by injecting malicious URLs through JMESPath variable substitution in ClusterPolicy `apiCall.service.url` definitions. Critically, this is non-blind SSRF: response bodies are reflected back to the attacker through admission error messages visible in kubectl output, enabling direct credential and data exfiltration in a single API call. A fully functional proof-of-concept is published in GHSA-qr4g-8hrp-c4rw; no confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Credential leakage in Kyverno's apiCall service mode automatically forwards the Kubernetes admission controller's ServiceAccount bearer token to any external HTTP endpoint referenced in a policy, including attacker-controlled servers. Affecting Kyverno before 1.16.4 (fix version disputed - see confidence notes), this insecure-by-default behavior requires only policy-creation privileges to exploit: a low-privileged user crafts a ClusterPolicy pointing apiCall.service.url at an attacker-controlled host, then triggers a matching admission event, causing Kyverno to self-exfiltrate its SA token. No public exploit is confirmed in CISA KEV, but a working proof-of-concept with full reproduction steps is embedded in the GitHub security advisory GHSA-8wfp-579w-6r25.
Cross-namespace privilege escalation in Kyverno 1.18.0-1.18.1 lets any tenant who can create a NamespacedMutatingPolicy in their own namespace force the cluster-privileged admission controller to generate resources (ConfigMaps, Secrets, NetworkPolicies, RoleBindings) in arbitrary namespaces, including kube-system. The nmpol CEL compiler unintentionally exposes the generator library to matchConditions, and neither the mpol validator nor GenerateResources enforces namespace scope on the generator.apply() target. A working proof-of-concept is published in the vendor advisory (GHSA-79gf-7frw-68m9); there is no KEV listing or evidence of active exploitation, and the issue is fixed in 1.18.2.
A type assertion bug in Kyverno's forEach mutation handler crashes the cluster-wide background controller into CrashLoopBackOff and blocks admission controller operations, causing denial of service for policy-matched resources. Any authenticated user with Policy or ClusterPolicy creation permissions can trigger the crash by creating a malformed policy. The vulnerability affects Kyverno versions prior to 1.17.2 and 1.16.4, is limited to the legacy policy engine (CEL-based policies unaffected), and persists until the malicious policy is deleted. Vendor-released patches available with confirmed fix commits on GitHub.
Kyverno's apiCall feature automatically attaches the admission controller's ServiceAccount token to HTTP requests without validating the destination URL, enabling authenticated attackers to exfiltrate tokens to attacker-controlled servers and achieve full cluster compromise through webhook configuration tampering. Affects Kyverno versions prior to 1.18.0-rc1, 1.17.2-rc1, and 1.16.4. Vendor-released patches available across all three affected version branches. EPSS data not provided, but the vulnerability enables privilege escalation from low-privilege Kubernetes user to cluster admin via token theft, representing critical risk in multi-tenant environments.
Cross-namespace privilege escalation in Kyverno 1.17.x allows authenticated namespace administrators to bypass RBAC controls and read ConfigMaps from any Kubernetes namespace. The vulnerability exploits unvalidated `configMap.namespace` field in Kyverno's ConfigMap context loader, enabling attackers to leverage Kyverno's privileged service account permissions. This is a regression following incomplete fix for CVE-2026-22039, which addressed the same issue in `apiCall` context but missed the ConfigMap loader. Patch available in version 1.17.2. CVSS 7.7 with Changed Scope indicates significant multi-tenant cluster risk; EPSS data not available but the regression nature and RBAC bypass impact warrant immediate patching in multi-tenant environments.
Kyverno versions 1.16.0 and later contain a server-side request forgery vulnerability in unrestricted CEL HTTP functions that allow attackers to make arbitrary HTTP requests from the Kyverno controller, potentially accessing internal services and metadata endpoints. The vulnerability affects Kubernetes clusters running vulnerable Kyverno versions with policies utilizing CEL-based HTTP operations, with no CVSS or EPSS data currently available to quantify severity.
Kyverno versions up to 1.16.3 is affected by allocation of resources without limits or throttling (CVSS 7.7).
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass and unauthorized cluster operations.
Server-side request forgery in Kyverno's APICall feature (all versions before 1.16.2) enables any user holding namespace-level Policy creation rights to weaponize Kyverno's cluster-wide, high-privilege ServiceAccount as a confused deputy - directing it to issue HTTP requests to arbitrary internal endpoints including cloud IMDS at 169.254.169.254. Responses, potentially containing other tenants' database passwords, API keys, and cloud IAM role credentials, are surfaced in the PolicyReport and are readable by the attacking tenant, completely collapsing multi-tenant isolation. No public exploit has been identified at time of analysis, though the attack path is straightforward and the impact in shared Kubernetes clusters is severe.
Server-side request forgery in Kyverno's Service Call feature (versions before v1.13.4) allows any cluster user holding ClusterPolicy creation rights to exfiltrate arbitrary Kubernetes resource data - including Secrets - by directing policy apiCall requests to an attacker-controlled external server. The vulnerability stems from a missing URL validation that permits the apiCall/service block, documented for in-cluster services, to resolve and POST data to internet-accessible endpoints. Publicly available exploit code exists in the form of a working PoC ClusterPolicy published in the GHSA advisory; no active exploitation is confirmed via CISA KEV.
Kyverno is a policy engine designed for cloud native platform engineering teams. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable. Public exploit code available.
Kyverno is a policy engine designed for cloud native platform engineering teams. Rated medium severity (CVSS 5.8), this vulnerability is remotely exploitable. Public exploit code available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 8.7), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. No vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Kyverno is a policy engine designed for Kubernetes. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Kyverno is a policy engine designed for Kubernetes. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
An image signature validation bypass vulnerability in Kyverno 1.8.3 and 1.8.4 allows a malicious image registry (or a man-in-the-middle attacker) to inject unsigned arbitrary container images into a. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. This Improper Authentication vulnerability could allow attackers to bypass authentication mechanisms to gain unauthorized access.