Kyverno SSRF breaks namespace isolation and exposes cloud credentials

At a glance

What this is: Orca Security’s analysis shows that a critical Kyverno SSRF lets namespaced policy logic make outbound HTTP requests from a privileged admission controller, turning delegated policy evaluation into a path to internal data and cloud credential exposure.

Why it matters: IAM and platform teams need to treat admission controllers as privileged network actors, because namespace delegation does not contain outbound request capability once policy logic can call external URLs.

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.

Context

Kyverno is a Kubernetes admission controller, which means it evaluates API requests before they are stored and can enforce policy at the point of admission. The security assumption in this design is that namespaced policies stay within namespace boundaries even when they are evaluated by a cluster-level component.

This article is about that assumption breaking in practice. Once policy expressions can invoke outbound HTTP from the admission controller pod, namespace-scoped authors are no longer limited to namespace-scoped reach. The result is an identity and network boundary failure, not just a code flaw.

For IAM and cloud teams, the important question is not whether the policy author had cluster-admin. It is whether the execution context behind the policy had stronger network reach, stronger trust, and stronger credential access than the author was meant to have.

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. A user with limited policy rights can cause a privileged controller to reach internal services or metadata endpoints, so the effective access path is controlled by the controller’s network position, not the author’s RBAC permissions. That creates a cross-boundary data access problem.

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. If an admission controller can reach those endpoints, the attack can move from cluster data exposure to cloud account abuse.

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. Those signals mean policy evaluation is no longer confined to admission decisions and may be driving network access from a privileged component.

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.

Technical breakdown

Why a namespaced policy can become a cluster-level network action

Kyverno evaluates certain policy logic inside its admission controller pod, not inside the user’s namespace. That distinction matters because the pod’s network identity, routing, and egress permissions determine where a request can go. In a secure design, delegated policy authorship should not grant the ability to make arbitrary outbound HTTP from a trusted control-plane component. Here, the HTTP helper runs in the controller’s context, so the policy author is indirectly driving network reach they do not personally possess. That is why namespace scoping and execution scoping are not the same thing.

Practical implication: treat any policy language that can trigger network calls as privileged control-plane code, even when policy creation is namespaced.

How SSRF turns admission evaluation into credential exposure

Server-Side Request Forgery happens when untrusted input controls a server-side request destination. In this case, the policy author influences the URL and the admission controller performs the request, so the response can come from internal services, cluster services, or cloud metadata endpoints. Metadata endpoints are especially dangerous because they often rely on network position rather than user authentication. If a pod can reach 169.254.169.254 or a provider metadata service, it may retrieve temporary credentials or tokens. That turns an admission-time validation feature into a credential retrieval path.

Practical implication: block metadata endpoints and restrict egress from policy engines as if they were credential-bearing workloads.

Why Kubernetes RBAC does not contain this failure mode

Kubernetes RBAC governs API operations, such as creating resources through the Kubernetes API. It does not govern raw HTTP traffic leaving a pod. That is the core mismatch exposed here: a user may lack access to kube-system objects, yet still cause the admission controller to fetch data from services in that namespace because the network call is made by the controller. Namespace delegation therefore needs both API authorization and network authorization, or the stronger trust domain will leak through the weaker one.

Practical implication: pair policy RBAC with network policy, destination allowlisting, and explicit controls on external fetch functions.

Threat narrative

Attacker objective: The attacker wants to use delegated policy creation to make the Kyverno controller fetch internal data or cloud credentials on their behalf.

1. Entry occurs when a namespace-scoped user creates a malicious namespaced Kyverno policy that includes an HTTP-capable expression.
2. Credential or data access occurs when the admission controller evaluates that policy and makes the outbound request from its own pod context.
3. Escalation occurs because the request can reach internal cluster services or cloud metadata endpoints that the attacker could not access directly through Kubernetes RBAC.
4. Impact is exfiltration of internal data or temporary cloud credentials through the admission response or reflected error message.

