CVE-2026-63121 in policies
Summary
by MITRE • 10/31/2026
Kubewarden policies is a collection of WebAssembly policies for securing and governing Kubernetes clusters. For versions provisionally classified as affected before 2.1.2, `trusted-repos-policy` compares an image's `registry` hostname against `reject lists` and `allow lists` case-sensitively even though `registry` DNS names are case-insensitive. An image with an uppercase or mixed-case `registry` hostname can miss a rejection rule for the equivalent lowercase host, so the admission policy accepts a resource whose container runtime pulls the same prohibited image. Only reject-list configurations have this bypass: allow-list configurations fail closed by over-denying differently cased hostnames. The security consequences depend on the configured rejection policy and deployment environment. This issue is fixed in version 2.1.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
Kubewarden serves as a critical component in modern Kubernetes security architectures, providing extensible admission control through WebAssembly-based policies that govern cluster behavior. Within this ecosystem, the trusted-repos-policy plays a vital role in enforcing image integrity by validating container registries against predefined allow and reject lists. However, versions prior to 2.1.2 contain a significant logical flaw where the policy engine performs case-sensitive string comparisons when evaluating registry hostnames against these configured lists. This implementation oversight fails to account for the fundamental DNS specification which dictates that domain names are inherently case-insensitive, leading to inconsistent security enforcement depending on how image references are formatted in deployment manifests or container runtimes.
The technical root cause of this vulnerability lies in the direct string matching logic used by the policy engine without normalizing input data before comparison. When a user configures a reject list containing lowercase registry hostnames such as docker.io, an attacker can bypass this restriction by referencing images using uppercase characters like Docker.IO or mixed-case variations like DoCkEr.Io. Because the policy treats these strings as distinct entities rather than equivalent identifiers, it fails to trigger the rejection rule for the prohibited image. Consequently, the admission controller approves the resource creation request, allowing a container with a potentially malicious or unapproved image to be scheduled and pulled by the node's runtime environment. This bypass is specific to reject-list configurations; allow-list policies exhibit fail-closed behavior where mismatched casing results in denial of service for legitimate workloads rather than security breaches, making this issue primarily a risk for organizations relying on negative constraints to block known bad actors or untrusted sources.
From an operational perspective, the impact of this vulnerability is contingent upon the specific security posture and deployment environment of the affected cluster. For environments that rely heavily on strict image signing and provenance verification via reject lists, this flaw effectively nullifies a layer of defense against supply chain attacks. An adversary with access to create workloads in the namespace could pull images from prohibited registries by simply altering the case of the hostname, thereby evading detection mechanisms designed to prevent unauthorized software execution. This aligns with CWE-20 Improper Input Validation and CWE-798 Use of Hard-coded Credentials if the registry credentials are also mishandled due to similar casing issues, though primarily it represents a logic error in access control enforcement. In terms of MITRE ATT&CK framework mappings, this vulnerability facilitates lateral movement or initial access by allowing unauthorized container images to be deployed, potentially serving as an entry point for further exploitation within the cluster if those images contain vulnerabilities or malware.
To mitigate this risk and ensure robust security governance, organizations must upgrade Kubewarden policies to version 2.1.2 or later where the case-sensitivity issue has been resolved through proper hostname normalization before list comparison. Until the update is applied, administrators should implement compensating controls such as using admission controllers that enforce lowercase registry names in all deployment manifests or leveraging network-level restrictions to block traffic to prohibited registries regardless of casing variations. Additionally, auditing existing policies for reliance on case-sensitive reject lists and transitioning them to normalized comparisons can help maintain security integrity during the transition period. Regular updates to container orchestration components are essential to address such logical flaws that undermine the intended security boundaries of Kubernetes clusters.