ConfigConfusion: One YAML File to Become Organization Owner in…

ConfigConfusion exploits Google Kubernetes Config Connector to escalate from a namespace user to Organization Owner without GCP credentials. Google initially accepted the report as P1/S1, then reversed course, classifying it as "working as intended" and declining to issue a patch.

On September 23, 2026, researcher Justin O'Leary disclosed ConfigConfusion, an architectural vulnerability in Google Kubernetes Config Connector (KCC) that allows a user with access to a Kubernetes namespace to escalate to Organization Owner of a GCP organization. Three lines of YAML and roughly five seconds are all the exploit requires. Google accepted the report as P1/S1 on March 27, 2026, then rejected it as "working as intended" without releasing a patch.

Key Takeaways

A Kubernetes user with permission to create IAMPolicyMember in their namespace becomes a GCP Organization Owner without possessing any cloud credentials
Google accepted the report as P1/S1 on March 27, 2026; 11 days later, a Security Bot reversed the decision with the rationale "working as intended"
The same company patched identical confused deputy patterns in Cloud Run (ImageRunner, January 2025) and Cloud Composer (ConfusedComposer, April 2025)
AWS ACK and Azure Service Operator adopt architectures that limit blast radius by separating controllers or using per-namespace identities

How the Confused Deputy Works Between Kubernetes and GCP

The mechanism exploits a structural disconnect between two authorization systems. Kubernetes RBAC governs who can create an IAMPolicyMember resource in the cluster. GCP IAM governs who can modify organization policies. Neither system verifies that the user submitting the Kubernetes resource is authorized to obtain the requested GCP privilege.

Config Connector operates as an intermediary with a dedicated service account, typically granted organization-level privileges to manage cross-project resources. When a Kubernetes user creates an IAMPolicyMember referencing an external organization, KCC executes the GCP operation using its own identity, not that of the original user. The Kubernetes user never needs GCP credentials or access to the service account.

O'Leary classified the flaw as CWE-441 (confused deputy). The vulnerability does not reside in an implementation bug, but in the absence of an end-to-end authorization check across the two trust domains. As the researcher told The Register: "The vulnerability is the missing authorization check. Config Connector executes privileged operations on behalf of users without verifying those users are authorized."

From "Nice Catch!" to "Not a Vulnerability": The Disclosure Timeline

O'Leary's disclosure documents a sequence of reversals in the case handling. On March 27, 2026, a Google engineer responded to the report: "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." The case was classified P1/S1, the highest priority, and the bounty payment process was initiated.

Eleven days later, on April 7, 2026, a Google Security Bot automatically reversed the decision: "Working as intended. The Config Connector Service Account requires the organization admin role for the reported scenario to be exploitable which is not recommended and breaks best practice." This rationale conflicts with Google's official documentation, which presents the org-level KCC configuration as a supported feature — not as a discouraged practice.

On May 1, 2026, the Google CNA declined CVE assignment with the rationale: "We do not believe it is a vulnerability." Despite this, as of June 18, 2026, the case still held P1/S1 "In Progress (Accepted)" status in the internal tracking system. Roughly three months later, on September 23, 2026, the vulnerability remains unpatched according to media coverage.

"Three lines, five seconds, full admin control."
— Justin O'Leary, describing the exploit

ImageRunner and ConfusedComposer: Same Pattern, Different Treatment

O'Leary's documentation highlights that Google patched similar confused deputy patterns in other services. ImageRunner, discovered by Tenable in January 2025, exploited a confused deputy in Cloud Run to gain unauthorized access to container registry. ConfusedComposer, also from Tenable in April 2025, used an analogous disconnect in Cloud Composer. Both were patched by Google.

The three cases share the same CWE-441 mechanism. According to DeafNews analysis, the difference in treatment raises questions about bug bounty governance that the brief cannot resolve with certainty: the precise reason for maintaining P1/S1 status despite the rejection is marked as UNKNOWN in available sources.

O'Leary summarized the dynamic in an interview with The Register: "This is a pattern. This is just how these trillion-dollar companies deal with people like me." The Register confirmed the pattern reference citing Liv Matan of Tenable.

Why the Missing Audit Trail Makes Detection Difficult

A concrete operational consequence concerns traceability. GCP operations executed by Config Connector are attributed to the KCC service account, not the Kubernetes user who submitted the resource. The GCP event log shows the controller's identity, not the subject who originated the request.

This disconnect makes detection based on direct correlation between Kubernetes events and GCP operations impractical. A SOC analyst observing the creation of an organization-level IAMPolicyMember would see a legitimate operation executed by an authorized service account, with no indicator that the request originated from a namespace user.

The brief does not specify operational mitigations for this scenario. AWS ACK and Azure Service Operator v2 adopt alternative architectures: controller separation or per-namespace identities, which limit the blast radius of similar operations. These are documented configurations of competing services, not recommendations applicable to KCC.

What to Do Now

Information is based on available sources, with limitations stemming from the lack of a structured advisory from Google. Verified facts in the dossier indicate the following:

Verify whether KCC is configured with organization-level scope in your environment; the feature is officially documented by Google and implemented since release 1.27.0
Recognize that GCP operations executed by KCC do not report the original Kubernetes user's identity in logs
Note that Google classified the case "working as intended" and declined CVE assignment; as of September 23, 2026, no patch has been released
Consider that Google treated technically analogous patterns in Cloud Run and Cloud Composer as vulnerabilities to be fixed

According to DeafNews analysis, the discrepancy between initial acceptance (P1/S1 with "Nice catch!") and subsequent rejection ("working as intended" with the qualifier "not recommended and breaks best practice") documents an internal contradiction in Google's assessments, not resolvable with current sources.

Editorial Close

ConfigConfusion exemplifies a class of architectural risks that cross platform boundaries: the confused deputy is not an isolated code bug, but a trust disconnect between systems operating in cascade. The case is notable for the documented contrast between Google's official practice (org-level support in KCC) and the Security Bot's classification (practice "not recommended"), as well as for the maintenance of P1/S1 status despite formal rejection.

The lack of a structured advisory from Google limits the ability to assess real impact on GCP tenants. Available sources — O'Leary's blog, BleepingComputer and The Register reporting, and KCC GitHub documentation — provide a solid factual basis but do not allow independent verification of internal Google communications.

Information has been verified against cited sources and is current as of publication.

Sources

Sources and references

Get DeafLetter