Two Cloud Giants, Two Flaws, Zero Bug Bounties: The 'Confused Deputy' Problem That Won't Go Away

Key points

• Security researcher Justin O'Leary disclosed two separate "confused deputy" vulnerabilities, one in Microsoft Azure on 12 May and one in Google Cloud on 18 June.
• The Azure flaw let an attacker with basic backup permissions quietly escalate to full cluster administrator access over Kubernetes infrastructure.
• The Google Cloud flaw let an attacker with minimal permissions make themselves an Organisation Owner with complete administrative control, and left no visible trace in audit logs.
• Microsoft appears to have silently patched its flaw without publicly acknowledging it; Google declined to class its flaw as a vulnerability eligible for a bounty reward.
• Google's Config Connector tool is deployed in FedRAMP-authorised environments, meaning the flaw reaches US federal government cloud infrastructure.

A type of security flaw that computer scientists identified nearly 40 years ago is still causing serious problems inside the world's largest cloud platforms.

Justin O'Leary, an independent security researcher, disclosed two so-called "confused deputy" vulnerabilities earlier this year, one affecting Microsoft Azure and one affecting Google Cloud Platform. Neither company paid a bug-bounty reward. Microsoft appears to have fixed its flaw without announcing it. Google told O'Leary it might fix the issue but that it did not qualify as a vulnerability serious enough to reward.

What is a confused deputy flaw, and why does it matter here?

A confused deputy attack tricks a powerful, trusted service into doing something on behalf of a low-privileged attacker, the same way a corrupt employee might use their employer's authority to act outside the rules. The attacker does not need special access. They just need to fool a high-privileged middleman into acting for them.

Computer scientist Norm Hardy named the problem in a 1988 paper after spotting it years earlier. The underlying weakness is catalogued by MITRE, the non-profit organisation that maintains a global database of software flaw types, as CWE-441, a "confused deputy" category.

O'Leary told Dark Reading that cloud builders often copy patterns from one service to another without checking whether the trust assumptions still hold. That copy-and-paste approach is why the flaw keeps reappearing.

What exactly could an attacker do?

The Azure flaw sits inside the Azure Kubernetes Service backup tool. Kubernetes is software that manages large collections of containerised applications (think of it as an automated traffic controller for a company's back-end software). The backup service uses a feature called Trusted Access to reach inside a Kubernetes cluster. O'Leary found that a user with only the lowest backup permission, called Backup Contributor, which carries no Kubernetes access at all, could exploit the confused deputy flaw to promote themselves to cluster administrator. From there, they could steal data from backups or install malicious software across the whole network.

The Google Cloud flaw lives in Config Connector, an open-source add-on that lets teams manage Google Cloud resources through Kubernetes. O'Leary found that Config Connector never checks whether the person making a request actually has permission to grant the role they are requesting. It simply passes the request to Google's own back-end systems using its own high-level credentials.

"When a Kubernetes user submits an IAMPolicyMember referencing an external organisation, Config Connector should verify: does this user have permission to grant IAM roles on this organisation?" O'Leary wrote in his research notes. "It doesn't."

The result: an attacker with basic Kubernetes namespace access and no Google Cloud permissions at all can make themselves a Google Cloud Organisation Owner with full administrative control over every resource in the organisation.

Worse, the attack leaves almost no trace. Actions appear in audit logs as activity by the service account, not the attacker. "The attacker is essentially invisible," O'Leary said.

Should cloud customers be worried?

Yes, particularly Google Cloud customers. Config Connector is widely deployed across large enterprises and US government agencies, including environments that carry FedRAMP authorisation (a US federal programme that certifies cloud services as safe enough for government data). Google's own documentation for the tool does not clearly warn users about this risk.

Microsoft's decision to patch quietly is also a concern. A silent patch, O'Leary argues, protects the vendor's reputation but leaves customers unable to tell whether they were exposed or for how long.

O'Leary is presenting the full technical detail in a session called "Trust No Deputy: Breaking Azure and GCP Through Managed Identity Chains" at Black Hat USA 2026.

What should your organisation do right now?

Cloud teams should audit the permissions granted to any backup or connector service running in their Kubernetes environments. Specifically, check whether Config Connector's service account holds more Google Cloud permissions than your teams actually need, and tighten them. Separating trust boundaries so that no single service can grant itself elevated access to unrelated systems directly reduces the risk O'Leary describes. Security teams should also review audit logs for any unexpected IAM role changes, bearing in mind that some of the activity described here may appear as service account actions rather than individual user actions.