ConfigConfusion: Missing Authorization Check in GCP Config Connector Lets a Kubernetes Namespace User Seize Organization Owner
ConfigConfusion (TL-2026-2629), also tracked as ConfigConfusion, is a critical-severity software vulnerability, first published 2026-09-23. It has no confirmed attribution, affects Google Config Connector (KCC) for Google Kubernetes Engine, maps to 8 MITRE ATT&CK techniques (T1078.004, T1098.003, T1136.003), and is covered by 9 detection rules and 7 indicators of compromise.
Key facts for TL-2026-2629
- Threat ID
- TL-2026-2629
- Also known as
- ConfigConfusion
- Severity
- CRITICAL
- Status
- ACTIVE
- Category
- VULNERABILITY
- First published
- 2026-09-23
- Last reviewed
- 2026-09-23
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, cloud-computing, software-as-a-service
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 7
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.
How ConfigConfusion works
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 techniques used in TL-2026-2629
Defense Evasion
Privilege Escalation
T1098.003 Additional Cloud Roles
Persistence
T1098.003 Additional Cloud Roles; T1136.003 Cloud Account
Initial Access
Discovery
T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery; T1613 Container and Resource Discovery
Execution
Affected products and versions in ConfigConfusion
- Google — Config Connector (KCC) for Google Kubernetes Engine
Vulnerable versions: all Config Connector deployments as of September 2026 (architectural design flaw, not a specific version regression)
Remediation for ConfigConfusion
Patches
- No vendor patch exists — Google classified the reported behavior as 'working as designed' on 2026-04-07 and has not committed to a fix
Immediate actions
- Audit every IAMPolicyMember, IAMPartialPolicy, and other Config Connector custom resource with an organizationRef, folderRef, or billingAccountRef external field for unexpected or unauthorized target IDs
- Restrict, via Kubernetes RBAC, which namespaces and users can create IAM-related Config Connector custom resources (IAMPolicyMember, IAMPartialPolicy, IAMPolicy)
- Review and revoke any organization- or folder-level IAM bindings that do not correspond to an approved, tracked change
- Inventory which of the 32+ Config Connector CRDs accepting organizationRef/folderRef/billingAccountRef are enabled in each cluster
Workarounds
- Run Config Connector exclusively in namespaced mode with narrowly scoped, per-team service accounts
- Disable or strictly gate creation of IAMPolicyMember/IAMPartialPolicy resources with organizationRef or folderRef targets outside a trusted platform-team namespace
- Enforce organization policy constraints limiting which principals can hold organization-level Owner/Organization Admin roles
Longer-term hardening
- Migrate Config Connector from cluster mode (single shared service account) to namespaced mode with per-namespace, least-privilege service accounts
- Remove organization- and folder-level IAM roles from Config Connector service accounts unless a specific, documented use case requires them
- Deploy policy-as-code admission control (e.g. OPA/Gatekeeper, Kyverno) to validate or block IAM-related CRDs targeting organization/folder/billing scope before they reach Config Connector
- Continuously monitor organization- and folder-level Cloud Audit Logs for IAM policy changes originating from Config Connector (cnrm-controller-manager) service accounts
Weaknesses (CWE) in ConfigConfusion
CWE-441, CWE-863, CWE-269
Timeline of ConfigConfusion
- Google patches Tenable Research's 'ImageRunner' confused-deputy privilege-escalation flaw in GCP Cloud Run (and a related 'ConfusedComposer' flaw in Cloud Composer) by adding requester-identity authorization checks — the same class of fix O'Leary later argues Google should apply to Config Connector for ConfigConfusion.
- Justin O'Leary privately reports the ConfigConfusion authorization-bypass flaw in Google Kubernetes Config Connector to Google.
- A Google security engineer accepts the report as a valid vulnerability, telling O'Leary 'Nice catch!' and classifying it at the highest internal priority and severity (P1/S1).
- Google's Vulnerability Reward Program reverses the engineer's determination via an automated Security Bot notice, stating the report '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' and that granting such scope 'goes against Google Cloud's publicly shared best practices' — denying the bug-bounty reward and committing to no fix.
- The same researcher, Justin O'Leary, discloses a parallel confused-deputy privilege-escalation flaw in Microsoft Azure Backup for AKS (Backup Contributor to cluster-admin via Trusted Access) to Microsoft; MSRC rejects the report on 2026-04-13 but Microsoft silently patches the issue without a CVE or advisory.
- The Register, Dark Reading, and Cybernews publish coverage of ConfigConfusion, reporting the bug remains tracked internally at Google as P1/S1 'in progress (accepted)' with no CVE and no fix roughly three months after the initial report, alongside the parallel Azure Backup for AKS confused-deputy flaw found by the same researcher.
- BleepingComputer publishes a technical deep-dive, 'How one Kubernetes YAML can hand over a GCP organization,' detailing the exploit mechanics and defensive mitigations; Google's 'working as designed' position and the absence of a patch remain unchanged.
Sources cited for ConfigConfusion
- 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
- 'Confused Deputy' Flaws Persist in Google Cloud, Microsoft Azure
- ConfigConfusion: GCP IAM Authorization Bypass — Google Said 'Nice Catch' Then Left It Unpatched
- Google thanks researcher for finding major flaw but doesn't fix it and pays no reward
- Access control with IAM (Config Connector documentation)
- GoogleCloudPlatform/k8s-config-connector (source repository)
- ImageRunner: A Privilege Escalation Vulnerability Impacting GCP Cloud Run
More in vulnerability
- cPanel/WHM CalDAV/CardDAV and WP Toolkit Flaws Enable Cross-Account Access and Root Privilege Escalation (CVE-2026-68490, CVE-2026-87899, CVE-2026-87900)
- CVE-2026-94127: Critical F5 BIG-IP APM Zero-Day Heap Overflow in OAuth Authorization Server Exploited for Unauthenticated Remote Code Execution
- Eclypsium InfraTrust Report: Mass Active Exploitation of Network Management Systems (Cisco FMC/ISE CVE-2026-20079, CVE-2026-76460; SonicWall SMA 1000 CVE-2026-83548/83549; Linux Kernel CopyFail CVE-2026-31431)
- OAuth Token Theft via Sideloaded AppX Packages Abusing Microsoft-Signed Web Hosts (WWAHost.exe)
- CVE-2026-87902: Critical Unauthenticated Local File Inclusion in WordPress Core (Conditional RCE)
Detection coverage for TL-2026-2629
As of 2026-09-23, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2629 across Splunk SPL, Microsoft KQL and Sigma, covering 7 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.