Confused Deputy Flaws Let Low-Level Users Hijack Azure and Google Cloud

What Happened?

An independent security researcher found two “confused deputy” flaws this year. One is in Microsoft Azure. The other is in Google Cloud. Both were reported to the vendors ahead of a talk at Black Hat USA 2026.

A confused deputy flaw is simple to explain. A trusted service holds high permissions. An attacker tricks that service into acting on their behalf. The service never checks if the attacker was allowed to make the request. It just does the job using its own powerful access.

The Azure flaw sits in the backup service for Azure Kubernetes Service. A user with a basic Backup Contributor role has no Kubernetes rights at all. But the flaw lets that user jump all the way to cluster-admin. From there, an attacker can steal data from backups or drop malicious workloads onto clusters.

The Google Cloud flaw is worse. It lives in Config Connector, an open source add-on that lets teams manage cloud resources through Kubernetes. The tool takes a user-supplied organization ID and passes it straight to the Google Cloud API using its own high-level credentials. It never checks if the user was allowed to touch that organization.

The result is stark. A user with basic Kubernetes access and zero cloud permissions can become Google Cloud Organization Owner. That is full control over every project, every secret, and every billing account. The researcher scored it a perfect 10.0 on the CVSS severity scale.

There is a stealth angle too. The attacker’s actions get logged as service account activity. That hides the real attacker from the audit logs. As the researcher put it, the attacker is basically invisible.

What’s the Impact?

The Google Cloud flaw remains unpatched. Google first accepted it as a top-priority bug. Then a review panel reversed course and called it “working as intended.” No fix. No bounty. The tool is deployed across large enterprises and government agencies, including FedRAMP-authorized environments.

Microsoft appears to have quietly patched its Azure flaw. But a silent patch leaves customers in the dark. They cannot track their own exposure if no one tells them a hole existed.

The bigger issue is the pattern. This is not one odd bug. It is the same design gap showing up again and again across cloud platforms. Google itself patched this exact pattern twice before, in tools called Cloud Run and Cloud Composer. The check that stops the attack was added to those services. It was never added here.

Confused deputy problems are not new either. The term dates back to a 1988 paper. Nearly forty years later, and after huge advances in identity and access management, the same flaw class keeps coming back. Cloud teams often build in a cookie-cutter way, and that spreads the weakness far and wide.

How to Avoid This

You cannot patch your way out of a vendor bug. But you can shrink the blast radius and watch for abuse.

• Lock down who can run kubectl apply. The Config Connector attack needs only namespace access. Review your Kubernetes role-based access controls and cut anyone who does not need write access.
• Scope your service account credentials tight. Do not grant organization-level or folder-level permissions unless you truly need them. Smaller permissions mean a smaller blast radius.
• Watch your cloud audit logs. Look for new identity and access bindings at the folder or organization level that did not come through your normal GitOps pipeline. Sudden owner-level grants are a red flag.
• Separate your trust boundaries. Keep a clear wall between your Kubernetes layer and your cloud identity layer. One should not silently speak for the other.
• Open a support case with your provider. If you run these tools, ask directly why the flaw remains open and push for a real fix.