Justin O’Leary spotted trouble in Google’s Kubernetes tools. He reported it. Google called it a sharp find. Then everything flipped.
The security researcher detailed a vulnerability he named ConfigConfusion. It sits inside Config Connector, Google’s open-source Kubernetes operator for managing cloud resources. Any user with access to a single Kubernetes namespace could bypass Google Cloud Platform identity controls. Full organization owner privileges followed in seconds. No extra permissions required from the Google IAM side.
O’Leary filed his report on March 8. The Register broke the story today. He followed with his own technical write-up. The details paint a picture of initial praise followed by outright rejection.
A Google security engineer responded on March 27. “Nice catch!” the message read. The engineer filed an internal bug, assigned it P1 priority and S1 severity. Those labels signal urgent attention. The note promised coordination with the product team and updates on a fix. It even pointed O’Leary toward his bug bounty profile for payment options.
O’Leary thought the process was underway. Eleven days passed. Then a security bot delivered different news. The Cloud Vulnerability Reward Program panel reviewed the case. It decided the issue did not meet reward criteria. The software operated “as intended,” the panel ruled. No payout. The bug report stayed open. No CVE issued. No patch applied.
Months later the case remains listed as in progress. O’Leary received nothing. He shared the full timeline and code analysis in his post at olearysec.com.
The flaw centers on missing authorization checks. Config Connector runs with elevated service account permissions at the organization level. It needs those rights to handle resources across clusters. Yet it fails to verify whether the Kubernetes user requesting an IAM change holds the proper rights.
An attacker crafts three lines of YAML. They target an IAMPolicyMember resource. The object passes a user-controlled organization ID straight to the GCP IAM API. Config Connector acts on it using its own privileged credentials. The attacker’s Kubernetes identity never appears in GCP logs. The new owner binding takes effect. Complete control arrives.
CVSS scores it critical. 10.0. Network attack. Low complexity. The scope changes. Confidentiality, integrity and availability all suffer high impact. It persists even if Kubernetes access gets revoked. Gmail accounts or other identities can be added as organization owners.
Google pushed back. Its spokesperson told The Register the scenario requires a privileged Config Connector service account already granted Organization Admin rights. That setup violates least-privilege best practices, the company said. An attacker would also need initial environment access, such as an exposed container.
O’Leary rejects that framing. Google’s own documentation shows organizations configuring Config Connector with broad permissions. The operator exists to simplify management at scale. A developer with kubectl in one namespace should never escalate to organization owner. The absence of validation creates a classic confused deputy problem.
This marks the third time Google addressed similar issues in different services. Tenable researchers found ImageRunner in Cloud Run and ConfusedComposer in Cloud Composer. Both allowed privilege escalation through hidden service permissions. Google added checks after those reports. Config Connector still lacks them despite overlapping patterns.
Liv Matan from Tenable described the pattern as “Jenga” vulnerabilities. Interconnected cloud services hide permission assumptions. One misstep collapses layers of assumed safety. O’Leary sees the same architecture flaw here across more than 30 custom resource definitions and over 100 controllers.
The code tells the story. In pkg/controller/iam/iamclient/externalonly.go, lines 46-51 simply copy the external organization reference without checking the caller’s rights. Simple. Direct. And unvalidated.
Enterprise teams run Google Kubernetes Engine at massive scale. They depend on Config Connector for declarative management. A namespace compromise now threatens the entire organization. Secrets. Billing. Projects. All of it.
But the real story runs deeper than one bug. O’Leary calls it a pattern. He faced identical treatment from Microsoft earlier this year on an Azure Backup vulnerability. The company rejected his report, then patched quietly without a CVE or advisory.
The Register has covered parallel cases with AI vendors and other cloud providers. Researchers report critical issues. Companies label them intended behavior. Fixes arrive without credit or transparency. Bug hunters grow frustrated.
Google’s Vulnerability Reward Program paid out more than $17 million in 2025 to 747 researchers, according to SC Media. Record totals. Yet individual cases reveal friction. The program includes appeal options. O’Leary tried. New information is preferred. The panel held firm.
His appeal cited the prior fixed vulnerabilities. Google had recognized the class before. Why treat this instance differently? The response stayed consistent. Privileged service accounts should not be configured that way. Case closed.
O’Leary works in cloud environments daily. His team uses GKE. Finding a serious flaw in widely deployed tooling only to watch it linger creates professional tension. “This is just how these trillion-dollar companies deal with people like me,” he told The Register.
The disclosure raises questions about accountability. Public bug bounty programs promise rewards for valid findings. High severity ratings suggest internal agreement on risk. Yet the final verdict can shift without clear technical rebuttal.
Config Connector remains unpatched as of today. Organizations cannot simply toggle a setting. Mitigation means removing the operator entirely or accepting the exposure. Not ideal for teams built around it.
And the pattern continues. Recent Medium posts describe similar Google VRP rejections. One detailed forced closures and “intended behavior” labels even after clarification. Another highlighted documentation excuses for access control problems.
Google maintains strong overall security. Its programs have paid millions. Thousands of bugs fixed. Yet these edge cases erode trust among the very researchers the company courts.
O’Leary published anyway. He demonstrated the attack in video. Three lines. Five seconds. Organization takeover. The YAML is public. Attackers now have a blueprint.
Google did not close the internal case. It did not assign a CVE. It did not dispute O’Leary’s right to disclose. The flaw sits in limbo. High priority on paper. Dismissed in practice.
Cloud security rests on clear boundaries. When operators act as deputies without checking intent, those boundaries dissolve. Enterprises pay for perceived safety. They deserve more than “working as intended” when the intention leaves them exposed.
The conversation will not end here. Other researchers watch these cases. They weigh effort against recognition. Vendors track the signals too. How they respond shapes who bothers to report next time.
For now O’Leary moves on. The bug stays. And Google still calls it a nice catch.
WebProNews is an iEntry Publication