Google to Security Researcher: 'Nice Catch', Then Backtracks on Reward
Google finds itself at the center of a controversy regarding vulnerability management, having initially acknowledged a serious security flaw in a Kubernetes operator, only to later deny its existence and the associated reward.
The researcher Justin O'Leary, an expert in cloud security, reported to Google a flaw that allows any user of a Kubernetes namespace to bypass the Identity and Access Management (IAM) protections of Google Cloud Platform (GCP), thereby gaining full control over the cloud resources of an entire organization. The issue has been dubbed ConfigConfusion.
The vulnerability, found in Config Connector - an open source Kubernetes add-on that allows managing Google Cloud resources through Kubernetes - arises from a lack of authorization verification. According to O'Leary and as reported by The Register, a Config Connector service account with organization-level permissions can bypass IAM authorization and obtain the highest level of control (owner role) over an entire GCP organization, which is the root node of all business resources within Google Cloud.
"Nice catch": Google on the discovery of a security flaw but denies the award to the researcher.
Google responded to O'Leary's report on March 8, assigning the flaw a priority of P1 and a severity of S1, indicating an urgent fix necessary for issues affecting a large percentage of users and potentially disrupting key organizational functions. On March 27, a Google security engineer officially accepted the report, complimenting O'Leary with a "Nice catch!" and assuring that the product team would work to resolve the issue and would notify the researcher upon fixing it, inviting him to check the payment options for the bounty.
Just eleven days later, on April 7, the situation changed drastically. O'Leary received an automatic message from a Google security bot revoking the previous decision. The message stated that the security impact of the issue did not meet the criteria for a reward and that the software "was functioning as intended." Despite this reversal, the bug report remains classified as P1/S1, and its status is still "in progress (accepted)." To date, Google has not assigned a CVE nor released a patch, and O'Leary has not received any compensation.
When asked by The Register, a Google spokesperson explained that the vulnerability is not eligible for a reward because the GCP IAM bypass would only be exploitable if an attacker already had access to a privileged Config Connector service account. Moreover, an attacker would first need to gain access to the organization's environment (for example, an exposed container) to exploit the privileged instance of Config Connector and execute commands with administrative authority. Google emphasized that granting this level of access to the Config Connector service account goes against the public best practices of Google Cloud and the principle of least privilege.
O'Leary dismisses this explanation. He admits that the Config Connector service account requires organization-level permissions to manage resources across multiple GKE clusters, and that Google's own documentation instructs users on how to do so. The key point, however, lies in his argument: "having those permissions does not mean any user of a namespace should be able to abuse them."
The vulnerability, he emphasizes, is precisely the lack of authorization verification: Config Connector performs privileged operations on behalf of users without checking that they are authorized. The case raises some doubts about the transparency and management of bug bounties by large tech companies. O'Leary has commented on the situation with some skepticism: "This is a model. This is how these trillion-dollar companies treat people like me." A perception that could, in the long run, undermine collaboration with the community of independent researchers, pushing them towards less "responsible" paths.