Google Gerrit Vulnerability Exposes 18 Projects, Including ChromiumOS

A critical vulnerability in Google’s Gerrit code-collaboration platform allowed unauthorized actors to inject malicious code into at least 18 high-profile Google projects, including ChromiumOS, Dart, and Bazel, according to research by Tenable Cloud Research.

Dubbed GerriScary (CVE-2025-1568), the vulnerability exposed supply chain risks by exploiting misconfigured permissions and automated review processes, enabling attackers to bypass critical security checks.

Google has since remediated affected repositories, but third-party organizations using Gerrit remain at risk unless they reassess their configurations.

The Gerrit platform, a cornerstone of Google’s open-source development workflow, enables contributors to propose and review code changes before merging them into projects.

However, Tenable researchers discovered that Gerrit’s default permissions granted any registered user—a group requiring only a Google account—the ability to modify existing code submissions via the “addPatchSet” privilege.

This permission, intended to streamline collaboration, became a liability when paired with misconfigured label persistence rules in projects like ChromiumOS.

Gerrit’s label system, designed to enforce approval requirements (e.g., “Code-Review +2”), failed to reset votes when new code patches were added.

Attackers could hijack already-approved changes, append malicious code, and rely on retained approvals to auto-merge tainted updates.

Worse, many projects automated merges via bots that prioritized speed over re-review, creating a race condition window.

By injecting code into a change seconds before a bot processed it, attackers could execute 0-click exploits without human oversight.

Google Gerrit Vulnerability

The exploitation relied on three interconnected vulnerability. First, the permissive “addPatchSet” privilege let attackers modify any active code change.

Second, Gerrit’s “Copy Conditions” mechanism—meant to preserve approvals for minor revisions—improperly carried over labels like “Commit-Queue +2” even after significant code alterations.

Third, automated merge bots operated on delays (5 minutes in ChromiumOS), giving attackers time to sabotage submissions.

Tenable demonstrated this by injecting benign test comments into ChromiumOS and Dart projects.

In one instance, a ChromiumOS code search tool publicly displayed their proof-of-concept alteration, confirming the vulnerability viability.

Researchers also developed scanning tools to identify vulnerable projects, leveraging HTTP status codes (e.g., “209” responses) to detect misconfigured permissions without triggering alerts.

This revealed widespread exposure across Google’s ecosystem, including infrastructure tools like Bazel and cryptographic libraries like BoringSSL.

Mitigations

Google responded by overhauling label persistence settings to invalidate approvals after patch updates, forcing re-reviews for all changes.

The ChromiumOS team also restricted “addPatchSet” to trusted contributors, closing the door to anonymous exploits.

However, these fixes apply only to Google-managed projects. Thousands of third-party Gerrit instances remain vulnerable if they retain default configurations or lax label rules.

The incident underscores the fragility of open-source collaboration tools when security guardrails are overlooked.

While Google’s rapid remediation limits immediate risks, the broader lesson resonates: platforms balancing openness with security must rigorously audit permission models and submission workflows.

As Tenable notes, Gerrit’s complexity—particularly its opaque “Copy Conditions” syntax—likely contributed to misconfigurations, urging organizations to adopt least-privilege principles and continuous configuration monitoring.

In an era where supply chain attacks dominate cyberthreat landscapes, GerriScary serves as a stark reminder that even tech giants are not immune to oversight in their development ecosystems.

While Google’s proactive patches mitigate the threat, the onus now shifts to the global open-source community to harden Gerrit instances against similar logic- vulnerability exploits.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.