vulnerability
Google shrugs off Config Connector cloud takeover bug
2026-06-19
In March, researcher Justin O'Leary reported something fairly spectacular to Google. From a single Kubernetes namespace, with zero Google Cloud permissions to his name, he could promote himself to Organization Owner of an entire GCP org in roughly five seconds. Three lines of YAML. Full control over projects, secrets, billing, Gmail, all of it. No audit trail in GCP IAM, because his identity never touched IAM at all.
A Google security engineer replied with "nice catch", rated it P1/S1, and said they would work with the product team on a fix. Eleven days later, a bot reversed the decision. No vulnerability, no payout, no patch. The ticket is still sitting there at P1/S1, marked "in progress (accepted)", which is a fun status for something Google has also decided is not a bug.
What the flaw actually does
The bug lives in Config Connector, Google's own Kubernetes add-on for managing cloud resources from inside a cluster. It runs privileged operations on behalf of users without checking whether those users are authorised to ask for them. In security terms it's a confused deputy: a trusted process happily doing dangerous things for whoever sends it a request.
Config Connector's service account is granted Organization Admin so it can do its job. Anyone with kubectl access to a namespace where that service account operates can ride those permissions all the way up. No IAM role, no audit log entry tying the action to a person, no friction.
The dispute
Google's position is that the Config Connector service account legitimately needs Organization Admin, and if a developer with namespace access can abuse it, that's the customer's problem for not applying least privilege properly.
O'Leary's counter is straightforward. Google's own documentation tells administrators to grant exactly those permissions. A privileged service account is not supposed to be a quiet escalation path for anyone holding a kubectl context. And, awkwardly for the "working as intended" line, Google has already fixed the same confused deputy pattern twice in other services after Tenable raised it.
O'Leary says he had a similar experience with Microsoft earlier this year. He reported an Azure Backup flaw, watched it get rejected, then watched it get silently patched with no CVE and no credit.
What to do if you run Config Connector
While Google decides whether this is a bug or a feature, the practical exposure is real for anyone using GKE with Config Connector at organisation scope. Worth checking:
- Who has namespace access in clusters where Config Connector's service account holds org-level roles. Treat that list like an IAM list, because functionally it is one.
- Whether Config Connector really needs Organization Admin, or whether you can scope it to specific projects or folders that match what your team actually manages.
- What logging you have outside GCP IAM. Kubernetes audit logs in the cluster will see the YAML go past. GCP's audit logs will not see a person behind the action.
The interesting wrinkle here is not the bug itself. Confused deputy issues are old, well understood, and Google clearly knows how to fix them when it wants to. The interesting bit is the gap between a human engineer saying "nice catch, P1" and a process eleven days later quietly deciding the customer is holding it wrong.