Google’s Gerrit Platform Flaw Exposes 18 Google Projects, Including ChromiumOS, to Hackers
A critical vulnerability, dubbed “GerriScary,” has been discovered in Google’s Gerrit code-collaboration platform, putting at least 18 major Google projects—including ChromiumOS, Chromium, Dart, and Bazel—at risk of unauthorized code submissions by hackers.
This flaw, uncovered by Tenable Cloud Research, highlights the dangers of misconfigured permissions in open-source development environments and the potential for large-scale supply chain attacks.
The GerriScary Vulnerability
Gerrit, developed by Google, is a widely used web-based system for code review and collaboration.
It allows developers to propose, discuss, and approve code changes before they are merged into project repositories.
However, Tenable researchers found that a combination of default permissions and logic flaws in Gerrit’s review process could allow any registered user to inject malicious code into trusted Google projects without detection.
The vulnerability centers on two main Gerrit mechanisms: permissions and labels. Permissions define what actions users can perform, while labels (or “Submit Requirements”) are used to gatekeep which code changes are eligible for merging.
In many Google projects, the default “addPatchSet” permission was granted to all registered users, allowing them to upload new versions of existing code changes—even if they were not the original author.

The real danger emerged from a misconfiguration in the way Gerrit handles label “Copy Conditions.” In the affected projects, label approvals—such as “Code-Review” and Google’s custom “Commit-Queue”—were set to persist across new patch sets, even if the underlying code changed.
This meant that a code change could be fully approved and ready for merging, and an attacker could then inject malicious code as a new patch set without resetting the approval status.
Attackers could automate the process by monitoring for code changes that had already received all necessary approvals, then racing to upload a malicious patch set just before Google’s automated bots merged the change into the repository.
In some cases, this race window was as long as five minutes, providing ample opportunity for exploitation.
Impacted Projects and Immediate Actions
The vulnerability affected at least 18 major Google projects, including ChromiumOS (CVE-2025-1568), Chromium, Dart, and Bazel. The vulnerability allowed unauthorized code submission to these projects before remediation.
Project Name | Description | Notable CVE(s) |
ChromiumOS | Open-source OS powering ChromeOS devices | CVE-2025-1568 |
Chromium | Open-source browser project (basis for Chrome) | |
Dart | Programming language for client development | |
Bazel | Build and test tool for large codebases | |
Third-party Chromium packages | Community-maintained Chromium components | |
… | (Additional projects as per Appendix A) |

While Google has since remediated the flaw in its own projects by tightening permissions and correcting label copy conditions, the risk remains for third-party organizations that use Gerrit and have not reviewed their configurations.
Security experts warn that any organization using Gerrit should immediately audit their permissions, especially the “addPatchSet” setting, and review their label copy conditions to ensure that approvals are not improperly retained across code changes.
The GerriScary incident underscores the importance of rigorous access control and configuration management in open-source development.
Industry leaders like Google can fall victim to subtle misconfigurations that open the door to sophisticated supply chain attacks. As software supply chains become more complex, the need for robust security practices and continuous monitoring is more pressing than ever.
Organizations are urged to learn from Google’s experience and proactively safeguard their own development pipelines against similar vulnerabilities.
Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates
Source link