Google Told the Researcher Nice Catch Then Refused to Pay and Never Fixed It

Google told a security researcher his bug was a nice catch, lined up his payout, then eleven days later called it harmless and refused to pay a cent. The flaw he reported lets anyone with basic Kubernetes access take over a complete Google Cloud organization in about five seconds, with three lines of text and no special permissions at all. Months on, it still is not fixed. He named it ConfigConfusion.

The man who found it goes by Justin O’Leary, a cloud bug hunter. What he found lives inside a Google tool called Config Connector.

Config Connector lets teams manage their Google Cloud setup by writing simple text files in Kubernetes, instead of clicking around in the cloud console. You describe what you want in a file, and Config Connector goes and makes it happen on Google Cloud for you. To do that across a company, it runs with a powerful service account, an automated identity that holds high-level permissions.

Here is where it goes wrong. When someone hands Config Connector one of those text files, it carries out the work using its own powerful identity, and it never checks whether the person who submitted the file was allowed to ask for that. So a developer sitting in one small corner of the Kubernetes cluster, with no Google Cloud permissions at all, can submit a file that grants themselves owner rights over the organization. Config Connector runs the request as if a real administrator asked for it. Security people call this a confused deputy, tracked as CWE-441: a trusted helper that gets tricked into misusing its power for someone who should never have had it.

The file an attacker needs is short. It points at the organization, it names who should get owner rights, and Config Connector handles the rest. Those owner rights sit right at the top, above the projects, the secrets, and the billing that live underneath. The grant can go to any Google account, including a throwaway address made minutes earlier, and it stays in place even after the attacker loses their Kubernetes access. The action shows up in the logs as the service account, not as the person who triggered it, so the trail points at the tool instead of the attacker.

That is not just a title on paper. From that position an attacker can:

• → Lock the real administrators and the security team out of their own cloud, while keeping their own access intact
• → Quietly switch off the audit logging, so the activity leaves no record for anyone to find
• → Forward a copy of the logs from across the company to a server they control
• → Run up a bill in someone else’s name, for example by mining cryptocurrency on the company’s account

O’Leary scores the flaw a 10 out of 10, the top of the standard severity scale. Work through the math he supplies and it lands a touch under, at 9.9, because the attacker still needs that small bit of Kubernetes access to start. There is no official score either way, because that comes with a CVE, and Google refused to assign one.

This is roughly what that malicious request looks like:

1
2
3
4
5
6
7

kind: IAMPolicyMember
spec:
  member: user:attacker@gmail.com
  role: roles/owner
  resourceRef:
    kind: Organization
    external: "123456789012"

Apply that with a single kubectl command and the binding lands on the organization. Not one Google Cloud permission was checked along the way.

The bug is bad on its own. What makes it a story is how Google handled it. O’Leary reported it on March 8. On March 27 a Google security engineer accepted the report, called it a nice catch, filed an internal bug to get it fixed, and told him to set up his payout. Google marked the case P1/S1, the highest priority and severity it uses.

Eleven days later an automated Google bot reversed that decision. The panel ruled the flaw was working as intended and did not qualify for a reward. A few weeks later, Google’s own CVE team refused to assign a tracking number, saying they did not believe it was a vulnerability.

Months on, the case still sits open as P1/S1, accepted, with no patch and no payout. It is hard to square calling the flaw working as intended while it sits open as a top-severity bug still marked for a fix. Yet that is exactly where things stand.

The timing is hard to ignore. Before O’Leary reported the flaw, Config Connector was not even on Google’s list of products that qualify for a reward. Twelve days after his report, it quietly turned up on that list, at the lowest payout level there is.

Google’s own reward rules put full takeover of an organization in their top payout bracket. This is exactly that, and it paid nothing. Google does reward cloud bugs well when it chooses to. Another researcher was paid 75,000 dollars this year for a flaw in Google’s own production systems, also met with a nice catch. The zero here is not a tight budget. It is a decision that this particular finding does not count.

Google’s defense goes like this. The attack only works if someone gave Config Connector very high rights across the organization, and doing that, Google says, goes against good practice. The problem: Google’s own setup guides walk you through giving the tool exactly those rights, with copy-paste examples, and never warn you off it. O’Leary’s point is plain. The danger is not how much power the tool holds. The danger is that it never checks whether the person asking is allowed to use that power.

