CVE-2026-124440: Kyverno Authorization Bypass

Detection Guidance

Begin with exposure validation:

1. Identify Kyverno versions.
2. Determine which subjects can create namespaced Policy objects.
3. Inspect the admission-controller ServiceAccount’s effective RBAC permissions.
4. Review Kubernetes audit logs for unexpected controller-originated requests.
5. Inspect policies for unusual apiCall paths and percent-encoded sequences.

Pay particular attention to permissions involving:

• Secrets.
• Workload objects.
• Cluster-scoped resources.
• mutatingwebhookconfigurations.
• Other admission-related objects.

Check Kyverno ServiceAccount Permissions

The ServiceAccount name can differ by chart, namespace, or customization. Obtain the actual identity from the Kyverno Deployment before running authorization checks:

kubectl -n kyverno get deploy \
  -o jsonpath='{range .items[*]}{.metadata.name}{" => "}{.spec.template.spec.serviceAccountName}{"\n"}{end}'

Then test its effective permissions:

kubectl auth can-i create policy.kyverno.io \
  --as=system:serviceaccount:kyverno:kyverno

kubectl auth can-i --list \
  --as=system:serviceaccount:kyverno:kyverno

kubectl get clusterrole,clusterrolebinding,role,rolebinding -A \
  -o yaml | grep -n -E \
  'kyverno|mutatingwebhookconfigurations|secrets|apiGroups'

Replace the example ServiceAccount identity if the deployment uses a different name.

Inspect Kyverno Policies

Inspect policies for apiCall, urlPath, percent signs, and unusual escape sequences. The following command is a triage aid, not a complete parser:

kubectl get policy.kyverno.io -A -o yaml |
  grep -n -E 'apiCall|urlPath|%[0-9A-Fa-f]?[^0-9A-Fa-f]|%[^0-9A-Fa-f]'

A stronger approach is to export policies and parse their YAML structure with a policy-aware script. Look for namespaced policies that use context.apiCall, especially where the path contains:

• Encoded separators.
• Incomplete percent escapes.
• Repeated encoding.
• Path components inconsistent with the policy namespace.
• References to cluster-scoped resources.

Kubernetes Audit Detection

Enable or review Kubernetes audit events for requests made by the Kyverno admission-controller ServiceAccount. Useful signals include:

• user.username matching the Kyverno admission-controller ServiceAccount.
• Requests to namespaces other than the policy’s namespace.
• Requests to cluster-scoped endpoints from policy-triggered activity.
• get, list, or watch operations against sensitive resources.
• Creation or modification of mutatingwebhookconfigurations.
• Activity that begins soon after a new Kyverno Policy is created.

A generic audit-log search can establish an initial baseline:

