Kubewarden Policy Engine CVE-2026-42541

Exploitation requires two preconditions: (1) Cluster operator has explicitly granted a user or service account permission to create AdmissionPolicy or AdmissionPolicyGroup resources in one or more namespaces (this is non-default); (2) The cluster runs Kubewarden version earlier than 1.35.0. Additionally, if the PolicyServer ServiceAccount lacks broad Kubernetes RBAC permissions, the enumeration scope is limited to subjects and actions within the PolicyServer's own RBAC permissions-the vulnerability does not grant new RBAC permissions but exposes existing ones. The can_i callback requires network access to the Kubernetes API from within the policy-server pod (standard in Kubernetes). No user interaction is needed; the malicious policy executes automatically during admission control. The vulnerability is exploitation-ready once a policy is deployed; no special Kubernetes feature flags or non-default configurations are required beyond the initial grant of policy creation permissions.

The CVSS v3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects a low-severity information disclosure with network accessibility but requiring low privileges. EPSS data is not provided; however, the risk assessment aligns with the CVSS rating: this is a reconnaissance vulnerability with confidentiality impact only. The attack requires prior privilege grant (AdmissionPolicy/AdmissionPolicyGroup creation permissions), which is non-default, reducing the immediate threat surface. No CISA KEV status or public exploit code is indicated in the data. The real-world risk depends critically on deployment posture-organizations granting unprivileged users policy creation rights without the v1.35.0 mitigation (PolicyServer capability restrictions) face reconnaissance-level exposure. Unlike direct privilege escalation or data exfiltration vulnerabilities, this enables attackers to probe RBAC configurations to identify high-value service accounts (e.g., those with 'get secrets' or 'create pods' permissions), informing follow-up exploitation. The low CVSS score understates organizational risk if attacker reconnaissance directly leads to further lateral movement; however, the vulnerability itself does not grant unauthorized actions, only visibility into existing permissions.

A cluster operator grants namespace developers permission to create AdmissionPolicies in their namespace to enforce custom validation rules. An attacker with that role crafts a malicious policy containing a can_i call querying whether the 'default' ServiceAccount can 'get secrets' in all namespaces. The policy-server evaluates this call using its own elevated ServiceAccount (e.g., kubewarden-policy-server), which has broad RBAC permissions, and returns permission results without authorization checks. The attacker learns which namespaces expose secret access, then exploits a separate vulnerability (e.g., lateral movement via a compromised pod) to access those secrets.