GPU VulnDB

Database/Container, Kubernetes & orchestration

Azure Kubernetes Service: incorrect authorization lets an authorized attacker elevate privileges remotely

CVSS 9.4CVE-2026-50516Container, Kubernetes & orchestrationcurated

Impact

An authorization check in AKS was incorrect, letting an attacker who already holds some legitimate access elevate privileges over the network, with high confidentiality and integrity impact. On a GPU cluster that is the difference between a tenant's own namespace and the cluster-wide authority that can schedule onto any node and read any secret, including the credentials that reach shared storage and the model registry. Microsoft's entry gives only the weakness class and does not say which API surface or which privilege boundary was crossed, so an operator cannot scope it precisely. Kept separate from the Azure Kubernetes Configuration Service missing-authentication issue: different service, different weakness, different prerequisite.

Who can reach it

A remote attacker holding existing authorized access to the AKS surface - per the record no additional privilege is needed beyond that foothold.

What to do

Microsoft fixed this in the hosted service; no patch to roll out and no node drain or reboot. Confirm your clusters are on a current AKS version and, if they host untrusted or multi-tenant workloads, review RBAC bindings and audit logs for escalation attempts predating the fix.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.