CVE-2026-53999 - Radius controller confused-deputy delete

CVE-2026-53999 / GHSA-fp5j-4fj2-4jvq covers a confused-deputy flaw in the Radius Kubernetes controller. The controller deserializes JSON from the radapp.io/status annotation on a Deployment and later uses annotation-derived resource identifiers when deleting a container resource. Without validating that the referenced resource belongs to the same tenant or resource group, the controller can use its higher-privilege identity to delete another tenant’s container resource in a shared installation.

This is most important for multi-tenant Radius deployments. In a single-tenant install it is usually self-DoS, but in a shared controller topology it becomes a real tenant-boundary issue. The right fix is not just “upgrade the package” but also confirm the repository does not keep custom controller code, broad RBAC, or annotation trust patterns that reintroduce the same failure shape.

When to use it

  • A repository deploys Radius controllers or resolves radius-project/radius below 0.58.0.
  • One controller identity can reconcile or delete resources across namespaces, teams, tenants, or resource groups.
  • Owned code or overlays parse radapp.io/status annotations or perform destructive actions from annotation-derived resource IDs.
  • You need a bounded PR or triage note that upgrades Radius and proves tenant-boundary validation before delete operations.

Inputs

  • Go manifests, Radius controller images, Kubernetes manifests, Helm charts, Terraform modules, operator runbooks, RBAC, SBOMs, and generated reports.
  • Install topology, controller identity scope, radapp.io/status parsing code, resource group ownership, and tenant authorization model.
  • Available dependency tests, unit/policy tests, Helm/K8s render, RBAC review, container build, and security scan commands.

Affected versions

  • Vulnerable: github.com/radius-project/radius < 0.58.0
  • Fixed: 0.58.0+
  • Affected surface: Radius controller deployments that reconcile resources for more than one tenant or resource group, especially with shared controller credentials
  • Fixed code shape: annotation-derived resource IDs are validated against the current tenant and authorization context before destructive operations

Indicator-of-exposure

  • The repository resolves radius-project/radius < 0.58.0.
  • Kubernetes manifests, Helm charts, or deployment scripts install the Radius controller.
  • One controller instance reconciles Deployments across multiple teams, namespaces, tenants, or resource groups.
  • The controller service account or Radius API identity can delete resources outside the immediate tenant boundary of the originating Deployment.
  • The repository carries custom controller patches, admission hooks, or annotation-processing logic around radapp.io/status.

Quick checks:

rg -n "radius-project/radius|radapp.io/status|Deployment|controller|reconciler|serviceAccount|ClusterRole|RoleBinding|resourceGroup" .
go list -m all | rg "radius-project/radius"
rg -n "radapp.io/status|serviceAccount|ClusterRole|ClusterRoleBinding|radius-controller|tenant|resource group|shared controller" charts k8s helm deploy docs scripts

Windows:

rg -n "radius-project/radius|radapp.io/status|Deployment|controller|reconciler|serviceAccount|ClusterRole|RoleBinding|resourceGroup" .
go list -m all | rg "radius-project/radius"
rg -n "radapp.io/status|serviceAccount|ClusterRole|ClusterRoleBinding|radius-controller|tenant|resource group|shared controller" charts k8s helm deploy docs scripts

Do not validate exposure by tampering with live deployment annotations in a shared cluster.

Remediation strategy

  • Upgrade all controlled Radius dependencies, controller images, manifests, and rendered artifacts to 0.58.0+.
  • If the repository owns controller customizations or wrappers, validate annotation-derived resource identifiers against the current tenant/resource boundary before any delete or mutate operation.
  • Reduce the controller’s privileges to the smallest scope consistent with the install topology; avoid broad cross-tenant delete capability where separate controllers or scoped identities are possible.
  • Add policy or admission controls that reject malformed or externally tampered radapp.io/status annotations instead of trusting them as authoritative state.
  • Document that shared multi-tenant installs need stronger ownership checks than single-tenant labs or demos.

The prompt

You are remediating CVE-2026-53999 / GHSA-fp5j-4fj2-4jvq, a high-severity
Radius controller confused-deputy issue where tampered deployment annotations
can trigger deletion of another tenant's container resource in multi-tenant
installs. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Radius, removes unsafe trust
  in annotation-derived resource IDs, tightens tenant validation and RBAC,
  adds safe verification, and documents operator follow-up, or
