What is the Vulnerability?
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. This vulnerability follows the 'Confused Deputy' pattern and can affect another team's container in a multi-tenant install, while in a single-tenant install it is only self-DoS.
How Does it Work?
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.
Impact and CVSS Score
- **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)
Mitigation and Remediation
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
A short-term fix involves adding validation logic to ensure the container ID in `radapp.io/status` belongs to the current namespace/tenant. A long-term fix includes implementing the least privilege principle, adding Radius API authorization validation, and audit logging.