Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)
Date: 2026-06
Affected: go/github.com/radius-project/radius
Attack vector: deserialization
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-53999
CWE: CWE-20
CWE-441
CVSS: 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H)

# 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-pr


Mitigations:

Architectural layers (MAESTRO):