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

Key takeaways

• The flaw sat in how Gerrit permissions and CI workflows interacted.
• Supply chain flaws spread because many projects trust the same tool.
• Limit CI permissions and review who can submit changes.

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

In early 2026, a critical supply chain vulnerability known as GerriScary (CVE-2025-1568) exposed 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. This post covers 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 is 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.

To take this further with guided labs and an instructor, see our learning DevSecOps practices.

Related reading

• How Did Microsoft Copilot Get Hacked? Root Access Vulnerability Explained with Full Technical Details (July 2025)
• What is a real-world example of bypassing 2FA due to OAuth misconfiguration?
• WhatsApp for Windows Spoofing Vulnerability (CVE-2025-30401) | How Hackers Can Execute Malicious Code Using File Attachment Trick

Reference

For the authoritative details, see National Vulnerability Database.