GerriScary Vulnerability Explained | How CVE-2025-1568 Hacked 18 Google Projects via Gerrit Supply Chain Flaw

Table of Contents

• What Is GerriScary (CVE-2025-1568)?
•  How the GerriScary Exploit Works – Step-by-Step
•  Breakdown of the Attack Flow
• Projects Affected by GerriScary
•  Why This Happened: Misconfigurations and Oversights
•  How Google Responded to GerriScary
• Broader Implications of GerriScary
• Lessons for Developers and Organizations
• Is Your Gerrit System Safe?
• What Makes GerriScary Truly Scary?
• Future of Supply Chain Security Post-GerriScary
•  Conclusion
•  Frequently Asked Questions (FAQs)

In early 2025, a critical supply chain vulnerability known as GerriScary (CVE-2025-1568) rocked the cybersecurity world by exposing 18 major Google projects—including ChromiumOS, Chromium, Dart, and Bazel—to the risk of malicious code injection. This flaw, which stems from a misconfiguration in Google's code review tool Gerrit, demonstrated how even minor permission oversights and race conditions in CI/CD pipelines can be exploited by attackers to gain unauthorized access to production systems. In this blog, we’ll explore the technical mechanics of GerriScary, how it was exploited, its impact, and what developers and organizations can learn from this vulnerability.

What Is GerriScary (CVE-2025-1568)?

GerriScary is a supply chain vulnerability that targeted Google Gerrit, an open-source web-based team code collaboration tool used for code review. The exploit relied on a combination of:

• Default permission misconfiguration (addPatchSet)

  
  

• Race conditions in Gerrit's approval and commit processes

• Lack of patch validation after approval

This allowed an attacker to submit malicious code to projects that relied on Gerrit without triggering standard security flags or requiring administrative-level access.

How the GerriScary Exploit Works – Step-by-Step

1. Attacker pushes a legitimate-looking code update to a Gerrit-hosted project.

2. Developer reviews and approves the update, assuming it’s safe.

   
   

3. A race condition in Gerrit fails to revalidate the patch when a +2 approval is given.

4. Attacker uses the addPatchSet permission (granted to all registered users) to quickly push a modified, malicious patch to the already-approved change.

5. The automated bot merges the change into the live project before another human review occurs.

6. Malicious code is now part of the official project—without triggering alerts.

 Breakdown of the Attack Flow

• The attacker submits malicious code.

• Developer unknowingly approves it.

• Gerrit’s flawed commit process allows attacker to inject harmful code.

• The bot merges the code without re-checking the update.

• The live Google project is now compromised.

Projects Affected by GerriScary

At least 18 Google-hosted projects were impacted by this vulnerability. While not all were confirmed publicly, these are among the known affected:

• Chromium

• ChromiumOS

• Dart

• Bazel

• Several Android development libraries

• Build tools and internal infrastructure components

The vulnerability left these projects open to remote code execution, malware injection, and supply chain compromise affecting downstream users and developers.

Why This Happened: Misconfigurations and Oversights

The root causes of the GerriScary vulnerability are:

• Insecure default permission: Gerrit’s addPatchSet allowed all registered users to update approved changes.

• Lack of post-approval validation: Once a patch was approved, Gerrit failed to revalidate the updated patch.

• Race condition timing: The exploit was time-sensitive, with the attacker slipping in a malicious patch right before the bot executed the merge.

How Google Responded to GerriScary

Google acted swiftly after the disclosure:

• Revoked the addPatchSet permission for regular users on sensitive projects.

• Updated Gerrit to revalidate patches even after approval.

• Launched an internal audit of other open-source project workflows.

• Issued patches and updates across impacted repositories.

These responses have helped secure Google’s open-source ecosystem, but the exploit has raised broader concerns about the security of software supply chains.

Broader Implications of GerriScary

GerriScary isn’t just a bug—it’s a warning sign for the entire software industry. Here’s why:

• Supply chain attacks are increasingly targeting CI/CD systems and code review tools.

• Open-source projects are particularly vulnerable due to collaborative workflows.

• Race conditions are hard to detect, often overlooked in security testing.

• Default permissions in developer tools must be hardened to a zero-trust model.

Lessons for Developers and Organizations

To protect your CI/CD systems from similar threats, adopt the following best practices:

1. Review and restrict permissions: Never grant write or patch rights to general users.

2. Validate every change after approval: Ensure that bots or tools do not auto-merge without rechecking.

3. Use commit signing and verification: Sign patches and require trusted certificates.

4. Scan for race conditions: Use static and dynamic analysis tools in your development pipeline.

5. Audit your tooling configuration: Tools like Gerrit, GitLab, and Jenkins must be securely configured.

6. Adopt Zero Trust in your DevSecOps: Assume nothing is safe without verification—even inside your team.

Is Your Gerrit System Safe?

If your development environment uses Gerrit, here’s how to harden it:

• Disable addPatchSet for non-core developers.

• Enable patch revalidation triggers.

• Deploy audit logs for patch changes post-approval.

• Monitor all bot-triggered merges for anomalies.

• Integrate security gates between code approval and final merge stages.

What Makes GerriScary Truly Scary?

It wasn't a flaw in the code—it was a flaw in process and trust. The attacker didn't break in—they walked through the front door using valid permissions and precise timing. GerriScary proves that supply chain threats aren't just about what you code—but also how you code, review, and deploy.

Future of Supply Chain Security Post-GerriScary

The software industry must prioritize:

• Zero-trust code contributions

• Automated patch diff tools

• Behavioral analysis of contributor accounts

