CVE-2026-100706: Kyverno Privilege Escalation
TL;DR - CVE-2026-100706 is a critical Kyverno flaw affecting versions before 1.19.1. - A tenant able to create or modify Kyverno policies may bypass namespace restrictions and trigger privileged object creation. - Upgrade to Kyverno 1.19.1 or later and audit policies, RBAC, and Kubernetes activity immediately.
Summary
CVE-2026-100706 is a critical Kyverno privilege escalation vulnerability affecting Kyverno versions before 1.19.1. The flaw results from inadequate validation of URL-encoded path segments in the Policy resource’s apiCall.urlPath field. A namespace tenant may use encoded directory-traversal sequences to evade Kyverno’s intended per-namespace restriction.
The practical risk is substantial because the Kyverno admission controller processes the resulting API request using its ServiceAccount permissions. Depending on the installation’s RBAC configuration, successful exploitation could allow creation of objects in other namespaces or at cluster scope. The described impact includes cluster-wide MutatingWebhookConfiguration objects and PolicyException objects in the Kyverno namespace, potentially leading to cluster-admin-level control.
Organizations reviewing the issue should also assess related Kubernetes broken access control risks and verify that policy administration follows a documented CI/CD security hardening checklist.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-100706 |
| CVSS base score | 9.9 Critical |
| Attack vector | Not provided in the reviewed NVD response |
| Authentication or authorization required | An attacker must be able to create or modify Kyverno policies; the formal CVSS authorization component was not provided |
| Affected versions | Kyverno before 1.19.1 |
| Fixed version | Kyverno 1.19.1 or later |
| Patch available | Yes |
| CISA KEV | No, on_kev: false |
The available record does not include the complete CVSS vector. The attack vector and authorization components should not be inferred from the 9.9 score. Defenders should use the demonstrated attack prerequisite, namely policy creation or modification access, when assessing exposure.
Root Cause
The root cause is insufficient validation and normalization of URL-encoded path segments supplied through Kyverno Policy resources. Kyverno applies a namespace “clamp” intended to keep API calls within the policy’s permitted namespace. Encoded directory-traversal sequences can bypass that boundary when the path is interpreted downstream.
This is a path-handling issue rather than a conventional Kubernetes API authentication bypass. Kyverno’s admission controller remains the identity making the API request, but an attacker can influence the requested path so that the controller targets a different namespace or a cluster-scoped endpoint. The security boundary fails because validation does not reliably account for encoded traversal semantics before the request is issued.
The impact depends on the permissions granted to the Kyverno admission-controller ServiceAccount. Broad permissions increase the blast radius. In the described attack path, an attacker may cause creation of MutatingWebhookConfiguration resources across the cluster or create PolicyException objects in the Kyverno namespace. Those actions can alter admission behavior, weaken policy enforcement, or provide a path toward broader Kubernetes privilege escalation.
Who’s Exposed
The directly affected product is Kyverno. Based on the available vulnerability record, all Kyverno versions before 1.19.1 should be treated as affected. The supplied data does not identify a narrower lower bound, so operators should not assume that only recent 1.x releases are vulnerable. The fixed release is Kyverno 1.19.1, and later releases are the stated remediation target.
Exposure is highest where untrusted or semi-trusted namespace tenants can create or modify Kyverno Policy resources. Multi-tenant clusters, platform-as-a-service environments, and clusters delegating policy administration to application teams should receive priority. A deployment may still be exposed even when tenants cannot directly edit cluster-wide policies if they can manipulate namespace-scoped policies processed by Kyverno.
Inventory all Kyverno components rather than checking only a Helm values file. Verify the running controller image, deployment revision, Helm release values, and any separate background, cleanup, or reporting components. The critical question is whether the admission-controller workload actually runs a release earlier than 1.19.1.
Severity Breakdown
The assigned CVSS base score is 9.9, rated Critical. That score reflects the potential for a relatively constrained namespace-level actor to cause privileged Kubernetes API operations through an admission-controller identity. The consequence can extend beyond one namespace because the attack can target cluster-scoped objects or resources in privileged namespaces.
The full CVSS vector was not returned in the NVD response used for this assessment. Therefore, the formal values for attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability must be obtained from the authoritative CVE record or vendor advisory before being reproduced. In particular, do not infer a network attack vector or a specific privileges-required value solely from the 9.9 score.
Operationally, the severity is driven by three factors: policy write access may be available to a namespace tenant, Kyverno performs the resulting request, and the target resources can affect admission control or policy exceptions. Even if the Kyverno ServiceAccount is more restricted than the default installation, the issue should be treated as a critical control-plane exposure until permissions and deployed versions are verified.
Analyst’s Take: The first triage question is whether any tenant or other untrusted identity can write Kyverno policies, followed by whether the admission-controller ServiceAccount can affect cluster-scoped or privileged namespace resources. The 9.9 score signals the potential impact, but the reviewed NVD response does not provide the complete CVSS vector, so exposure decisions should rely on the documented policy-write prerequisite and the cluster’s actual RBAC configuration.
Exploitation Status
CVE-2026-100706 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time represented by the supplied research. The available CISA result was on_kev: false; no CISA due date, required action, or ransomware-campaign designation applies. KEV absence is not evidence that exploitation has never occurred.
The reviewed material did not establish confirmed exploitation in the wild. It also did not independently confirm a separate public exploit repository or a reliable public proof of concept. The Kyverno GitHub security advisory may include reproduction details, so defenders should review it directly. The appropriate current classification is:
| Exploitation question | Status |
|---|---|
| CISA KEV listing | No |
| Confirmed in-the-wild exploitation | Not established from reviewed sources |
| Independently confirmed public PoC | Not established from reviewed sources |
| Technical reproduction material | May be present in the Kyverno advisory; verify directly |
Organizations should not downgrade urgency because exploitation is unconfirmed. A vulnerability that can convert policy-write access into control-plane impact warrants rapid remediation, especially in shared Kubernetes environments.
Sources
The primary vulnerability record is the NVD entry for CVE-2026-100706. It identifies Kyverno versions before 1.19.1 as affected and describes the encoded path traversal issue in Policy apiCall.urlPath.
The vendor-associated technical reference is the Kyverno GitHub Security Advisory GHSA-5qq8-67g6-4h2w. Review the advisory for the vendor’s implementation details, release guidance, and any reproduction material before finalizing detection content.
Additional context is available from the VulnCheck advisory, which describes the privilege-escalation path involving apiCall.urlPath. CISA status should be checked against the Known Exploited Vulnerabilities Catalog during incident triage because exploitation status can change after publication.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Begin by identifying every Kyverno Policy containing an apiCall rule and reviewing its urlPath value. Look for percent-encoded traversal indicators such as %2e, %2E, %2f, %2F, or combinations that decode to ../. Also investigate policies that reference API paths outside their expected namespace or that were created or modified by identities that are not part of the platform security team.
Review Kubernetes audit logs for requests made by Kyverno ServiceAccounts that cross namespace boundaries or target cluster-scoped admission resources. The exact ServiceAccount name varies by deployment, so first identify it from the Kyverno admission-controller Deployment. A baseline query using jq can help locate suspicious requests:
kubectl get events -A --field-selector type=Warning -o json \
| jq -r '.items[] | [.lastTimestamp, .involvedObject.namespace,
.involvedObject.kind, .involvedObject.name, .message] | @tsv'
For audit logs stored as JSON Lines, search for high-risk Kyverno-generated operations:
jq -c '
select(
(.user.username | test("kyverno"; "i")) and
(
(.objectRef.resource == "mutatingwebhookconfigurations") or
(.objectRef.resource == "policyexceptions") or
(.objectRef.namespace != null)
)
)
| {
timestamp: .requestReceivedTimestamp,
user: .user.username,
verb: .verb,
namespace: .objectRef.namespace,
resource: .objectRef.resource,
name: .objectRef.name,
uri: .requestURI,
response: .responseStatus.code
}
' /var/log/kubernetes/audit/audit.log
The key patterns are Kyverno identities creating or modifying mutatingwebhookconfigurations, creating policyexceptions in the Kyverno namespace, or creating objects in namespaces unrelated to the triggering policy. A single match is not proof of exploitation because Kyverno may legitimately manage some resources, but unexpected actor, namespace, or timing combinations should trigger investigation.
Remediation Steps
Upgrade Kyverno to 1.19.1 or later. Confirm the version running in the cluster after the change:
kubectl -n kyverno get deploy -o custom-columns=NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image
kubectl -n kyverno get pods -o wide
If Kyverno was installed with Helm, use the organization’s existing Kyverno chart and values, selecting a chart release that deploys application version 1.19.1 or later:
helm repo update
helm upgrade <release-name> <kyverno-chart> \
--namespace kyverno \
--reuse-values \
--set image.tag=v1.19.1
The release name, chart name, and image configuration key can differ by chart version. Validate the rendered manifest before applying it, and confirm the resulting image rather than assuming that a Helm chart version numerically matches the Kyverno application version. Do not consider the upgrade complete until all admission-controller replicas run the fixed release.
If emergency remediation requires rotating shared administrator or deployment credentials, use an approved password manager such as Try 1Password → rather than placing secrets in shell history, tickets, or chat messages.
If an immediate upgrade is impossible, remove or restrict the ability of namespace tenants to create or modify Kyverno Policy resources. Review RBAC bindings for policies.kyverno.io and remove unnecessary write permissions. Also review the Kyverno admission-controller ServiceAccount and reduce permissions that are not required for the organization’s policy set. These controls reduce exposure but are not a substitute for the fixed release.
As a temporary containment measure, suspend or remove untrusted apiCall policies after assessing enforcement impact, and use admission controls or policy review workflows to block new policies containing encoded traversal sequences. Avoid relying only on string matching because encoded paths can have multiple representations. Preserve affected policies, audit logs, controller logs, webhook configurations, RBAC objects, and PolicyExceptions before cleanup if compromise is suspected.
After remediation, inspect all MutatingWebhookConfiguration objects, Kyverno PolicyException resources, ClusterRoles, RoleBindings, ServiceAccounts, and recently changed policies. Any unexplained cluster-wide admission change should be handled as a potential Kubernetes cluster compromise rather than as a routine configuration error.