CVE-2026-41485
Kyverno 1.13.0 – 1.16.4
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:HSummary
CVE-2026-41485 is a high-severity Reachable Assertion (CWE-617) vulnerability in Kyverno Kyverno. Its CVSS base score is 7.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 30th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-41485 is a vulnerability in Kyverno, a policy engine for cloud native platform engineering teams, affecting versions prior to 1.17.2 and 1.16.4. It stems from an unchecked type assertion in the `forEach` mutation handler within the legacy engine, which can be triggered by specially crafted `Policy` or `ClusterPolicy` resources. CEL-based policies remain unaffected. The issue carries a CVSS v3.1 score of 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H) and is associated with CWE-617.
An attacker with permissions to create a `Policy` or `ClusterPolicy` can exploit this remotely over the network with low complexity. Successful exploitation crashes the cluster-wide background controller into a persistent CrashLoopBackOff state and causes the admission controller to drop connections, blocking all matching resource operations until the malicious policy is deleted. This results in high-impact availability disruption across the cluster scope with no confidentiality or integrity effects.
Mitigation is available via upgrades to Kyverno versions 1.17.2 or 1.16.4, which address the type assertion flaw through fixes detailed in GitHub commits 76c8fdbe87328722e099e1fd44c3f21c9f7809cb and 80e728c2283a0c65e5adb02d8a907106e6ebe7e3. The official advisory at GHSA-fpjq-c37h-cqcv provides further details on the patch and verification steps.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25392
Vulnerability Data
Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to versions 1.17.2 and 1.16.4, an unchecked type assertion in the `forEach` mutation handler allows any user with permission to create a `Policy` or `ClusterPolicy` to crash…
more
the cluster-wide background controller into a persistent CrashLoopBackOff. The same bug also causes the admission controller to drop connections and block all matching resource operations. The crash loop persists until the policy is deleted. The vulnerability is confined to the legacy engine, and CEL-based policies are unaffected. Versions 1.17.2 and 1.16.4 fix the issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation finds reachable assertions during development.
Security engineering principles discourage use of assertions for handling untrusted input.
Validating untrusted inputs structurally prevents attacker data from reaching and triggering assertions.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent unsafe assertions from being coded in reachable paths.
Runtime monitoring of software can detect assertion-triggered crashes as adverse events.
Vulnerability identification processes can discover and record reachable-assertion flaws before deployment.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect reachable assertions before release, reducing the likelihood of exploitation.
Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.
Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.
Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.