Topic starter
10/06/2026 12:11 am
TL;DR: A critical SSRF in Kyverno 1.16.0 and later lets namespace-scoped policy authors make arbitrary HTTP requests from the admission controller pod, bypassing Kubernetes RBAC and exposing internal services and cloud metadata, according to Orca Security. Namespace isolation collapses when policy evaluation can reach network destinations the author cannot.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Kyverno SSRF: Breaking Kubernetes Namespace Isolation (CVE-2026-4789)”.
By the numbers:
- Kyverno versions 1.16.0 and later are affected.
- The disclosure timeline shows CVE-2026-4789 was assigned on 2026-03-24.
Key questions
Q: What breaks when namespace-scoped policies can trigger outbound HTTP from a controller?
A: Namespace scoping stops describing the real blast radius.
Q: Why does this kind of SSRF create cloud credential risk instead of just internal data exposure?
A: Cloud metadata services often authenticate by network reach rather than user identity, so a pod that can contact them may retrieve temporary credentials or tokens.
Q: What are the signs that a policy engine is becoming an SSRF target?
A: Watch for policies that can resolve URLs, outbound requests from control-plane pods, and reflected response data in validation errors or logs.
Practitioner guidance
- Restrict egress from admission controllers Allow Kyverno pods to reach only the Kubernetes API server and explicitly approved external services.
- Block cloud metadata destinations Prevent all pods that do not require instance credentials from reaching 169.254.169.254 and provider metadata services.
- Review namespaced policy creation rights Audit who can create NamespacedValidatingPolicy and NamespacedDeletingPolicy objects, then remove HTTP-capable policy constructs where namespace administrators do not need outbound fetch functions.
Bottom line: A namespace-scoped policy engine becomes risky when policy evaluation can drive network requests from a privileged controller pod.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
11/06/2026 1:53 am
Namespace-scoped policy is not the same thing as namespace-scoped effect: this breach worked because the governance model assumed delegated policy authors could only influence their own namespace. That assumption failed when policy execution moved into the Kyverno admission controller pod, which had broader network reach than the author. The implication is that platform teams must stop treating policy delegation as a purely logical boundary and recognise the controller’s egress as part of the trust model.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Who is accountable when a delegated policy engine leaks internal or cloud data?
A: Accountability sits with the team that owns the controller, the platform network rules, and the delegation model together. Namespace admins may author the policy, but they do not control the runtime privilege of the admission controller. That is why control-plane governance, network policy, and RBAC must be reviewed as one boundary.
👉 Read our full editorial: Kyverno SSRF breaks namespace isolation and exposes cloud credentials
12/06/2026 3:27 am
Namespace delegation is not a security boundary when policy logic can issue network requests. The article shows that the authorisation boundary remains in Kubernetes RBAC while the execution boundary shifts to the admission controller pod. That split means the real privilege holder is the component executing the request, not the user defining the policy. Practitioners should treat any delegated policy system with outbound fetch capability as a privileged proxy, not as a simple namespaced control.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: Who is accountable when delegated policy authorship can reach beyond namespace scope?
A: The accountable team is the one that owns the policy engine runtime, its egress boundaries, and the permissions granted to delegated policy authors. Namespace scoping alone is not enough if the controller can make network calls that bypass the author’s intended trust boundary.
👉 Read our full editorial: Kyverno SSRF breaks namespace isolation and exposes cloud credentials
This post was modified 18 hours ago by NHI Mgmt Group