• Permission audits and dynamic access controls

• Open collaboration on CI/CD security standards

Final Thoughts

The GerriScary vulnerability is a wake-up call for developers, DevOps teams, and open-source maintainers. As supply chain attacks evolve, so must our development pipelines. It’s not enough to secure your code—you must secure the way your code gets approved, merged, and deployed. Tools like Gerrit must be configured with security-first principles, and every team must treat CI/CD infrastructure as part of their attack surface.

FAQ:

What is the GerriScary vulnerability?

GerriScary is a critical supply chain vulnerability (CVE-2025-1568) that allowed attackers to inject malicious code into major Google projects by exploiting misconfigurations in Gerrit’s code review system.

What does CVE-2025-1568 refer to?

CVE-2025-1568 is the official identifier for the GerriScary vulnerability, which targeted Gerrit’s permission settings to bypass secure code submission protocols.

How did the GerriScary exploit work?

Attackers pushed a patch, waited for approval, then used a race condition to inject a malicious update before automated bots could revalidate the code, effectively tricking the system.

Which Google projects were affected by GerriScary?

At least 18 projects were impacted, including ChromiumOS, Chromium, Dart, Bazel, and other major open-source tools hosted in Google's infrastructure.

How did attackers bypass Gerrit’s approval process?

They used a race condition between patch approval and bot revalidation, exploiting Gerrit’s auto-merge behavior when the commit queue hit +2.

What is the role of the addPatchSet permission in this attack?

The addPatchSet permission allowed any authenticated user to push patch updates to existing changes, enabling attackers to overwrite approved code stealthily.

Why is GerriScary considered a supply chain vulnerability?

It targeted the software supply chain by compromising development infrastructure and injecting code before public release, affecting downstream consumers unknowingly.

How does a race condition enable malicious code injection?

A race condition occurs when two actions compete in timing; here, attackers updated code just before bots rechecked it, causing the malicious patch to be merged unchecked.

What are the dangers of insecure Gerrit permissions?

Insecure permissions like addPatchSet allow unverified users to alter approved changes, bypassing code review and compromising project integrity.

How did bots auto-merge malicious code in GerriScary?

Once a patch was approved, bots like the commit queue merged it automatically without detecting last-second changes made by attackers.

What is patch revalidation and why does it matter?

Patch revalidation ensures that the final code being merged is identical to the reviewed version; skipping this step lets malicious changes slip through.

How many Google projects were compromised by this flaw?

The vulnerability affected 18 Google projects, making it one of the largest coordinated internal security exposures in recent years.

Was Chromium or ChromiumOS impacted?

Yes, both Chromium and ChromiumOS were among the 18 affected projects, posing potential risks to millions of downstream users.

Can this vulnerability impact other open-source repositories?

Yes, any open-source project using Gerrit with similar configurations is vulnerable if they don’t enforce secure patch policies.

What is the commit queue +2 in Gerrit?

A commit queue +2 is a flag showing two levels of approval, after which the code is automatically merged by the bot if no blocking issues arise.

How can Gerrit users prevent similar attacks?

Disabling addPatchSet for all but trusted users, enforcing patch revalidation, and implementing timing checks can mitigate such risks.

What are the signs of a Gerrit system being exploited?

Unexpected patchsets, unauthorized commits, or mismatches between reviewed and merged code are common signs of exploitation.

What tools can detect supply chain vulnerabilities like GerriScary?

Tools like SLSA (Supply-chain Levels for Software Artifacts), GitGuardian, and SAST/DAST solutions can help detect anomalies in CI/CD pipelines.

Is the CVE-2025-1568 vulnerability still active?

No, patches have been released and the misconfigurations have been addressed in the latest Gerrit updates, but older instances may still be vulnerable.

How can developers audit their Gerrit permissions?

Use Gerrit’s access rights page to review project roles, audit addPatchSet usage, and ensure only trusted users have modification privileges.

What is the risk of automatic bot merging in code pipelines?

Automatic bot merging increases speed but can overlook manual revalidation, creating opportunities for race-condition-based attacks.

How fast did Google respond to the GerriScary disclosure?

Google acted promptly once notified, patching affected repositories and improving internal CI/CD security practices across projects.

What makes Gerrit attractive for attackers?

Gerrit is widely used for code reviews in open-source and enterprise environments, making it a prime target for compromising trusted infrastructure.

What is a code supply chain attack?

It’s an attack where the software development process is compromised, allowing malicious actors to inject backdoors before the product reaches users.

Can Gerrit vulnerabilities affect mobile apps?

Yes, if the compromised code makes it into mobile builds (e.g., Chromium-based browsers), mobile apps can indirectly inherit these flaws.

Why didn’t security checks catch the malicious code in GerriScary?

Because the attack relied on updating the code post-approval, it bypassed review checkpoints unless patch revalidation was enforced.

What are the best practices to secure Gerrit configurations?

Restrict sensitive permissions, enforce revalidation policies, limit bot automation triggers, and audit commit histories regularly.

Is Gerrit still safe to use for enterprise development?

Yes, if configured securely with proper access controls and updated with the latest patches, Gerrit remains a powerful and safe code review tool.

What role did CI/CD play in this vulnerability?

The vulnerability exploited automation in the CI/CD pipeline, particularly the timing between code approval and auto-merge actions.

How does GerriScary impact open-source software trust?

It undermines the integrity of open-source by showing that even trusted platforms like Gerrit can be manipulated if not properly secured.

What lessons should developers learn from GerriScary?

Developers should not rely solely on automation, must understand permission settings, and always enforce checks on the final code that gets merged.