Breaches seen in the wild

• Capital One breach 2019: A misconfigured firewall handed over its cloud role credentials, and an over-privileged role exposed data on 106 million people.
• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Access control failed here because execution context outlived the author’s intended scope. The namespaced policy author never received kube-system access, but the Kyverno controller did the work from inside a trusted namespace. This is a control-plane version of privilege transference, where the platform substitutes its own reach for the user’s constraints. The implication is that scoped policy authorship must be evaluated alongside the egress and destination authority of the runtime component.

Policy engines that evaluate user expressions must be designed as identity-bearing network clients. The moment CEL, Rego, or other policy languages can resolve URLs, the system is no longer just making policy decisions. It is also making outbound trust decisions on behalf of the cluster. That creates a named concept worth tracking: policy-evaluation egress risk. Security teams should classify it as a separate control domain, not as a side effect of admission control.

Cloud metadata access is the highest-value blast radius in this pattern. Internal service exposure is serious, but metadata endpoints can convert a cluster-side SSRF into cloud-side credential theft. That expands the problem from namespace containment to account-level compromise, especially where nodes or pods can reach instance metadata without hard egress restrictions. Practitioners should assume that any admission-time HTTP primitive can become a cloud credential path unless explicitly blocked.

The fix direction validates the governance gap rather than simply patching code. The article’s remediation path disables HTTP for namespaced policies by default and adds allowlist and blocklist controls for dangerous destinations. That is a strong signal that delegated policy authorship and unrestricted outbound fetches were never compatible at the same trust level. The practical conclusion is to redesign policy features around destination control, not around policy author convenience.

From our research library:

• 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.

What this signals

Policy-evaluation egress risk: once a policy engine can resolve outbound URLs, namespace delegation becomes a trust problem for the controller runtime, not just a governance problem for the policy author. Teams should classify those network-capable policy features as privileged execution paths and subject them to egress control.

Admission controllers increasingly sit at the intersection of identity, policy, and network reach. The practical programme response is to govern what the controller can call, not only who can submit the policy.

If a namespace-scoped policy can influence an HTTP request, the control boundary has already shifted. That means detection, network policy, and policy review all need to operate together, because RBAC by itself cannot see or stop the outbound request.

For practitioners

• Restrict egress from admission controllers Allow Kyverno pods to reach only the Kubernetes API server and explicitly approved external services. Block arbitrary outbound HTTP from the controller namespace because policy evaluation must not become a general-purpose proxy.
• Block cloud metadata destinations Prevent all pods that do not require instance credentials from reaching 169.254.169.254 and provider metadata services. Use network policy, node firewall rules, or cloud controls to remove metadata reach from the controller path.
• 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.
• Search policies for HTTP functions Scan existing namespaced policies for http.Get and http.Post usage, then classify any policy that can trigger external requests from a trusted controller as a high-risk exception.
• Validate controller egress in detection rules Alert on Kyverno pod connections to internal namespaces, external destinations, or metadata endpoints during policy evaluation windows so unexpected request paths are visible before exposure becomes credential theft.

Key takeaways

• A namespace-scoped policy engine becomes risky when policy evaluation can drive network requests from a privileged controller pod.
• The article shows a live proof of concept where a namespaced policy caused data to be fetched from kube-system and reflected back in the admission flow.
• Blocking controller egress, denying metadata access, and removing HTTP-capable policy paths are the controls that reduce this exposure.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
• Cloud metadata endpoint: A cloud metadata endpoint is a local service that exposes instance details and, in some environments, temporary credentials to workloads running on that instance. It is highly sensitive because SSRF can sometimes reach it from within the application and extract information meant only for trusted code.
• Namespace Isolation: Namespace isolation is the expectation that users or policies restricted to one Kubernetes namespace cannot affect resources or data outside that namespace. It fails when a shared controller executes delegated logic with broader runtime privileges than the author of the request.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.