CVE-2025-25204 - How a Simple Exit Code Bug in `gh attestation verify` Could Threaten Your Artifact Security

In early 2025, security researchers discovered a critical yet subtle vulnerability in GitHub’s official command line tool, gh, affecting versions 2.49. through 2.66.x. Assigning it CVE-2025-25204, this flaw lurked in the gh attestation verify command—GitHub’s Artifact Attestation verification utility. For those using automation to maintain the integrity of software supply chains, this bug can silently open the gates for malicious artifacts.

Let’s break down the issue, see how it can be exploited, and, most importantly, how to fix it.

What is gh attestation verify?

For continuous integration (CI) and development pipelines, artifact attestation is crucial. It’s a cryptographic way to check:
Was this artifact built by someone I trust?

Has anyone tampered with it?

GitHub introduced artifact attestation and verification to help automate these checks. Most CI scripts will run something like:

gh attestation verify --artifact ./build/output.tar.gz

If the verification *fails*—say, if the required attestation is missing or invalid—the program is supposed to return a *non-zero* exit code. This lets your script abort further steps, so unsafe code never gets deployed.

The Vulnerability: Wrong Exit Code On Missing Attestations

From gh 2.49. to 2.66.x, if you ran gh attestation verify on an artifact with _no_ attestations, the tool exited with a zero exit code.
Zero () means “success” in UNIX and almost all scripting languages.

Instead of failing, your CI/CD pipeline or deployment script would see “all clear!” even though *no* verifications happened. A zero-exit code prevents scripts from noticing that something went wrong.

Let’s see how a threat actor could use this bug

1. Setup: A company’s deployment pipeline requires attestation for every artifact. The final deployment step checks:

Expected Behavior: gh attestation verify should return non-zero, aborting deployment.

4. Actual (Buggy) Behavior: With CVE-2025-25204, the tool returns (success), and the artifact gets deployed, bypassing the gatekeeper!

This scenario can be generalized to any pipeline relying on exit codes from gh attestation verify, making the impact very broad.

Here’s a minimal demonstration

# Use a version of gh before v2.67.
gh --version
# gh version 2.66. (for example)

# Prepare a sample artifact (no attestations)
touch harmless.txt

# Run the verification
gh attestation verify --artifact harmless.txt

# Check exit code
echo $?
# Output:  (should be non-zero!)

If this result shows , and there really were no attestations, you have a vulnerable installation.

Why Is This Dangerous?

Most CI/CD deployments and security controls rely on return codes to automate decisions. Developers and infosec teams expect that a verification process returns an error code if anything is wrong, including if data is *missing*.
When these expectations are broken, malicious actors can exploit the gap to bypass what seem like robust security checks.

The worst part? This can happen silently—artifact verification *looks* like it succeeded, but in reality, nobody checked anything.

How to Fix: Update Immediately

The bug was patched in gh version 2.67..

Upgrade gh to at least v2.67. on all CI servers, developer machines, and automation environments.

- Audit your artifacts and deployments for any suspicious activity if you used earlier vulnerable versions.

Quick Upgrade

gh version
# If below 2.67., upgrade:
gh upgrade
# Or use your package manager, e.g.:
brew upgrade gh
# Or download the latest from https://github.com/cli/cli/releases

References

- GitHub Security Advisory for CVE-2025-25204
- Official gh CLI releases
- Artifact Attestation Docs
- OpenSSF on Supply Chain Security

Summary

CVE-2025-25204 in GitHub’s gh CLI is a reminder that even something as simple as a return code can have huge consequences for software supply chain security. If you use gh attestation verify to safeguard artifact deployment, make sure you’re running version 2.67. or above, and always check those return codes!

Timeline

Published on: 02/14/2025 17:15:19 UTC