This is also not a new kind of flaw for Google. Tenable Research found the same confused-deputy pattern twice before, in Cloud Run (ImageRunner) and in Cloud Composer (ConfusedComposer). Both times Google’s first answer was that the service account needs its permissions to function. Both times Google gave in, and added the missing check that makes sure the person is actually allowed before the tool acts. Those fixes shipped in early 2025. The same fix has not reached Config Connector.

Not everyone in security agrees with O’Leary, and that is fair to say out loud. Some people read it the other way. Config Connector is built to carry out whatever the files tell it to do, so the rights handed to the tool are, in practice, rights handed to whoever can drop a file in front of it. Read like that, this is not a bug. It is the tool doing its job.

There is a hole in that argument. Google already added the missing check to two other products when the same thing showed up there. A company does not quietly fix something twice if it is simply how the tool is meant to work.

The shape of this keeps repeating: a bug gets fixed quietly while the finder walks away with no money and no credit. O’Leary ran into it with Microsoft earlier this year too, reporting a privilege-escalation flaw in Azure Backup for AKS that Microsoft rejected and then quietly patched, with no CVE and no advisory. Around the same time, a researcher going by Nightmare Eclipse stopped reporting privately at all and started dropping Windows and Defender zero-days in public, after saying Microsoft fixed reported bugs without paying or crediting the work. Different vendors, same shape. The fix happens, the recognition does not.

There is one more turn. After deciding the flaw was not worth paying for, Google’s reward team asked O’Leary to send them a link if he wrote it up, so they could take a look, and maybe share it from their own account. The company that would not pay for the finding wanted his write-up to pass around.

O’Leary did something so this kind of flaw cannot just vanish. Start with what a CVE is. A tracked security flaw gets a CVE, a short public ID that security teams use to look it up, follow the fix, and check whether they are exposed. No number, and for most tools the flaw may as well not exist.

For its own products, Google is the one who hands out those numbers. Refuse to give a flaw a CVE, and it slips off the radar defenders watch.

O’Leary is in a position to change that. He signed up as an independent numbering authority, GNA-119, under GCVE, a newer system that lets trusted outsiders hand out these IDs without going through the usual gatekeepers. GCVE is run by CIRCL, the national cyber response center of Luxembourg. He is one of only two individual researchers cleared to do it so far.

He will not use it on his own work, and that is the point. A number you hand your own bug proves nothing, so he sends his findings to another authority to check, and ConfigConfusion still carries no ID at all. The bigger point is not about this one bug. A vendor can refuse a cloud flaw a number, and a trusted outsider can now hand it one anyway. The quiet-fix trick stops working.

What the fix looks like

The repair is the same one Google already wrote twice. Before Config Connector acts on a request that touches an organization, a folder, or a billing account, it should confirm that the Kubernetes user behind the request holds the matching Google Cloud permission, for example resourcemanager.organizations.setIamPolicy. That check is missing across most of the resource types Config Connector manages, which is why this reaches so far beyond a single object.

And it gets worse. Config Connector handles more than 530 of these resource types through over a hundred separate controllers, and almost none of them check whether the request is even allowed before they act. The one controller that does any validation only checks that things stay inside the same project, not whether the person had the right to ask. At least 32 resource types carry the same gap. The authorization check that would close it is the same one Google already shipped for Cloud Run and Cloud Composer. It just never reached this tool.

What to do while it stays unpatched

• → Check whether your clusters run Config Connector with organization-level permissions, which is the setup Google’s own docs recommend for managing multiple projects
• → Watch your Google Cloud audit logs for IAM changes at folder or organization level that did not come through your normal GitOps pipeline
• → Tighten who can run kubectl apply in any namespace, since that single permission is all the attack needs
• → Open a support case with Google and ask why the check that fixed ImageRunner and ConfusedComposer has not reached Config Connector

Config Connector runs with high privileges, gets tricked into acting for someone who should not have access, and leaves the trail pointing at the tool instead of the attacker. Getting a small bit of access and turning it into full control, holding on to that access after a reboot, slipping deeper into a network, and doing all of it without getting caught are the kind of skills my ethical hacking course walks you through, step by step:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

OLearySec | Tenable ConfusedComposer | Tenable ImageRunner