Kubewarden trusted-repos-policy CVE-2026-63121

Requires trusted-repos-policy before 2.1.2 deployed in a reject-list (deny) configuration; allow-list configurations are NOT affected because they fail closed by over-denying differently cased hostnames. The actor must be able to create or update admission-controlled workloads (pods, deployments, replicasets, statefulsets, daemonsets, jobs, cronjobs, etc.) and specify a container image whose registry portion uses uppercase or mixed-case characters so it misses the equivalently-named lowercase reject rule. Limiting factors: deny-list mode only, the need for workload-submission access to the API server, and an impact bounded by whatever the prohibited image does once the runtime pulls it; the vendor states impact depends on the configured rejection policy and environment.

This is a moderate-severity security-control bypass (input CVSS 6.3), not a directly exploitable code-execution flaw. The input vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L marks it network-reachable and unauthenticated (PR:N), but that overstates reach: triggering the bypass requires an actor able to submit or modify Kubernetes workloads (pods/deployments), which in practice needs RBAC - so treat PR:N as optimistic and 'unauthenticated' as not fully supported by the deployment reality. No EPSS score was provided and the issue is not in CISA KEV, so there is no exploitation-probability or active-exploitation signal; no public exploit identified at time of analysis (the three references are a fix commit, the GHSA advisory, and the 2.1.2 release tree - advisory/patch material, not PoC code). The vuln.today decision label is 'this_month', consistent with patching on a normal maintenance cycle rather than emergency action. The practical risk is bounded and conditional: only reject-list (deny) configurations are bypassable - allow-list configurations fail closed by over-denying - and the vendor explicitly states the confidentiality/integrity/availability impact varies with the configured rejection policy and environment. Net: a real but config-dependent policy-enforcement gap, not a high-urgency widespread-exploitation threat.

In a cluster using trusted-repos-policy (before 2.1.2) configured with a reject list, an actor able to create a workload submits a pod whose image uses an uppercase or mixed-case registry host (for example EVIL-REGISTRY.COM/malware). The policy compares the host case-sensitively, fails to match the lowercase reject entry evil-registry.com, and admits the resource, after which the container runtime normalizes the hostname and pulls the prohibited image. No public exploit identified at time of analysis, but the technique is trivially reproducible from the advisory's own example.