CVE-2026-42541: Kubewarden Information Disclosure Flaw

CVE-2026-42541 Overview

CVE-2026-42541 is a missing authorization vulnerability [CWE-862] in Kubewarden, a policy engine for Kubernetes. The flaw resides in the can_i host callback exposed to policy authors. An attacker with privileged AdmissionPolicy or AdmissionPolicyGroup create permissions can craft a policy that invokes can_i to issue arbitrary SubjectAccessReview (SAR) requests using policy-server privileges. The callback fails to enforce the context-aware allow-list, allowing reconnaissance of RBAC permissions for any user or service account across the cluster.

Critical Impact

Authenticated attackers with policy create permissions can enumerate cluster-wide RBAC permissions, learning whether specific identities can perform sensitive actions such as get secrets, create pods, or bind clusterroles.

Affected Products

• Kubewarden policy engine for Kubernetes
• Kubewarden adm-controller component
• Kubewarden policy-server

Discovery Timeline

• 2026-05-12 - CVE-2026-42541 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42541

Vulnerability Analysis

Kubewarden allows policies to query the cluster for contextual data through host callbacks. The can_i callback is designed to evaluate whether a subject can perform an action, mirroring the behavior of kubectl auth can-i. Policies must declare context-aware resource grants to use such callbacks, and the host should enforce those grants before issuing API calls on behalf of the policy.

The vulnerable code path does not enforce the context-aware allow-list check for can_i. Instead, it forwards the request directly to the callback handler, which executes a real SubjectAccessReview request against the Kubernetes API using the policy-server's service account credentials. Because policy-server typically holds broad permissions to perform SARs, the policy gains the ability to enumerate authorization decisions for any subject in any namespace.

The issue is classified as information disclosure and reconnaissance. The attacker does not directly read secrets or workload data through this flaw. They learn which identities possess which permissions, which is valuable for planning lateral movement and privilege escalation within the cluster.

Root Cause

The root cause is a missing authorization check [CWE-862] in the policy host callback dispatcher. The can_i callback bypasses the validation logic that enforces the policy's declared context-aware resources, creating a policy-level authorization gap.

Attack Vector

Exploitation requires an authenticated principal with permissions to create AdmissionPolicy or AdmissionPolicyGroup resources, which is not the default in most clusters. The attacker writes or deploys a malicious policy that calls can_i with chosen subjects, verbs, resources, and namespaces. When Kubewarden evaluates the policy, the policy-server submits SAR requests on the attacker's behalf and returns the authorization decisions to the policy logic. The attacker then exfiltrates the enumerated permission map through policy outputs or logs. See the GitHub Security Advisory GHSA-wqcw-g35j-j578 for technical details.

Detection Methods for CVE-2026-42541

Indicators of Compromise

• Unexpected SubjectAccessReview API calls originating from the Kubewarden policy-server service account at high volume or across many namespaces.
• Newly created AdmissionPolicy or AdmissionPolicyGroup resources from non-administrative identities, particularly those referencing untrusted policy module sources.
• Policy-server logs showing can_i host callback invocations against subjects unrelated to the policy's documented purpose.

Detection Strategies

• Audit Kubernetes API server logs for SubjectAccessReview create events tied to the policy-server service account and correlate with policy deployment events.
• Inventory all installed Kubewarden policies and review their source modules for can_i callback usage against unexpected subjects or resources.
• Monitor RBAC changes that grant admissionpolicies.policies.kubewarden.io or admissionpolicygroups.policies.kubewarden.io create verbs to non-admin principals.

Monitoring Recommendations

• Enable Kubernetes audit logging at the Metadata level for authorization.k8s.io/v1 resources and ship logs to a centralized analytics platform.
• Baseline normal policy-server SAR request volume and alert on statistically significant deviations.
• Track creation, modification, and deletion of Kubewarden policy resources as security-relevant events.

How to Mitigate CVE-2026-42541

Immediate Actions Required

• Upgrade Kubewarden components to the patched releases referenced in the vendor advisory.
• Restrict RBAC permissions for creating AdmissionPolicy and AdmissionPolicyGroup resources to trusted cluster administrators only.
• Review existing policies for unexpected can_i callback usage and remove or replace untrusted policies.

Patch Information

The vulnerability is fixed in updated Kubewarden releases. Refer to the Kubewarden GitHub Security Advisory GHSA-wqcw-g35j-j578 for the specific fixed versions and upgrade instructions for the adm-controller and policy-server components.

Workarounds

• Limit policy creation permissions to a small set of trusted operators using strict RBAC bindings until the patch is deployed.
• Run policy-server with the minimum service account privileges required, reducing the scope of any SAR enumeration.
• Source Kubewarden policies only from trusted, signed registries and validate policy module contents before deployment.

# Configuration example: restrict policy creation via RBAC
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq '.items[] | select(.roleRef.name | test("kubewarden|admin"))'

# Audit current AdmissionPolicy resources for can_i usage
kubectl get admissionpolicies,admissionpolicygroups --all-namespaces -o yaml | \
  grep -i 'can_i\|subjectaccessreview'