GHSA-fp5j-4fj2-4jvq: Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)
Radius Controller May Delete a Container Resource via an Injected Deployment Annotation (Multi-Tenant Installs)SummaryA 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 versionsVulnerability DetailsRoot CauseThe 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`:**Vulnerability Sink** - `pkg/controller/reconciler/deployment_reconciler.go:491`:Attack ChainProof of Concept (PoC)PrerequisitesKubernetes cluster with Radius v0.54.0 installedAttacker has permission to modify Deployment annotations in a namespaceTarget tenant has Radius-managed container resourcesEnvironment SetupStep 1: Install Kind Cluster and RadiusExpected output:Step 2: Create Attacker Tenant (tenant-a)Step 3: Deploy Legitimate Application in tenant-aCreate `legitimate-app.bicep`:Deploy the application:Step 4: Create Victim Tenant (tenant-b)Step 5: Verify Victim Resource ExistsExpected output:ExploitationStep 6: Inject Malicious AnnotationCreate `attack-patch.yaml`:Execute the attack:Expected output:Step 7: Verify Attack SuccessWait a few seconds and check the victim's resources:Expected output:Log EvidenceThe controller logs show the cross-tenant deletion operation:**Attack Triggered** (15:29:41.351Z):**Cross-Tenant Delete Request** (15:29:41.351Z):**Deletion Successful** (15:29:41.367Z):ImpactSecurity 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 tenantsAttack PrerequisitesAttacker needs permission to modify Deployment annotations in a Kubernetes namespaceAttacker needs to know the target resource's Radius resource ID (obtainable through enumeration or social engineering)CVSS 3.1 Vector| Metric              | Value   | Description                                                        |
|---------------------|---------|--------------------------------------------------------------------|
| Attack Vector       | Network | Via Kubernetes API                                                 |
| Attack Complexity   | Low     | Only requires annotation modification                              |
| Privileges Required | Low     | Requires Deployment edit permission                                |
| User Interaction    | None    | No user interaction required                                       |
| Scope               | Changed | Affects other tenants                                              |
| Confidentiality     | None    | No data disclosure                                                 |
| Integrity           | None    | No victim data modified; deletes a recoverable management resource |
| Availability        | High    | Causes service disruption                                          |WorkaroundsUntil an official fix is released, consider the following mitigations:**Restrict Annotation Modification Permissions**: Use Kubernetes RBAC to limit who can modify Deployment annotations**Monitor Anomalous Operations**: Monitor modifications to `radapp.io/status` annotations, especially those containing other tenants' resource IDs**Network Isolation**: Implement strict network policies in multi-tenant environmentsRemediation RecommendationsShort-term FixAdd validation logic in `annotations.go` to ensure the container ID in `radapp.io/status` belongs to the current namespace/tenant:Long-term Fix**Implement Least Privilege Principle**: The controller should use credentials associated with the Deployment's tenant**Add Radius API Authorization Validation**: UCP should validate the source tenant of delete requests**Audit Logging**: Log all cross-tenant operation attemptsReferences[Radius Project GitHub](https://github.com/radius-project/radius)[CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html)[CWE-441: Unintended Proxy or Intermediary (Confused Deputy)](https://cwe.mitre.org/data/definitions/441.html)[OWASP: Confused Deputy Problem](https://owasp.org/www-community/attacks/Confused_Deputy)
CVSS v3.1: 7.7