jq -r '
  select(.user.username? | test("system:serviceaccount:kyverno:")) |
  [
    .requestReceivedTimestamp,
    .user.username,
    .verb,
    .objectRef.apiGroup,
    .objectRef.apiVersion,
    .objectRef.resource,
    (.objectRef.namespace // "-"),
    (.objectRef.name // "-"),
    (.responseStatus.code // 0)
  ] | @tsv
' /var/log/kubernetes/audit/audit.log

For SIEM correlation, alert when a Kyverno ServiceAccount:

• Accesses a namespace outside its expected operating scope.
• Requests a cluster-scoped resource.
• Creates or changes a webhook configuration.
• Reads secrets or other privileged resources unexpectedly.

The exact API-server audit fields and log location vary by Kubernetes distribution. Also note that an API request performed by Kyverno may not preserve the original human actor in the Kubernetes audit user field. Correlate controller activity with recent policy writes, admission events, GitOps commits, and identity-provider logs.

A practical detection pattern is:

user.username starts_with "system:serviceaccount:kyverno:"
AND (
  objectRef.resource IN ("mutatingwebhookconfigurations", "validatingwebhookconfigurations")
  OR objectRef.namespace NOT IN approved_policy_namespaces
  OR objectRef.resource IN ("secrets", "clusterroles", "clusterrolebindings")
)

This is a behavioral detection strategy, not a vendor-supplied network signature. The supplied research does not identify a reliable wire-level signature, and URL encoding may be normalized by clients or API proxies before logging.

Remediation and Patching

Upgrade Kyverno to 1.19.2 or later, which is the fixed version identified in the supplied advisory material. Before changing production, review the project’s release notes and deployment method, then test admission behavior in a staging cluster.

Upgrade the controller and associated components consistently rather than replacing only one image in a multi-component installation.

Helm Deployments

First identify the release and repository configuration:

helm list -A | grep -i kyverno
helm repo list
helm search repo kyverno/kyverno --versions | head

After verifying that the repository and chart version correspond to Kyverno 1.19.2 or later, use the project’s documented Helm upgrade procedure. A typical command pattern is:

helm upgrade kyverno kyverno/kyverno \
  --namespace kyverno \
  --reuse-values \
  --version <chart-version-containing-kyverno-1.19.2-or-later> \
  --wait

Replace the placeholder with a verified chart version. The supplied research does not identify a chart-version mapping, so publishing a specific chart number without verification would be unsafe.

Manifest-Based Deployments

For manifest-based deployments, update Kyverno image references to the project’s 1.19.2-or-later release and apply the reviewed manifests:

kubectl apply -f <verified-kyverno-1.19.2-or-later-manifests>
kubectl -n kyverno rollout status deployment

Do not use an unverified URL or image tag in an emergency change. Confirm the deployed image and application version after upgrading:

kubectl -n kyverno get pods \
  -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image,STATUS:.status.phase

Temporary Mitigations

Until the upgrade is complete, remove or restrict the vulnerable capability. The most effective temporary control is to prevent untrusted subjects from creating or modifying Kyverno Policy objects.

Review RoleBindings and ClusterRoleBindings granting create, update, or patch on policies.kyverno.io, and remove unnecessary grants.

Also reduce the Kyverno admission-controller ServiceAccount’s RBAC permissions to the minimum required for deployed policies and features. This is a compensating control, not a replacement for upgrading. Restricting access to cluster-scoped resources, secrets, and admission webhook configuration can reduce impact, but overly aggressive changes may break policy evaluation or admission enforcement.

Post-Upgrade Investigation

After patching, audit for possible prior exploitation:

kubectl get policy.kyverno.io -A -o yaml > kyverno-policies-after-upgrade.yaml

kubectl get mutatingwebhookconfiguration -o yaml \
  > mutating-webhooks-after-upgrade.yaml

kubectl get clusterrole,clusterrolebinding -o yaml \
  > cluster-rbac-after-upgrade.yaml

Compare these objects with known-good configuration and investigate:

• Unexpected policy creation or modification.
• Webhook changes.
• Cross-namespace reads.
• Access to secrets or other sensitive objects.
• New or modified cluster RBAC.
• GitOps changes without an approved change record.
• Kyverno controller activity inconsistent with normal admission processing.

If evidence indicates that the admission-controller identity accessed secrets or changed admission configuration, treat the cluster as potentially compromised. Rotate exposed credentials, review workload and control-plane integrity, and follow the organization’s Kubernetes incident-response process.

References

1. Kyverno GitHub security advisory: GHSA-39w8-hv5g-f73w
2. VulnCheck advisory: Kyverno 1.19.1 privilege escalation via apiCall namespace-clamp bypass
3. Kyverno documentation on external data sources and apiCall
4. Kyverno 1.10 release material describing Kubernetes API calls

The supplied research reports a CVSS v3 base score of 9.9 but does not include the vector string. It also reports that CVE-2026-124440 was not listed in CISA KEV, with no confirmed in-the-wild exploitation or public PoC identified in the reviewed sources. These status fields should be rechecked against authoritative records before using this article as the sole basis for an automated remediation deadline.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.