Skip to navigation

Threat reportVulnerabilityTL-2026-2629

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

criticalACTIVE

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.

Key facts

IdentifiersTL-2026-2629
Also known asConfigConfusion
SeverityCRITICAL
Affected productsGoogle Config Connector (KCC) for Google Kubernetes Engine
Weaknesses (CWE)CWE-441, CWE-863, CWE-269
MITRE ATT&CK techniquesT1078.004 Cloud Accounts, T1098.003 Additional Cloud Roles, T1136.003 Cloud Account, T1199 Trusted Relationship, T1526 Cloud Service Discovery, T1580 Cloud Infrastructure Discovery, T1609 Container Administration Command, T1613 Container and Resource Discovery
MotivationUNKNOWN
Target sectorstechnology, cloud-computing, software-as-a-service
Target regionsGlobal
Detection rules9 (1 shown free)
Sources8 cited sources

Detection coverage

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. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: ConfigConfusion — Config Connector Service Account Grants Org/Folder/Billing-Level Owner via IAMPolicyMember

Detects the ConfigConfusion confused-deputy exploitation step: a per-namespace cnrm-controller-manager Config Connector service account executes a SetIamPolicy call that grants roles/owner, roles/resourcemanager.organizationAdmin, or roles/resourcemanager.folderAdmin at Organization/Folder/BillingAccount scope. Because KCC never validates that the requesting Kubernetes identity holds equivalent GCP authority, any org-level grant originating from a cnrm-controller-manager identity is inherently suspicious — legitimate org-level IAM changes should come from human admins or dedicated IAM-governance service accounts, not a GKE workload-identity-bound controller SA.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1199, T1609, T1068
  • Data sources: gcp_cloud_audit_logs_admin_activity, kubernetes_api_audit_log_gke, splunk_ta_google_cloud_platform
  • Severity: critical
  • Confidence: high

Splunk SPL

index=gcp_audit sourcetype="google:gcp:audit"
    protoPayload.methodName IN ("SetIamPolicy","google.iam.v1.IAMPolicy.SetIamPolicy")
    protoPayload.authenticationInfo.principalEmail="*cnrm-controller-manager*"
``` isolate org/folder/billing-scoped policy pushes performed by the KCC controller identity ```
| eval target_type=case(
    match(protoPayload.resourceName, "^organizations/"), "organization",
    match(protoPayload.resourceName, "^folders/"), "folder",
    match(protoPayload.resourceName, "^billingAccounts/"), "billingAccount",
    1=1, "project")
| where target_type IN ("organization","folder","billingAccount")
| spath input=protoPayload.request path=policy.bindings{} output=bindings
| mvexpand bindings
| spath input=bindings
``` flag only the high-privilege roles the ConfigConfusion PoC uses for org takeover ```
| where role IN ("roles/owner","roles/resourcemanager.organizationAdmin","roles/resourcemanager.folderAdmin")
| eval granted_member=mvindex(members, 0)
| table _time protoPayload.authenticationInfo.principalEmail target_type protoPayload.resourceName role granted_member protoPayload.requestMetadata.callerIp
| rename protoPayload.authenticationInfo.principalEmail as controller_identity, protoPayload.resourceName as target_resource, protoPayload.requestMetadata.callerIp as caller_ip
| sort - _time

Microsoft KQL

GCPAuditLogs_CL
| where TimeGenerated > ago(24h)
| where MethodName_s in ("SetIamPolicy", "google.iam.v1.IAMPolicy.SetIamPolicy")
| where PrincipalEmail_s has "cnrm-controller-manager"
| where ResourceName_s has_any ("organizations/", "folders/", "billingAccounts/")
| mv-expand Bindings = todynamic(PolicyBindings_s)
| extend Role = tostring(Bindings.role)
| where Role in ("roles/owner", "roles/resourcemanager.organizationAdmin", "roles/resourcemanager.folderAdmin")
| extend GrantedMember = tostring(Bindings.members[0])
| project TimeGenerated, ControllerIdentity = PrincipalEmail_s, TargetResource = ResourceName_s, Role, GrantedMember, CallerIp = CallerIp_s
| sort by TimeGenerated desc

Sigma

