Google Denies Bug Bounty for Config Connector Flaw That Could Grant Full GCP Organization Control
Researcher Justin O'Leary discovered a vulnerability in Google's Config Connector Kubernetes operator that lets any namespace user gain GCP Organization Owner access, but Google rejected the bounty, calling it 'working as intended.'
Security researcher Justin O'Leary has uncovered a critical flaw in Google's Config Connector, an open-source Kubernetes add-on used to manage Google Cloud resources. Dubbed ConfigConfusion, the vulnerability allows any Kubernetes namespace user to bypass Google Cloud Platform's Identity and Access Management (IAM) controls and escalate privileges to roles/owner of an entire GCP Organization — the root node of all cloud resources. O'Leary reported the issue to Google on March 8, 2026, and was initially told 'Nice catch!' by a Google security engineer, who assigned the bug the highest priority (P1) and severity (S1) ratings. Yet weeks later, Google reversed course, denied a bug bounty, and claimed the behavior is 'working as intended.' The bug report remains marked as 'in progress (accepted)' nearly three months later, with no fix or CVE issued.
The vulnerability resides in Config Connector's failure to perform proper authorization checks. According to O'Leary, any Config Connector service account with organization-level permissions can be abused by a user with kubectl access to a single Kubernetes namespace — even if that user has zero GCP IAM permissions. The missing authorization check allows the attacker to impersonate any service account and execute commands with administrative authority, including becoming Organization Owner. O'Leary demonstrated the exploit in three lines of code, taking only five seconds to gain full control. Google's own documentation instructs users to grant Config Connector service accounts org-level permissions, making the attack path straightforward for any organization following best practices.
Google's response to The Register downplayed the risk, arguing that the issue is only exploitable if an attacker already has access to a Config Connector service account granted the Organization Admin role — which it says goes against the principle of least privilege. '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,' a Google spokesperson said. The company also noted that an attacker would first need to breach the organization's environment, such as an exposed container. O'Leary counters that Google's own documentation recommends exactly this configuration, and that the core vulnerability is the missing authorization check — not the permissions themselves.
The impact of ConfigConfusion is significant. Config Connector is widely used by enterprises managing multi-cluster GKE environments, and any organization following Google's documented setup is potentially exposed. An attacker who compromises a single namespace — through a vulnerable application, stolen credentials, or a supply-chain attack — could pivot to full cloud takeover without triggering IAM audit logs, since the abuse happens inside the Kubernetes layer. O'Leary noted that the exploit leaves no audit trail in GCP's IAM logs, making detection extremely difficult. The bug remains unpatched, leaving users in a precarious position: either follow Google's documented best practices and remain vulnerable, or restrict Config Connector permissions and lose functionality.
This is not the first time O'Leary has faced such treatment from a major cloud vendor. Earlier this year, he reported a privilege escalation vulnerability in Azure Backup for AKS to Microsoft, which rejected the report and then silently patched the flaw without assigning a CVE or publishing an advisory. 'This is a pattern,' O'Leary told The Register. 'This is just how these trillion-dollar companies deal with people like me.' The incident highlights growing frustration among security researchers who find critical vulnerabilities in widely used cloud infrastructure but are denied bounties or credit, even when the vendor acknowledges the issue internally. Google's decision to keep the bug report open at P1/S1 while denying a fix or reward further erodes trust in its vulnerability disclosure process.
For now, organizations using Config Connector are advised to review their service account permissions and apply strict namespace isolation, though no official mitigation exists. O'Leary has published a detailed blog post with technical specifics, and the security community is calling on Google to either patch the flaw or provide a clear explanation for why it considers the behavior acceptable. The incident underscores a broader challenge in cloud security: when vendors prioritize denial over remediation, the entire ecosystem pays the price.