That massive GitHub supply chain attack? It all started with a stolen SpotBugs token

But this mystery isn't over yet, Unit 42 opines

That massive GitHub supply chain attack that spilled secrets from countless projects? It traces back to a stolen token from a SpotBugs workflow - exposed way back in November, months earlier than previously suspected.

After "piecing together the stages" of the tj-actions/changed-files compromise, Palo Alto Networks' Unit 42 threat hunters concluded attackers used a leaked Personal Access Token (PAT) from SpotBugs to shift over to reviewdog, and ultimately tamper with the popular tj-actions/changed-files GitHub Action to quietly stash developers' secrets in log files.

"The attackers obtained initial access by taking advantage of the GitHub Actions workflow of SpotBugs, a popular open-source tool for static analysis of bugs in code," Omer Gil, Aviad Hahami, Asi Greenholts, and Yaron Avital said in an April update to their analysis from last month.

"This enabled the attackers to move laterally between SpotBugs repositories, until obtaining access to reviewdog," the team wrote, adding that the attack started in November 2024, "but only came to light months later."

As a refresher: This fairly complicated caper was spotted in mid-March by StepSecurity, which provides security for GitHub Actions. At the time, the software firm said miscreants compromised tj-actions/changed-files - a GitHub Action used to track file changes in projects - and rigged it to dump secrets from continuous integration (CI) workflows straight into build logs.

Unit 42 says the attacker first poked at Coinbase's agentkit repo, a dry run that went nowhere, before shifting focus to poisoning an open source supply chain on GitHub.

More than 23,000 GitHub repositories used the change detection tool. In the case of public repositories or others where its logs are publicly available, any project using the altered tj-actions/changed-files would surreptitiously leak secrets - API keys, passwords, access tokens, and the like - in a way that anyone could see if they knew where to look, in workflow logs.

This compromise, we're told, happened sometime between March 10 and March 14.

A few days after that discovery, on March 16, researcher Adnan Khan and later Wiz suggested the tampering with that GitHub Action may have started with another GitHub code review tool, reviewdog, after a suspicious commit was clocked in the reviewdog/action-setup repository.

The reviewdog maintainer later confirmed their project was compromised via a stolen PAT. This allowed the attackers to poison the Action, which was used as a dependency by tj-actions/eslint-changed-files - itself a dependency of the widely used tj-actions/changed-files Action. "This attack potentially led to the compromise of additional actions, notably the widely used tj-actions/changed-files action, causing repositories to leak secrets," they said.

But wait, there's more

As Unit 42's threat hunters dug deeper, they discovered this supply chain attack likely began even earlier than expected. In November, a maintainer of the SpotBugs project - which uses static analysis to detects bugs in Java code – modified a workflow in the spotbugs/sonar-findbugs repository to use their own PAT as a secret.

According to Unit 42, this happened on November 28, and about a week later, on December 6, "the attacker submitted a malicious pull request to spotbugs/sonar-findbugs, which exploited a GitHub Actions workflow that used the pull_request_target trigger."

This is serious, because a pull_request_target trigger allows workflows running from forks to access secrets in the original repo — the PAT, in this particular case — and can result in a so-called poisoned pipeline execution attack.

Thanks to that trigger, the malicious pull request leaked the SpotBugs' maintainer's PAT to the attacker, who created a GitHub account called jurkaofavak and on March 11 used the maintainer's stolen private token to add that new account to SpotBugs as a maintainer. Two minutes later, jurkaofavak was able to push a SpotBugs branch containing a malicious workflow.

"We have confirmed with [the SpotBugs' maintainer] that the PAT that was used as a secret in this workflow was the same PAT that later invited jurkaofavak to the spotbugs/spotbugs repository," Unit 42 said.

As we now know, the malicious workflow leaked the PAT of a reviewdog maintainer who had permission to edit both the reviewdog/action-setup and spotbugs/spotbugs repositories.

"By reviewing the indicators of compromise, and speaking to the maintainers of the involved repositories, we estimate that this PAT had access to both spotbugs/spotbugs and to reviewdog/action-setup," they wrote.

Using that stolen token, the attacker overrode reviewdog/action-setup's v1 tag and caused it to point to a malicious commit, according to Unit 42, which continued:

• After this, tj-actions/changed-files's CI workflow was invoked
• This workflow uses the tj-actions/eslint-changed-files GitHub Action as a pipeline dependency, which in turn depends on and runs the malicious code at reviewdog/action-setup
• The malicious code stole a GitHub token that had write permission to tj-actions/changed-files

This stolen token allowed the attacker to override all tags in tj-actions/changed-files and point them to another malicious commit that leaked workflow secrets for projects using the now-compromised code.

Despite apparently uncovering the initial access point, the investigation is far from over, according to Unit 42.

"Given the attacker's modus operandi of multiple attack stages, stealthy operations and attempts to erase all traces of malicious activity, we still have a mystery to solve," the researchers note. "Having invested months of effort and after achieving so much, why did the attackers print the secrets to logs, and in doing so, also reveal their attack?" ®