- TRIAGE.md if this repository does not control an affected Radius dependency,
  controller deployment, wrapper, or mitigation path.

## Rules

- Scope only CVE-2026-53999 / GHSA-fp5j-4fj2-4jvq and directly related Radius
  controller annotation parsing, tenant validation, destructive actions, and
  install topology.
- Treat cluster manifests, resource IDs, service-account tokens, cloud
  credentials, tenant names, and logs as sensitive.
- Do not tamper with live annotations or delete real resources to prove
  exposure.
- Do not broaden controller privileges, skip authorization checks, or normalize
  cross-tenant IDs into the current tenant to make tests pass.
- Do not auto-merge.

## Steps

1. Inventory every controlled Radius dependency, image, controller deployment,
   Kubernetes manifest, Helm chart, Terraform module, and operator runbook.
2. Resolve versions. Anything below `0.58.0` is vulnerable.
3. Determine install topology: single tenant, per-team controller, or shared
   multi-tenant controller. Record where one controller identity can affect
   multiple tenants or resource groups.
4. Search for owned code or overlays that parse `radapp.io/status`, copy
   annotation-derived resource IDs, or perform delete operations from that
   state.
5. If this repository does not control an affected Radius controller runtime or
   patch path, stop with `TRIAGE.md` naming the owner and required version
   `0.58.0+`.
6. Upgrade all controlled dependencies, controller images, and render outputs
   to `0.58.0+`.
7. For owned code or wrappers, ensure destructive operations validate that the
   resource referenced by the annotation belongs to the current tenant,
   namespace, and authorization context before delete or mutate actions occur.
8. Harden deployment boundaries:
   - prefer per-tenant or per-scope controller identities where practical;
   - reduce service-account and Radius API permissions;
   - reject malformed or unexpected annotation payloads;
   - document unsupported shared-topology shortcuts.
9. Add safe tests or policy checks:
   - resolved version is `0.58.0+`;
   - annotation-derived resource IDs from another tenant are rejected;
   - admission or validation logic fails closed on malformed status payloads;
   - render output and RBAC do not grant unnecessary cross-tenant delete
     privileges.
10. Add a PR body section named `CVE-2026-53999 operator actions` that states:
    - Radius versions before and after;
    - whether the install is single-tenant or shared multi-tenant;
    - which identities could delete cross-tenant resources before the change;
    - what tenant-validation and RBAC controls were added;
    - which cluster audit logs or Radius API logs operators should review.
11. Run relevant validation: dependency install, unit tests, policy tests, Helm
    rendering, Kubernetes schema checks, RBAC review, container build, and
    security scans that do not mutate live clusters.
12. Use PR title:
    `fix(sec): harden Radius controller tenant-boundary deletes`.

## Stop conditions

- No controlled Radius controller deployment or dependency exists.
- The repository only consumes a vendor-managed Radius service and cannot patch
  or contain the controller.
- Safe verification would require destructive testing in a shared environment.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled dependency or image resolves radius-project/radius < 0.58.0.
  • Annotation-derived resource IDs are not trusted for destructive actions without tenant-boundary validation.
  • Shared installs have scoped identities and RBAC rather than broad cross-tenant delete capability.
  • Tests prove cross-tenant references are rejected fail-closed.

Output contract

  • Reviewer-ready PR upgrading Radius dependencies and controller images to 0.58.0+ with refreshed render output, SBOMs, and reports.
  • Tenant-boundary validation for annotation-derived resource IDs before delete or mutate operations in owned code.
  • Operator notes for single-vs-shared topology, identities that could delete cross-tenant resources, RBAC tightening, and audit logs to review.
  • TRIAGE.md when the affected controller deployment or patch path is not controlled by this repository.

Watch for

  • Treating single-tenant test behavior as proof that multi-tenant deployments are safe.
  • Upgrading the module while a vendored controller patch keeps the old trust pattern.
  • Leaving cluster-level service accounts or broad Radius API credentials in place after the version bump.
  • Assuming “recoverable deletion” means the tenant-boundary violation is low risk.

References