# The Cloud Giants That Can't Keep a Secret: Confused Deputy Flaws Still Breaking Azure and GCP
Norm Hardy named this class of vulnerability in 1988. He was writing about a compiler at a commercial timesharing firm in Silicon Valley. Nearly four decades of IAM evolution, cloud abstraction layers, and zero-trust marketing later, independent researcher Justin O'Leary found the same fundamental failure sitting inside Microsoft Azure and Google Cloud Platform — and neither company wanted to talk about it.
That's the story. The vulnerability class isn't exotic. The affected platforms are the two most widely deployed cloud environments in enterprise and government. And the response from both vendors was silence.
## What "Confused Deputy" Actually Means
The confused deputy problem is deceptively simple, which is part of why it keeps showing up.
When a service receives a request from an upstream entity, it inherits that entity's authority to act. The confusion happens when the service fails to track *where that request originally came from* before forwarding it downstream. An attacker who can craft or intercept that request chain can make a high-privileged service vouch for them — passing their request along as if it originated from a trusted internal source rather than from the attacker's own account.
The practical result: you bypass firewall rules, IAM policies, and access controls that were designed to stop exactly you. You don't need a credential. You need the right service to carry your request without asking questions.
In cloud environments, where everything communicates through managed identity tokens and service-to-service trust is deeply embedded in how workloads are designed, this creates compounding problems. The attack surface isn't a single misconfigured bucket. It's the trust architecture itself.
## Where O'Leary Found the Cracks
O'Leary's research focused on managed identity chains — the mechanism cloud platforms use to let services authenticate to each other without hardcoded credentials. This is supposed to be the secure path. In practice, he found that both Azure and GCP had implemented it in ways that allowed confused deputy exploitation.
The specific mechanics will get their full airing in his Black Hat USA 2026 session, "Trust No Deputy: Breaking Azure and GCP Through Managed Identity Chains." But the core finding is consistent across both platforms: the request forwarding logic didn't adequately validate or preserve the original request source, creating openings for attackers to elevate to administrative-level permissions by tricking the platform into forwarding requests on their behalf.
O'Leary's characterization of the root cause is worth sitting with. "When you're building these big cloud infrastructures, you're often doing it in a cookie-cutter approach," he told Dark Reading. That's not an accusation of laziness — it's a description of how large-scale infrastructure development actually works. Teams build components that are reused and composed. Trust assumptions get baked in early and rarely revisited. The vulnerability that works in one component gets replicated into a dozen others because the original template had it wrong.
## The Silence Is Its Own Story
Both Google and Microsoft received O'Leary's reports. Neither acknowledged the vulnerabilities. Neither paid a bug bounty. Microsoft appears to have silently patched its flaw — which means the company knew it was real, fixed it without public disclosure, and declined to credit the researcher who found it.
Silent patching isn't unique to Microsoft, and it's not always indefensible. There are scenarios where public disclosure before patch availability creates unacceptable risk. But when a researcher reports a vulnerability, gets no response, and then watches the issue quietly disappear in an update cycle, that's a failure of the vulnerability disclosure relationship — one that discourages the kind of independent research that found this problem in the first place.
The GCP situation is less clear from what's public. Whether the flaw has been addressed, is in remediation, or remains open is unknown as of O'Leary's Black Hat presentation timing.
For enterprise security teams running workloads on either platform, that ambiguity matters. If your cloud provider silently patches a critical trust chain vulnerability, you may not know to audit whether that vulnerability was exploited before the fix landed.
## HackWire Analysis
The confused deputy finding in Azure and GCP fits a pattern that's getting harder to ignore: managed identity, which was supposed to solve the credential sprawl problem, is becoming an attack surface in its own right.
Over the past two years, researchers have repeatedly demonstrated that the service-to-service trust mechanisms at the core of modern cloud architecture are vulnerable to privilege escalation attacks that don't require stolen passwords or misconfigured buckets. The Midnight Blizzard/Microsoft breach in 2024 showed what happens when OAuth token chains get abused at scale. The Azure cross-tenant identity takeover research that preceded O'Leary's work explored similar structural weaknesses in how Azure Automation inherits permissions. What O'Leary has added is confirmation that the same confused deputy logic failures exist across both major hyperscaler platforms simultaneously — which suggests this isn't a vendor-specific implementation error but a category-level risk in how cloud-native identity is being engineered.
The 1988 framing is instructive but potentially misleading. This isn't a case of cloud teams forgetting a 40-year-old lesson. It's a case of scale introducing new complexity into identity chains that are structurally similar to what Hardy described but are operationally far more opaque. When a managed identity token can flow through five services before reaching a resource, tracking the original request source isn't a trivial problem — and apparently neither Azure nor GCP had solved it.
For defenders, the immediate question is whether workloads using managed identity chains have logging in place to detect anomalous request propagation. Most don't. Cloud-native logging captures what actions were taken and by which identity, but reconstructing the full upstream request chain to detect a confused deputy exploit requires log coverage and correlation that most security teams aren't running.
The Black Hat session will be the forcing function for enterprises to revisit this. Expect proof-of-concept tooling to circulate within weeks of the presentation. Teams running high-value workloads on Azure or GCP — especially government and financial services customers — should be pulling their managed identity configurations now and asking hard questions about what their upstream trust chains actually look like.
The vulnerability has a name from 1988. The window to get ahead of it is right now.
— HackWire Editorial
---
## Related Coverage