CVE-2025-48710: Kube Resource Orchestrator (kro) RCE Vulnerability

CVE-2025-48710 Overview

CVE-2025-48710 affects kro (Kube Resource Orchestrator) versions 0.1.0 through 0.2.0. The flaw allows users with permission to create or modify ResourceGraphDefinition resources to supply arbitrary container images. kro's controllers then deploy and run those attacker-controlled images, producing a confused-deputy condition. The result is code execution on cluster nodes under the privileges of the kro controller. The issue is classified under CWE-441: Unintended Proxy or Intermediary ('Confused Deputy') and was fixed in kro 0.2.1.

Critical Impact
An authenticated Kubernetes user with rights to author ResourceGraphDefinition objects can trigger the kro controller to pull and execute arbitrary container images inside the cluster.

Affected Products

kro (Kube Resource Orchestrator) 0.1.0
kro (Kube Resource Orchestrator) versions after 0.1.0 and before 0.2.1
Kubernetes clusters running the kro controller with default RBAC permissions

Discovery Timeline

2025-06-04 - CVE-2025-48710 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-48710

Vulnerability Analysis

kro is a Kubernetes controller that reconciles high-level custom resources into concrete workloads. Users define a ResourceGraphDefinition that describes a graph of Kubernetes objects, and kro materializes those objects on their behalf. The controller performs this work using its own service account, which typically holds broad cluster permissions.

Before version 0.2.1, kro did not restrict or validate the container image references embedded in a ResourceGraphDefinition. Any user permitted to create or modify these resources could point kro at an arbitrary image. When the controller reconciled the graph, it deployed the attacker-supplied image using its own privileges. This bypassed image policy controls that would otherwise apply to the requesting user.

Once the pod started, the attacker gained code execution inside the cluster with whatever service account, node access, and network reach the resulting workload received. See the Orca Security analysis for a detailed walkthrough.

Root Cause

The root cause is a confused-deputy pattern. kro accepted container image fields from ResourceGraphDefinition input without policy enforcement, then acted on that input using its own elevated identity. Trust boundaries between the requesting user and the controller were not maintained.

Attack Vector

An attacker needs Kubernetes API access with permission to create or modify ResourceGraphDefinition resources. The attacker authors a definition referencing a malicious image, submits it to the API server, and waits for kro to reconcile the graph. The malicious pod then runs on a cluster node with the workload's assigned privileges.

No user interaction is required after submission. See the upstream fix diff between v0.2.1 and v0.2.2 for related hardening changes.

Detection Methods for CVE-2025-48710

Indicators of Compromise

Creation or modification of ResourceGraphDefinition objects that reference images from untrusted or unexpected registries
Pods created by the kro controller service account running images outside your organization's approved registry list
Outbound network connections from kro-deployed pods to attacker-controlled infrastructure
Unexpected container images pulled by nodes shortly after ResourceGraphDefinition changes

Detection Strategies

Audit Kubernetes API server logs for create and update verbs on the resourcegraphdefinitions.kro.run resource
Correlate ResourceGraphDefinition write events with subsequent pod creation events attributed to the kro controller
Use admission controllers such as Kyverno or OPA Gatekeeper to log or block image references that do not match an allowlist
Compare running container images against a signed, approved registry inventory

Monitoring Recommendations

Enable Kubernetes audit logging at the Metadata level or higher for all kro custom resources
Forward container runtime and Kubernetes audit events to a centralized analytics platform for correlation
Alert on pods that mount privileged capabilities or host paths and were created through kro reconciliation
Monitor image pull events for registries not on your approved list

How to Mitigate CVE-2025-48710

Immediate Actions Required

Upgrade kro to version 0.2.1 or later across all clusters
Review existing ResourceGraphDefinition objects and remove any that reference untrusted images
Restrict RBAC permissions on resourcegraphdefinitions.kro.run to a minimal set of trusted principals
Enforce a container image allowlist through an admission controller

Patch Information

The kro maintainers addressed the issue in release 0.2.1. Review the version comparison on GitHub for the code changes shipped in the surrounding releases and upgrade to the latest stable version.

Workarounds

Remove the create and update verbs on ResourceGraphDefinition resources from all roles that do not require them
Deploy an admission policy that rejects ResourceGraphDefinition objects containing images outside an approved registry
Run the kro controller with the least privileges required, avoiding cluster-admin bindings
Apply Pod Security Admission restricted profile to namespaces where kro deploys workloads

bash

# Example Kyverno policy fragment to restrict images in ResourceGraphDefinitions
# Apply after upgrading kro; adjust registry to your approved source
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-kro-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: allowed-registries
      match:
        any:
          - resources:
              kinds:
                - kro.run/v1alpha1/ResourceGraphDefinition
      validate:
        message: "Images in ResourceGraphDefinition must come from the approved registry."
        pattern:
          spec:
            resources:
              - template:
                  spec:
                    containers:
                      - image: "registry.example.com/*"