"Nice catch!" wrote a Google security engineer to researcher Justin O'Leary — then the company reversed course, said there was no vulnerability, and declined to pay a bounty for a flaw that remains marked high-severity and still unfixed.
ConfigConfusion and Config Connector
O'Leary named the issue ConfigConfusion. It stems from Config Connector, an open source Kubernetes add-on that lets users manage Google Cloud resources through Kubernetes. According to O'Leary, Config Connector fails to perform an authorization check: a namespace user with only kubectl access can submit a malicious IAMPolicyMember resource. Config Connector, he says, passes the user-controlled organization ID directly to the GCP IAM API and executes the request with its own elevated credentials, thereby making the user an Organization Owner.
In O'Leary's demonstration, three lines of YAML delivered full administrative control over a GCP Organization in about five seconds. He told The Register that "Config Connector executes privileged operations on behalf of users without verifying those users are authorized," and that the result is a confused-deputy condition that yields root access — including projects, secrets, billing, and Gmail accounts — with no audit trail tied to the attacker's Kubernetes identity.
Google's response and the Cloud Vulnerability Reward Program decision
Google initially accepted O'Leary's report. On March 27 a Google security engineer told him the issue was filed with the relevant product team and added "We'll let you know when the issue was fixed," assigning the bug P1 priority and S1 severity. Eleven days later, on April 7, O'Leary received a message from a Google Security Bot reversing that decision: the Cloud Vulnerability Reward Program panel concluded the "security impact of this issue does not meet the criteria to qualify for a reward" and that the issue "is working as intended."
A Google spokesperson told The Register the company did not issue a bug bounty because exploitation is "only exploitable if an attacker has access to a Config Connector Service Account that’s been granted the Organization Admin role by the organization (i.e., it is privileged)" and because an attacker would first need "to gain entry to an organization's environment (e.g., an exposed container) in order to leverage the privileged Config Connector instance and execute commands with administrative authority." The spokesperson added that granting such permissions "goes against Google Cloud’s publicly shared best practices and the principle of least privilege."
Timeline: March 8 — June 18, 2026
- March 8 — O'Leary reported the vulnerability to Google.
- March 27 — A Google security engineer accepted the report, called it a "Nice catch!" and assigned P1/S1.
- April 7 — A Google Security Bot informed O'Leary the Cloud Vulnerability Reward Program panel decided the issue did not qualify for a reward and labeled it "working as intended."
- June 18, 2026 — Nearly three months after acceptance, the bug report remains P1/S1 with status "in progress (accepted)," with no CVE assigned and no fix issued; O'Leary received no bounty.
Tenable's prior Jenga findings and precedent
O'Leary notes ConfigConfusion echoes earlier "confused-deputy" issues that Google has fixed in other services. Tenable Research documented two prior cases — ImageRunner in Cloud Run and ConfusedComposer in Cloud Composer — that abused inter-service permissions to escalate privileges. Tenable researcher Liv Matan described the class as "Jenga," calling out the risks posed by interconnected services and hidden misconfigurations. Google added authorization checks to both Cloud Run and Cloud Composer after those reports; O'Leary asks why the same check cannot be added to Config Connector.
What this means for technologists, enterprises, and bug hunters
- Technologists and security teams: Operators who use Config Connector to manage resources across multiple GKE clusters should note O'Leary's claim that Google documentation instructs how to grant org-level permissions to the Config Connector service account. If the documentation does so, teams must weigh the configuration guidance against O'Leary's assertion that Config Connector lacks an authorization check, which would allow a namespace user to escalate to Organization Owner.
- Enterprise cloud and DevOps teams: Organizations that grant the Config Connector service account organization-level permissions will need to reconcile Google's best-practice guidance with the possibility a namespace-level kubectl user could abuse Config Connector's elevated credentials, according to O'Leary's disclosure.
- Bug hunters and disclosure advocates: O'Leary said this pattern is familiar — he drew a parallel to a similar interaction with Microsoft earlier this year, where he reported a privilege escalation in Azure Backup for AKS, Microsoft rejected the report and then silently patched it without assigning a CVE or publishing an advisory. O'Leary told The Register, "This is just how these trillion-dollar companies deal with people like me."
The facts here are specific and unresolved: a researcher reported a high-priority, high-severity flaw he calls ConfigConfusion; Google at first accepted the report and praised the find; then the company said the issue did not meet reward criteria and that the behavior is "working as intended"; and the report remains open with no CVE and no public patch. The concrete next step the record leaves open is whether Google will add the same sort of authorization check to Config Connector that it added to Cloud Run and Cloud Composer — and whether it will close the accepted P1/S1 report with a fix and advisory rather than a "working as intended" designation.
