Notifications
Clear all
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.
NHIMG editorial — based on content published by Orca Security: Kyverno SSRF vulnerability in policy evaluation and namespace isolation
By the numbers:
- A critical SSRF vulnerability affects Kyverno versions 1.16.0 and later.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
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 do admission controllers make SSRF more dangerous than ordinary application SSRF?
A: Admission controllers run inside the trust boundary of the cluster and often have broad egress.
Q: How do security teams know whether a policy engine can be abused for cloud credential theft?
A: Look for any feature that lets policy logic call external URLs, then test whether the controller can reach link-local metadata addresses or internal service DNS names.
Practitioner guidance
- Review policy engines for outbound request primitives Inventory admission controllers and policy systems that expose HTTP helpers, external data lookups, or templated network calls.
- Restrict egress from Kyverno and similar controllers Apply network policy, firewall rules, or cloud-level controls so controller pods can only reach the Kubernetes API server and explicitly approved destinations.
- Separate namespace delegation from network privilege Revisit any assumption that namespace-scoped policy authorisation is safe if the controller executing it can leave the namespace.
What's in the full article
Orca Security's full report covers the operational detail this post intentionally leaves for the source:
- The full PoC walk-through showing how a namespaced policy can exfiltrate data through Kyverno admission processing.
- The exact detection queries for finding http.Get and http.Post usage across Kyverno policy objects.
- The remediation timeline, including the merged maintainer fix and the difference between temporary mitigations and the forthcoming patched release.
- The defense-in-depth guidance for restricting controller egress and blocking metadata endpoints in cloud environments.
👉 Read Orca Security's analysis of the Kyverno SSRF and namespace isolation break →
Kyverno SSRF: what namespace-scoped policy teams need to know?
Explore further
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-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
