Google Told Researcher 'Nice Catch!' Then Denied Bug Bounty For Flaw It Still Hasn't Fixed (theregister.com)
- Reference: 0183965376
- News link: https://it.slashdot.org/story/26/06/18/1656252/google-told-researcher-nice-catch-then-denied-bug-bounty-for-flaw-it-still-hasnt-fixed
- Source link: https://www.theregister.com/security/2026/06/18/google-told-researcher-nice-catch-then-denied-bug-bounty-for-flaw-it-still-hasnt-fixed/5258076
> According to O'Leary, Config Connector doesn't perform an authorization check, and this allows any Config Connector service account with org-level permissions to bypass Identity and Access Management (IAM) authorization and gain the highest level of control (roles/owner) to an entire GCP Organization -- the root node of all of a company's resources within Google Cloud. On March 27, a Google security engineer accepted O'Leary's report and told him: "Nice catch!" The employee said that they filed a bug based on O'Leary's report with the relevant product team and assured him the Chocolate Factory's security squad would work with relevant Google Cloud people to fix the flaw. "We'll work with the product team to ensure this issue is address. We'll let you know when the issue was fixed," the engineer said. "In the meantime, review the payment option selected in your bughunters.google.com profile."
>
> Google assigned the bug P1 priority and S1 severity, signifying a flaw worthy of urgent repair because it affects a large percentage of users and can disrupt core organizational functions. "I figured that was the end of that," O'Leary said in a phone interview with The Register. Eleven days later, on April 7, he received a new message from a Google Security Bot reversing the earlier decision. The Reg viewed the email, and O'Leary included a screenshot in his Thursday writeup. The message said that the Cloud Vulnerability Reward Program panel decided that the "security impact of this issue does not meet the criteria to qualify for a reward."
>
> After reviewing the bug report, Google determined the software "is working as intended," the message continued. It also noted that the program's decision not to pay a bounty "does not mean that the product team won't fix the issue." Nearly three months later, the case remains P1/S1 with the status "in progress (accepted)." Google hasn't assigned a CVE or issued a fix. O'Leary didn't receive any reward for his research. [...] "This is a pattern," O'Leary told [The Register]. "This is just how these trillion-dollar companies deal with people like me. In my day job, we use GKE, and it's incredibly frustrating on my end, when I find a critical vulnerability in the system that's being widely used, and I can't even get the vendor to patch their own stuff."
A Google spokesperson told The Register: "The issue reported does not qualify for a reward because the GCP IAM authorization bypass 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). Additionally, 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, such as the IAM bypass. Granting this level of access to the Config Connector Service Account goes against Google Cloud's publicly shared best practices and the principle of least privilege."
[1] https://www.theregister.com/security/2026/06/18/google-told-researcher-nice-catch-then-denied-bug-bounty-for-flaw-it-still-hasnt-fixed/5258076
[2] https://olearysec.com/research/config-connector-authorization-bypass
Well then (Score:3)
You know what to do, security researchers. Next time you find an exploit just publish it, because Google obviously doesn't want your feedback.
Re: (Score:2)
Sell it on the open market and you'll profit.
This is why "responsible disclosure" isn't (Score:4, Interesting)
This isn't the first, or the tenth, or the hundredth time this has happened to some security researcher dealing with some company. And even when their research is properly acknowledged and credited, the payouts are pitifully small. The entire concept of "responsible disclosure" is to guilt people who don't work for companies into free labor for them, donating it, and then receiving neither credit nor fair compensation.
It's time to discard not just the practice, but the entire concept, because the industry has proven that it concocted this nonsense as a one-sided deal, and that it will screw anyone/everyone at every possible opportunity. It's time for researchers to abandon any attempt to collaborate with companies, because it doesn't work .
What should they do instead? Just drop the vulnerabilites and let the companies deal with the fallout. They're too cheap, too lazy, and in too much of a hurry to make sure their products/services are secure before they start selling them, so they deserve what they get. Let them burn.
No. Not at all. (Score:2)
You should still disclose the vulnerability to the company, and tell them they have 90 days before you publish it.
If you just publish it, you are putting all their users at immediate risk of being exploited by criminals who view your publication and immediately weaponize it. That is why you must disclose it to the company first, so they can get a fix out BEFORE you go public with it.
If you are unwilling to do this, then don't publish the finding.
Re: (Score:1)
"No responsible disclosure" means just that. No 90 day window because that's still "responsible disclosure". Why should I give 90 days grace for a bounty that isn't going to be paid anyway?
Re: (Score:2)
You should give a 90 day window so you don't become an enabler of crime.
The bug bounty is there to incite you to look for bugs at all. If there isn't a bug bounty program, or you don't think it will pay out, then don't go looking for bugs.
If you find a bug anyway, and want to do the right thing, then you responsibly disclose it (whether you get paid or not). If you don't want to do the right thing, then you just ignore the bug and don't publish it.
If you publish the bug without giving the company 90 days
Seems defensible. (Score:5, Interesting)
From their bounty program page at [1]https://bughunters.google.com/... [google.com] :
"Insecure customer configurations (such as unconditionally injecting shared secrets or misconfiguring security-related settings) rather than a product vulnerability.}
If their published standards indicate that giving the connector that level of admin permissions is excessive, and the access needed to exploit this is as clearly a set of poor security management as the last paragraph of the summary implies, then, "Yes, it should be corrected, and no, it's not bounty worthy" seems a reasonable stance to take. It sits right in the zone of that definition.
You could have the argument, but it's not clear to me that Google has it wrong.
[1] https://bughunters.google.com/about/rules/google-friends/cloud-vulnerability-reward-program-rules#non-qualifying-vulnerabilities
Re: Seems defensible. (Score:2)
> If their published standards indicate that giving the connector that level of admin permissions is excessive, and the access needed to exploit this is as clearly a set of poor security management as the last paragraph of the summary implies, then, "Yes, it should be corrected, and no, it's not bounty worthy" seems a reasonable stance to take. It sits right in the zone of that definition.
> You could have the argument, but it's not clear to me that Google has it wrong.
Well I am sure they are not wrong in that they have legal cover to refuse the bounty.
I think they probably are wrong in excluding all config related bugs from their bounty program. Chained exploits are becoming increasing attack vectors so "you need elevated privileges" is not the moat it used to be. And GCP takeover is a big cost to bear. "We can prove it was your fault for not reading our docs carefully enough" will probably not be the salve their customers want in case of exploit. Security is hard and pr
Re: (Score:3)
If you are going to pay for misconfigurations the sky really is the limit.
I'm gonna AI me a new minivan! (Score:2)
There's no guarantees on bugs, because they should be discouraged in all cases.
Re: (Score:2)
How would it have damaged Google to (a) give credit where it's due and (b) cut a $50,000 check?
Answer: not at all.
In fact, it would help them, because it'd go a little way toward repairing the reputation they've spent the past several years damaging. And it'd be a far better choice -- in every possible way -- than trying to weasel out of it as they've done in this case.
What Google (and Microsoft, and others) have done by abusing the good faith and trust of security researchers has convinced a lot
Re: (Score:2)
But how much credit is really due when the literal purpose of the tools to run as a Service Account with scoped permissions to sync changes from Kubernetes to GCP. There should be some pretty serious warnings saying that whatever access you give the Service Account is the access you gave... But the whole point of the tool is to shift from making changes directly in GCP to be in Kubernetes through a proxy Service Account.
Bug bounties bleeding dry by people overstating severity is also damaging.
Re: (Score:2)
It's more than reasonable. The whole point of the product is make configs in Kubernetes format and a Service Account will sync the changes. So in essence roles that are given to the Service Account are basically given to users who direct the Service Account on what to do.
User --(Creates)--> Kubernetes Custom Resource which define GCP Settings --(Watched by)--> Config Connector --(Sync as Service Account with scoped access)--> GCP Config
If you give the Service Account rights to edit permissions, the
Nightmare Eclipse (Score:4, Insightful)
Pay the bounty.
The two other possible outcomes are Nightmare Eclipse (she's really on a roll!) or 0day sales on DNM's.
It doesn't even matter whether a decision to fix is made.
Gosh, you'd think $GOOG was broke.
Overstating (Score:2)
This one sure seems overstated though. How much should corps dish out just to avoid fragile egos, if those people didn't really find something notable?
We want to keep the backdoor a bit longer (Score:3)
Google: Nice Catch!
NSA: Hey, we still need it!
Google: Invalid and we don't fix it any time soon.
Re: (Score:2)
This is what happened
LLM trained on security breaches are getting real good at finding tiny security flaws, probably unwinding years or even decades of intentional security flaws for various agencies
Re: (Score:2)
Google Non-Specialist: Nice Catch!
Actual Engineering Team: It's not a bug. Proxied access through a Service Account is the whole point of what this product does. Maybe our docs should have more warnings or we should put in [1]another layer like the competing tool [crossplane.io] if people are going to get confused and shoot themselves in the foot.
Google Non-Specialist: Invalid, but we'll keep a case open to idiot-proof already acceptable behavior.
[1] https://docs.crossplane.io/v2.3/managed-resources/managed-resource-activation-policies/
The new Google motto (Score:3)
Pick from any of the following:
-- Don't be good
-- Don't be sensible
-- Don't be responsible
-- Don't be averse to being a dickhead
It would be great if somebody sponsored a "choose a new motto for Google" contest. Maybe Louis Rossman - he'd likely have the balls to do it if YouTube wasn't so important for him. Hell, he might do it anyway - he seems like a really scrappy give-zero-shits kind of guy.
Toldl (Score:2)
Child-like behavior, sounds like they are acting like little toldlers.