Between 31 January and 1 April 2021, an unauthorized party periodically altered Codecov's Bash Uploader script so it could send data from customers' CI environments to a remote server. A customer spotted a checksum mismatch. The lesson for defenders is simple: a script piped into your build runs with your secrets, so verify it and keep secrets out of reach.
What happened, in order?
All dates below come from Codecov's own security update.
- 31 January 2021. Periodic, unauthorized alterations of the Bash Uploader begin.
- 1 April 2021. A customer reports that the checksum of the downloaded uploader does not match the one published on GitHub. Codecov secures and remediates the script the same day, after learning of the access.
- 15 April 2021. Codecov emails affected users and adds a banner in the application.
- 29 April 2021. Codecov updates its notice with more detail on which environment variables may have been obtained and how they may have been used.
Codecov states that the only change was a single added line, which sent the output of the git remote and environment commands to a third-party server, and that there were 108 windows between 31 January and 1 April when the altered script was active.
How did the attacker get in?
Codecov attributes the access to an error in its Docker image creation process that let the actor extract the credential needed to modify the script. A secondary analysis describes a credential left in an intermediate layer of a public image. We rely on Codecov's own wording as the primary account.
What was exposed?
Per Codecov, credentials, tokens or keys present in the CI environment when the script ran, the services and data reachable with them, and git remote information. Several other companies later reported effects from the incident. We do not repeat their individual accounts here, because we did not verify them against primary sources.
What did Codecov tell users to do?
Run the environment command in CI to see which keys and tokens were present, invalidate and regenerate the sensitive ones, audit how they were used, check any locally stored copy of the uploader for the malicious line, and replace it. Users who verified a checksum before running the script may not have been affected.
What should defenders learn?
Detection came from outside. A customer comparing checksums found the problem. Checksum verification of downloaded scripts is cheap and it worked.
Secrets in CI are the real prize. The script ran inside builds, where environment variables hold deploy keys and tokens. Anything a build can read, a compromised build step can read.
Piping a remote script into a shell is trust without verification. The fix is to pin a version, verify a checksum or signature, or vendor the file after review.
Rotation is the recovery plan. If you cannot list the secrets in your CI and rotate them within a day, a similar event will hurt more.
What to do
- List every secret available to each CI job. Remove the ones a job does not need.
- Prefer short-lived tokens issued per job over stored long-lived credentials.
- Pin third-party scripts and actions by version or digest, and verify checksums or signatures.
- Restrict outbound network access from build runners to the hosts they need.
- Alert on unexpected changes to artifacts you publish for others to download.
- Practise a rotation drill for your CI secrets.
- Keep a record of which third-party tools run in your pipelines.
Quick check
Would a dependency scanner have caught this?
Not by itself. This was a modified script, not a package with a known flaw. Checksum verification, pinning and monitoring of CI behaviour address it.
Is this still a risk today?
The same pattern, a trusted build helper altered at its source, remains relevant. The controls above apply to any such tool.
Sources
Last reviewed: 18 October 2026.
