ConfigConfusion: GCP IAM Authorization Bypass — Google Said 'Nice Catch' Then Left It Unpatched | OLearySec
ConfigConfusion: GCP IAM Authorization Bypass — Google Said 'Nice Catch' Then Left It Unpatched
By Justin O'Leary<br>June 18, 2026<br>None (vendor rejected)
Unpatched
10.0
CVSS 3.1 Base Score · Critical
Critical
CVSS 10.0 CRITICAL · CWE-441 Confused Deputy · UNPATCHED
GCP IAM Authorization Bypass — Any Kubernetes Namespace User Can Become Organization Owner
Config Connector is the attack vector. Every GCP organization running it is exposed. All IAM authorization controls are bypassed.
Google’s internal tracker shows this as P1/S1 — their highest severity. A Google engineer responded “Nice catch!” and filed it for a fix. Then the VRP panel reversed course, dismissing a complete IAM authorization bypass as “working as intended.”
They’re not disputing what it does. They’re disputing who has to fix it.
The Pattern:
Date<br>What Happened<br>Case Status
Mar 27<br>Engineer: “Nice catch! I’ve filed a bug. Set up payment for your reward.”<br>P1/S1 Accepted
Apr 7<br>Panel: “Working as intended. No bounty. (But we may still fix it.)”<br>P1/S1 Accepted
May 1<br>Google CNA to MITRE: “We do not believe it is a vulnerability. ”<br>P1/S1 Accepted
Today<br>Bug remains open. No patch. No bounty.<br>Still P1/S1 Accepted
They’re fixing it. They’re just not paying for it.
Why? According to Google’s Cloud VRP Rules, this vulnerability qualifies for S0b: Cloud Project/Organization Takeover with Full Administrative Control — defined as:
“Gaining the highest level of control over a project, equivalent to roles/owner. This includes the ability to set any IAM policy on any resource, iam.setIamPolicy, manage all service accounts, and control all resources within that project.”
Config Connector is the attack vector — but the impacted product is GCP IAM itself . ConfigConfusion bypasses IAM authorization to grant roles/owner on an entire GCP Organization . The victim isn’t Config Connector — it’s IAM.
Notable timing — from GitHub git history:
Date<br>Evidence<br>Config Connector Status
Nov 5, 2025<br>cloud-tiers.text @ 5b61833<br>Not in file (Ctrl+F “Config Connector” = 0 results)
Mar 8, 2026<br>I submit vulnerability report
Mar 20, 2026<br>cloud-tiers.asciipb @ 3ff4408<br>Added at Tier 3
Config Connector was never in the tier list before my report. It appeared 12 days later , at the lowest payout tier.
I’m calling it ConfigConfusion — a GCP IAM authorization bypass that exploits Config Connector as a confused deputy. It follows the same pattern Google patched in ImageRunner and ConfusedComposer. This time, they refuse to fix it.
The complete attack chain: A Kubernetes namespace user with zero GCP permissions submits a malicious IAMPolicyMember. Config Connector passes the user-controlled organization ID directly to the GCP IAM API with no authorization check. Five seconds later, the attacker is GCP Organization Owner with full administrative control over every project, every secret, and every billing account.
The vulnerability bypasses all GCP IAM authorization controls . Any user with basic Kubernetes namespace access — an intern, a contractor, a compromised CI pipeline — can escalate to GCP Organization Owner without any GCP permissions whatsoever. No resourcemanager.organizations.setIamPolicy. No IAM roles. Just kubectl apply.
The attacker’s Kubernetes identity never touches GCP IAM. Config Connector executes the request using its own elevated credentials. IAM is completely bypassed.
Google patched this exact pattern twice before. They just won’t patch it here.
“Nice Catch!” — Google’s Human Reviewer
On March 27, a Google security engineer reviewed my report and accepted it:
“Nice catch! I’ve filed a bug with the responsible product team based on your report. We’ll work with the product team to ensure this issue is addressed. We’ll let you know when the issue was fixed. ”
“In the meantime, review the payment option selected in your bughunters.google.com profile. We recommend to choose Bugcrowd as the payment provider for your potential reward. ”
— [email protected], March 27, 2026
The case was assigned P1 priority, S1 severity . Status: “In Progress (Accepted)” .
Google engineer accepts the vulnerability and initiates payment process.
The case remains P1/S1 “In Progress (Accepted)” — the status Google assigns to real vulnerabilities.
This is not the response to intended behavior. This is the response to a valid security vulnerability.
“Working as Intended” — Google’s Automated Bot
Eleven days later, Google Security Bot reversed the human reviewer’s decision:
“Cloud Vulnerability Reward Program panel has decided that the security impact of this issue does not meet...