GHSA-fp5j-4fj2-4jvq — Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)

Affected: Go: github.com/radius-project/radius

# 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-p…

Most recent entries from all

GHSA-fp5j-4fj2-4jvq — Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)