# ConfigConfusion: Missing Authorization Check in GCP Config Connector Lets a Kubernetes Namespace User Seize Organization Owner

> ConfigConfusion is an unpatched confused-deputy flaw in Google Kubernetes Config Connector (KCC): a user with only Kubernetes namespace access and permission to create an IAMPolicyMember resource can grant themselves roles/owner on the entire GCP organization, because KCC's service account executes the IAM change with its own elevated credentials without ever validating that the requesting Kubernetes identity is authorized to make it. Google rated the report P1/S1, initially praised it ('Nice catch!'), then reversed course, called it 'working as designed,' denied the bug bounty, and has issued no fix.

- **Published:** 2026-09-23T00:00:00Z
- **Last reviewed:** 2026-09-23T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2629
- **ID:** TL-2026-2629
- **Severity:** CRITICAL
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 7 (full data via the Threadlinqs MCP server — Purple tier)

## Description

Config Connector (KCC) is Google's Kubernetes operator for managing GCP resources declaratively via Kubernetes manifests. Independent researcher Justin O'Leary found that KCC contains a textbook confused-deputy vulnerability: Kubernetes RBAC checks whether a user may create a given custom resource in a namespace, but Google Cloud IAM only ever sees and authorizes the KCC controller's own service-account identity — it never learns, and never checks, which Kubernetes user actually requested the change.

The result is that a user with zero Google Cloud credentials of their own, but with kubectl access to a namespace where they can create an IAMPolicyMember custom resource, can submit a manifest that grants an arbitrary principal (e.g. an external, attacker-controlled GCP service account or a freshly created Gmail-based account) the roles/owner role scoped to the organization, by setting resourceRef.kind to Organization and resourceRef.external to the target org's numeric ID. The per-namespace cnrm-controller-manager pod, authenticated to GCP via Workload Identity Federation for GKE, then impersonates its bound IAM service account and pushes the binding to Cloud Resource Manager exactly as written, in roughly five seconds, with no re-validation of the originating user's own (nonexistent) GCP permissions.

The root cause is architectural rather than a single coding bug: every Config Connector CRD that accepts an organizationRef, folderRef, or billingAccountRef with a user-controlled external field inherits the same trust gap, putting 32+ CRDs in the KCC API surface at risk of the identical class of escalation, not just IAMPolicyMember. Once granted, the malicious IAM binding is a normal, persistent organization-level policy entry — it survives revocation of the attacker's original Kubernetes namespace access entirely, since GCP IAM has no record that the grant was ever tied to that Kubernetes identity in the first place. An org-level roles/owner grant carries full administrative control over every descendant project, IAM policy, Secret Manager secret, and the billing account.

O'Leary reported the issue to Google on 2026-03-08. A Google security engineer initially accepted it as valid, telling him 'Nice catch!' and classifying it at the highest internal priority and severity (P1/S1). On 2026-04-07 Google reversed that determination via an automated Security Bot response, telling O'Leary the behavior is 'working as intended,' declining to pay a bug-bounty reward, and not committing to any fix — a decision that, per subsequent reporting, still stood as of the most recent coverage. The same researcher separately reported and demonstrated a parallel confused-deputy privilege-escalation flaw in Microsoft Azure Backup for AKS earlier in 2026; Microsoft silently patched that issue without assigning a CVE or publishing an advisory, in contrast to Google's public non-fix stance on ConfigConfusion. No CVE has been assigned to ConfigConfusion and no CVSS score has been published for it.

Because Google does not consider this a vulnerability, defenders running Config Connector must self-remediate: move to namespaced mode with narrowly scoped, per-namespace service accounts instead of a single cluster-wide service account; strip organization- and folder-level IAM roles from KCC service accounts wherever project-level scope suffices; gate which namespaces/teams may create IAMPolicyMember, IAMPartialPolicy, and other organizationRef/folderRef/billingAccountRef-bearing CRDs; and continuously monitor organization- and folder-level IAM policy changes attributable to Config Connector service accounts via Cloud Audit Logs / Security Command Center.

## MITRE ATT&CK

- T1199 Trusted Relationship
- T1580 Cloud Infrastructure Discovery
- T1613 Container and Resource Discovery
- T1526 Cloud Service Discovery
- T1609 Container Administration Command
- T1098.003 Additional Cloud Roles
- T1098.003 Additional Cloud Roles
- T1136.003 Cloud Account
- T1078.004 Cloud Accounts

## Sources

- [How one Kubernetes YAML can hand over a GCP organization](https://www.bleepingcomputer.com/news/security/how-one-kubernetes-yaml-can-hand-over-a-gcp-organization/)
- [Google told researcher 'Nice catch!' Then denied bug bounty for flaw it still hasn't fixed](https://www.theregister.com/security/2026/06/18/google-told-researcher-nice-catch-then-denied-bug-bounty-for-flaw-it-still-hasnt-fixed/5258076)
- ['Confused Deputy' Flaws Persist in Google Cloud, Microsoft Azure](https://www.darkreading.com/cloud-security/confused-deputy-flaws-google-cloud-microsoft-azure)
- [ConfigConfusion: GCP IAM Authorization Bypass — Google Said 'Nice Catch' Then Left It Unpatched](https://olearysec.com/research/config-connector-authorization-bypass/)
- [Google thanks researcher for finding major flaw but doesn't fix it and pays no reward](https://cybernews.com/security/google-refuses-to-pay-bug-hunter/)
- [Access control with IAM (Config Connector documentation)](https://docs.cloud.google.com/config-connector/docs/how-to/configure-iam-permissions)
- [GoogleCloudPlatform/k8s-config-connector (source repository)](https://github.com/GoogleCloudPlatform/k8s-config-connector)
- [ImageRunner: A Privilege Escalation Vulnerability Impacting GCP Cloud Run](https://www.tenable.com/blog/imagerunner-a-privilege-escalation-vulnerability-impacting-gcp-cloud-run)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2629