|
| 1 | +--- |
| 2 | +title: "Not affected by cross-ns privilege escalation via policy api call" |
| 3 | +authors: |
| 4 | + - Víctor Cuadrado Juan |
| 5 | +date: 2026-02-16 |
| 6 | +--- |
| 7 | + |
| 8 | +## Why Kubewarden is not affected by CVE-2026-22039 |
| 9 | + |
| 10 | +The recent vulnerability |
| 11 | +[CVE-2026-22039](https://nvd.nist.gov/vuln/detail/cve-2026-22039) is doing the |
| 12 | +rounds in the Kubernetes security community, with dramatic titles such as _"How |
| 13 | +an admission controller vulnerability turned Kubernetes namespaces into a |
| 14 | +security illusion"_. You can read about people doubting admission |
| 15 | +controllers, claiming they have too much power, or they represent too high a value |
| 16 | +target. |
| 17 | + |
| 18 | +In this blogpost, we reassure Kubewarden users that they aren't affected |
| 19 | +thanks to our architecture, and explain why. |
| 20 | + |
| 21 | +In those admission controllers that are vulnerable, users with permissions to create |
| 22 | +namespaced policies can manipulate the admission controller into accessing or |
| 23 | +modifying resources outside their intended scope, effectively bypassing |
| 24 | +namespace boundaries and undermining cluster security. You could deploy a badly |
| 25 | +configured policy in your own namespace (or an attacker could), and through that, you |
| 26 | +have access to all resources in the cluster. This is why this CVE is marked |
| 27 | +with a CVVS score of _9.9_ (CRITICAL) over 10. |
| 28 | + |
| 29 | +*Kubewarden is not affected by this vulnerability.* |
| 30 | + |
| 31 | +From the very beginning, we designed our architecture to prevent such privilege |
| 32 | +escalations: |
| 33 | + |
| 34 | +- Namespaced admission policies in Kubewarden are strictly confined: they |
| 35 | + cannot access cluster-wide data or resources outside their namespace. Users |
| 36 | + can add namespaced policies to police their own namespace, but they keep being |
| 37 | + confined by Kubernetes. This is part of our "persona" approach for Kubewarden; |
| 38 | + different personas, different permissions and constraints. |
| 39 | + |
| 40 | +- Only cluster-wide policies, intended for highly privileged users such as |
| 41 | + cluster operators, can request broader access. Even then, their capabilities |
| 42 | + are tightly controlled and must be explicitly granted by the cluster operator. |
| 43 | + |
| 44 | + This is implemented via our [context-aware policies feature](https://docs.kubewarden.io/explanations/context-aware-policies). |
| 45 | + Specifically: |
| 46 | + - The cluster operator must list the policy capabilities under |
| 47 | + `spec.contextAwareResources`, for example "read access to Secrets, ConfigMaps". |
| 48 | + - The cluster operator must schedule the policy, using `spec.PolicyServer`, |
| 49 | + in a PolicyServer that uses a ServiceAccount with enough permissions for |
| 50 | + those capabilities. |
| 51 | + |
| 52 | +- The default PolicyServer ServiceAccount only has read permissions for |
| 53 | + Namespaces, Pods, Services, and Ingresses. See the kubewarden-controller Helm |
| 54 | + chart `values.policyServer.permissions`. Cluster operators configure and |
| 55 | + deploy PolicyServers consciously and explicitly. |
| 56 | + |
| 57 | +- All violation attempts are logged by their PolicyServer. |
| 58 | + |
| 59 | +We like to compare our context-aware feature to Android or iPhone app |
| 60 | +permissions. Permissions are explicit, per policy, reviewed and logged. |
| 61 | + |
| 62 | +This architecture compounds with our policies being run in WebAssembly hosts. |
| 63 | +The defense-in-depth approach ensures that namespace isolation is preserved and |
| 64 | +that no policy can overstep its intended boundaries, regardless of user intent |
| 65 | +or policy configuration. |
| 66 | + |
| 67 | +Our commitment to secure defaults and explicit privilege boundaries is core to |
| 68 | +Kubewarden’s philosophy. We encourage users and operators to review our |
| 69 | +[documentation](https://docs.kubewarden.io/) for further details on policy |
| 70 | +permissions and security best practices. |
0 commit comments