🚨 [KUBERNETES SECURITY] — NEW KYVERNO FLAWS CAN LEAK ITS HIGH-PRIVILEGE SERVICEACCOUNT TOKEN AND TURN THE POLICY ENGINE INTO AN SSRF PROXY CVE-2026-84195 can expose Kyverno's own Kubernetes ServiceAccount token to an attacker-controlled endpoint, while CVE-2026-84199 can make Kyverno query internal resources — potentially including cloud metadata services — using its cluster-level privileges. CyberSignal Priority: 🔴 VERY HIGH 📅 Published: September 1, 2026 🆔 CVE-2026-84195 · CVE-2026-84199 🎯 Kyverno · Kubernetes ⚠️ CVSS 3.1: 7.7 HIGH 🏷️ Kubernetes · Cloud Security · SSRF · Credential Theft · IAM A Kubernetes policy engine is supposed to enforce: **what workloads are allowed to do.** These flaws can potentially make that same privileged component: **do things for the attacker.** ### 🔎 What happened Two newly published Kyverno vulnerabilities affect its: `apiCall` functionality. The first: ### CVE-2026-84195 Kyverno versions before: **1.16.4** can automatically attach the admission controller's: **ServiceAccount token** to outbound HTTP requests made through `apiCall`. If an attacker can control the destination URL: Kyverno sends request ↓ request reaches attacker-controlled server ↓ Kyverno credential can be exposed ↓ attacker obtains high-value Kubernetes identity. The published advisory warns this could potentially allow control over: Kyverno policies and cluster resources. ### ⚔️ Attack chain — credential leak Attacker has permission to create/modify applicable policy ↓ Malicious `apiCall` destination configured ↓ Kyverno performs outbound HTTP request ↓ Kyverno ServiceAccount token attached ↓ Request reaches attacker-controlled endpoint ↓ Token captured ↓ Kyverno identity potentially impersonated ↓ Cluster resources/policies targeted This is essentially: **credential exfiltration through a trusted security component.** ### 🔎 CVE-2026-84199 The second flaw is an: **SSRF — Server-Side Request Forgery.** Affected: Kyverno before **1.16.2**. The URL used by `ServiceCall` isn't sufficiently restricted. A namespace-level user capable of creating Policies can potentially instruct Kyverno to request: internal services ↓ other tenant resources ↓ cloud metadata endpoints. A particularly important example is: `169.254.169.254` —the link-local address commonly associated with cloud-instance metadata services. ### ⚔️ Attack chain — SSRF Attacker gains namespace-level Policy creation permission ↓ Crafted `ServiceCall` URL supplied ↓ Kyverno receives policy ↓ Kyverno makes request using trusted cluster context ↓ Internal resource becomes reachable ↓ Response returned through PolicyReport ↓ Secrets / metadata / IAM credentials potentially exposed. This is a classic: ### **Confused Deputy** The attacker can't directly reach something. But Kyverno can. So the attacker convinces: **Kyverno to reach it for them.** ### 🎯 What is affected This matters particularly in: multi-tenant Kubernetes managed Kubernetes cloud-native platforms shared developer clusters. Kyverno often has elevated permissions because it needs to inspect and enforce policies across: pods deployments namespaces images security contexts admission requests. That makes its own identity: **high value.** ### 🧠 Why this matters Cloud-native security tools frequently receive broad privileges because they need visibility over: everything. But that creates an inversion: security control compromised ↓ privileged identity exposed ↓ security control becomes attacker infrastructure. The same principle applies to: admission controllers CNAPP agents CI/CD runners service meshes cluster operators. A defensive tool can become one of the most valuable identities in the environment. ### ⚠️ Important caveat Neither vulnerability is: **unauthenticated internet RCE.** CVE-2026-84199 requires a user capable of creating applicable Policies at namespace level. CVE-2026-84195 similarly depends on access to the `apiCall` functionality. So this is primarily dangerous when an attacker already has: some Kubernetes permissions but should NOT have: cluster-wide privileges. There is currently no verified evidence in the reviewed sources of: active exploitation in the wild. ### 🛡️ Defender action Kyverno operators should prioritize upgrading beyond the affected versions. For CVE-2026-84195: **Kyverno ≥ 1.16.4** For CVE-2026-84199: **Kyverno ≥ 1.16.2** Also: restrict who can create Policies ↓ restrict `apiCall` usage ↓ block unnecessary access to cloud metadata endpoints ↓ apply Kubernetes NetworkPolicies ↓ audit Kyverno outbound connections ↓ review ServiceAccount permissions ↓ rotate tokens/credentials if exposure is suspected. Especially review whether namespace-level tenants can indirectly cause privileged controllers to connect to: arbitrary URLs. ### 🧠 CyberSignal insight **In Kubernetes, the most dangerous identity may not belong to an administrator — it may belong to the security controller trusted to police everyone else.** Sources: Kyverno Security Advisories · VulnCheck · CVE/MITRE
Post summary
The advisory discloses two Kyverno CVEs that enable credential leakage and SSRF, offers upgrade and mitigation guidance, and notes the absence of evidence for active exploitation.