Google's tracker says P1. Its panel says working as intended. The flaw makes a namespace user an org owner

Eleven days between Nice catch and working as intended

On 27 March 2026 a Google security engineer read a vulnerability report and replied: "Nice catch! I've filed a bug with the responsible product team based on your report." The same message told the researcher to check the payment option in his profile for his reward. The case was set to P1 priority and S1 severity, status In Progress, Accepted.

Eleven days later, on 7 April, the Cloud Vulnerability Reward Program panel reversed it: "We have reviewed your report and determined that the issue you described is working as intended." No reward. On 1 May, Google's own CNA formally refused a CVE, telling MITRE: "we do not believe it is a vulnerability."

As of the researcher's page, the case is still P1 and S1, still Accepted, still open, and the behaviour is still there. The researcher, Justin O'Leary, published the whole exchange on 18 June alongside his Black Hat USA briefing and calls the technique ConfigConfusion.

What the dispute is not about. Nobody disagrees about what the behaviour does. Google has not argued that the escalation fails, that the researcher got the mechanism wrong, or that the impact is overstated. The argument is about whether a product doing exactly what it was built to do, in a configuration Google documents, counts as a vulnerability in that product.

And what this briefing cannot establish: whether any organisation has been attacked this way, because no incident is reported anywhere; whether Google has quietly fixed it since the page was written; and what Google's internal reasoning was beyond the sentences it sent. One side of this correspondence is published in full and the other is not, which is worth holding on to throughout.

What actually happens

Config Connector is a Kubernetes operator that lets teams manage Google Cloud resources as Kubernetes objects. You write YAML, the operator makes the cloud match it. To do that, it runs with a service account of its own, and in many deployments that account holds organisation level authority, because that is the scope the product supports and documents.

The resource in question is IAMPolicyMember, which grants a member a role on a resource. Its reference documentation includes a section titled External Organization Level Policy Member, with an example that binds a role at organisation scope.

So a user who can create that one kind of object in one watched namespace writes a manifest naming an organisation and a role. Config Connector takes the organisation identifier from the user supplied field and calls the Google Cloud IAM API with it, using its own elevated credentials. It does not check whether the Kubernetes user has any authority over that organisation, because the Kubernetes user's identity never reaches Google Cloud IAM at all.

O'Leary names the file and lines: pkg/controller/iam/iamclient/externalonly.go, where the external reference is placed into the request as is. His summary of the result is blunt: "A Kubernetes namespace user with zero GCP permissions submits a malicious IAMPolicyMember... Five seconds later, the attacker is GCP Organization Owner."

The confused deputy, and the two times Google fixed it

This is a textbook confused deputy, CWE-441: a privileged service is persuaded to use its authority on behalf of somebody who does not have that authority. The fix for a confused deputy is always the same shape. Before the privileged service acts, it checks whether the requester could have done this themselves.

Google has applied that fix twice, to the same pattern, in the last two years.

Three confused deputy findings in Google Cloud, from the research

Finding	The deputy	Outcome
ImageRunner	Cloud Run service agent pulls images the deployer cannot read	Patched January 2025. Cloud Run now verifies the deployer's access to the image
ConfusedComposer	Cloud Composer invokes the Cloud Build service account for package installs	Patched April 2025. Composer no longer uses that account for PyPI installs
ConfigConfusion	Config Connector passes a user supplied organisation ID to IAM with its own credentials	No fix. Working as intended

In the first two cases the defence that the service account legitimately needs elevated permissions was treated as beside the point, because it is. A deputy needs authority to be useful; that is what makes it a deputy. The question is whether it checks who is asking.

The scale of the gap is the detail that should worry a Config Connector operator most. O'Leary counts more than 530 custom resource definitions managed through more than 100 controllers, and finds exactly one controller that validates a cross project reference: the load balancer route extension controller, which refuses references outside its own project for three specific fields. The check exists in the codebase. It was written by Google engineers. It is applied in one place.

Google's reason, and the documentation problem

Google's stated rationale for the refusal is one sentence: "The Config Connector Service Account requires the organization admin role for the reported scenario to be exploitable which is not recommended and breaks best practice."

That is a real argument. If the deployment gives the operator organisation level authority, the blast radius is organisation wide, and an administrator who grants that has made a choice. The difficulty is where the choice came from.

The configuration Google calls not recommended, against Google's own documentation

Google's position	What Google's documentation shows
Organisation admin on the service account is not recommended and breaks best practice	The access control guide describes expanding Config Connector's permissions so it can manage all projects and folders for a given organisation
The scenario is a customer configuration choice	The resource documentation includes a section titled External Organization Level Policy Member, with an example
Organisation scope is an edge case	Organisation level is presented as one of three scopes, alongside project and folder
This is an unintended side effect	Organisation level support was requested in 2020, implemented, and shipped in version 1.27.0

O'Leary says he asked the panel to point to any Google documentation describing the configuration as not recommended, and that none was produced. This briefing could not find one either.

There is a second awkward artefact, and it is the kind of thing that only shows up because git history is public. Config Connector does not appear in Google's cloud vulnerability reward tier file as of 5 November 2025. It appears in that file on 20 March 2026, at Tier 3, the lowest payout tier. The report was submitted on 8 March, twelve days earlier. The research presents that as timing rather than as proof of anything, and so does this briefing.

The timeline

Dates from the research, with days from the report computed for this briefing

Date	What happened	Days
8 March 2026	Vulnerability reported to Google	zero
20 March 2026	Config Connector added to the reward tier file, at Tier 3	12
27 March 2026	Engineer: Nice catch. Bug filed. Reward payment set up. Case P1 and S1, Accepted	19
7 April 2026	Panel: working as intended. No reward. Case remains Accepted	30
1 May 2026	Google CNA refuses a CVE: we do not believe it is a vulnerability	54
18 June 2026	Research published alongside a Black Hat USA briefing	102
25 September 2026	Still open, still P1 and S1, still unpatched on the researcher's account	201

What to do about it

Google's position, taken at face value, is that this is a configuration risk for customers to manage. Whether or not you accept that framing, it means the mitigations are yours.

The question this leaves

There is a version of this story that is just a bounty dispute, and it is the least interesting version. Researchers and vendors disagree about scope all the time, and a panel is entitled to reach a different conclusion from the engineer who triaged first.

The part that matters to everyone else is the boundary being drawn. Google's argument is that the risk lives in how the customer configured the operator, not in the operator's missing check. Applied consistently, that argument would have blocked the ImageRunner fix and the ConfusedComposer fix too, because in both cases the service account also legitimately held the permissions it was tricked into using. Google added the caller check anyway, twice, and the product got safer both times.

So the question for anyone running managed infrastructure that acts on your behalf, on any cloud: when a platform component uses its own credentials to carry out your instruction, who checks that you were allowed to give it? If the answer is that your own authorisation system checks it before the instruction leaves your side, make sure that is actually true, because on this evidence the far side may not be checking at all.