title: Config Connector Service Account Grants Organization/Folder/Billing-Level Owner Role
id: 6f2b1e34-9a3d-4c7e-8b1a-2d5f7c9e0a11
status: experimental
description: |
  Detects a GKE Config Connector (KCC) cnrm-controller-manager service account
  executing SetIamPolicy against an Organization, Folder, or BillingAccount
  resource and granting roles/owner or an equivalent org-admin role. This is
  the exploitation signature of ConfigConfusion, a confused-deputy flaw where
  KCC never validates that the Kubernetes user requesting the IAMPolicyMember
  change holds equivalent GCP IAM authority.
references:
  - https://www.bleepingcomputer.com/news/security/how-one-kubernetes-yaml-can-hand-over-a-gcp-organization/
  - https://olearysec.com/research/config-connector-authorization-bypass/
author: Threadlinqs Team
date: 2026-09-23
tags:
  - attack.initial-access
  - attack.t1199
  - attack.execution
  - attack.t1609
  - attack.privilege-escalation
  - attack.t1068
  - attack.t1098.003
logsource:
  category: cloud
  product: gcp
  service: cloud_audit
detection:
  selection_method:
    protoPayload.methodName:
      - 'SetIamPolicy'
      - 'google.iam.v1.IAMPolicy.SetIamPolicy'
  selection_identity:
    protoPayload.authenticationInfo.principalEmail|contains: 'cnrm-controller-manager'
  selection_scope:
    protoPayload.resourceName|contains:
      - 'organizations/'
      - 'folders/'
      - 'billingAccounts/'
  selection_role:
    protoPayload.request.policy.bindings.role:
      - 'roles/owner'
      - 'roles/resourcemanager.organizationAdmin'
      - 'roles/resourcemanager.folderAdmin'
  condition: selection_method and selection_identity and selection_scope and selection_role
falsepositives:
  - A deliberately provisioned, documented platform-team migration that intentionally re-parents org-level IAM via an approved Config Connector change window
level: critical

Known false positives:

  • An approved, change-managed org-restructure or migration deliberately performed through Config Connector by the platform team with a documented ticket

Tuning notes: Field names assume Cloud Audit Logs ingested via the Splunk Add-on for Google Cloud Platform / a custom Sentinel GCP audit-log connector into GCPAuditLogs_CL; adjust JSON paths to match the actual TA/connector schema. Maintain an allowlist of any cnrm-controller-manager service accounts that are legitimately scoped to org/folder level (there should normally be none per Google's own best practices) to suppress expected noise.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • ConfigConfusion — Config Connector Service Account Grants Org/Folder/Billing-Level Owner via IAMPolicyMember · unlock with TL Creds
  • ConfigConfusion — Persistence via New Service Account/Key Created by a Recently Org-Owner-Granted Principal · unlock with TL Creds
  • ConfigConfusion — Cross-Project Blast-Radius Enumeration by a Valid Cloud Account Following Org-Level Grant · unlock with TL Creds
  • Config Connector Service Account Grants Organization/Folder/Billing-Level Owner Role · unlock with TL Creds
  • Recently Org-Owner-Granted Principal Creates GCP Service Account or Key · unlock with TL Creds
  • Broad Cross-Project GCP Resource Enumeration Following Org-Level IAM Grant · unlock with TL Creds
  • ConfigConfusion — Persistence via New Service Account/Key Created by a Recently Org-Owner-Granted Principal · unlock with TL Creds
  • ConfigConfusion — Cross-Project Blast-Radius Enumeration by a Valid Cloud Account Following Org-Level Grant · unlock with TL Creds

Indicators of compromise

As of 2026-09-23, Threadlinqs Intelligence tracks 7 indicators of compromise for TL-2026-2629.

7 indicators of compromise · unlock with TL Creds. Compare plans

Technical analysis

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.

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 by tactic:

Defense Evasion

T1078.004 Cloud Accounts

Privilege Escalation

T1098.003 Additional Cloud Roles

Persistence

T1098.003 Additional Cloud Roles; T1136.003 Cloud Account

Initial Access

T1199 Trusted Relationship

Discovery

T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery; T1613 Container and Resource Discovery

Execution

T1609 Container Administration Command

Remediation

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

Affected and fixed versions

  • 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)

Timeline

  • 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

Previous and next in vulnerability

Drafted by the Threadlinqs research pipeline from 8 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats