A researcher has described how a vulnerability in GitHub’s CodeQL, a tool for detecting security issues, had the potential to infect most repositories using it, including stealing source code and executing malicious code in workflows, until it was fixed in January this year.

According to the researcher, GitHub has found no evidence of this being used to compromise its platform or systems.

CodeQL scans code for vulnerabilities and the default setup uses GitHub Actions to perform scans on a repository every time code is pushed or on a schedule. It is available for public repositories, and for private repositories that have GitHub Advanced Security, a paid feature.

Researcher John Stawinski at security company Praetorian described how the security tool uses a GitHub token to grant itself permission to a repository. When the tool runs, it generates files that are stored in the repository, called workflow artifacts, which are visible to anyone with read access to that repository. Stawinski discovered that in some cases this file contained environment variables, used to store repository secrets, including this GitHub token. The vulnerability is documented in a GitHub advisory, which is marked as high severity.

This token is quickly invalidated but in a certain version of a CodeQL action which uploads debug artifacts after a failure, the artifacts can be downloaded about a second before it is invalidated. The CodeQL action, which is used by repositories that configure CodeQL, is itself open source so Stawinski researched whether this vulnerability would enable the action to be compromised. He was successful, writing an empty proof-of-concept tag to the CodeQL repository, at which point he reported the problem to GitHub.

“GitHub had one of the most rapid and impressive remediation responses we have ever seen,” said Stawinski, noting that following the report, debug artifact upload in the CodeQL action was disabled just three hours later.

The reason may be that the issue was even worse than it first appeared. Via the vulnerability, Stawinkski could write code to unprotected branches in the CodeQL repository, but even if malicious, this would have to be committed to a production branch before impacting other GitHub repositories using CodeQL. This might be possible via smuggling in “a small malicious change” but would still have to be merged.

The researcher discovered though that if an actor removed and then added a v3 tag to a CodeQL commit, “every single repository using the default CodeQL workflow would execute their malicious code.” This is because CodeQL is not using workflow pinning, removing this risk, even though GitHub recommends this. Since the CodeQL actions “check out the source code of every repository they run on,” this would enable exfiltration of the code from any repository which had enabled it, including private repositories in which there might be hardcoded secrets.

A further risk is that the vulnerability could have been combined with GitHub actions cache poisoning, a technique that enables code execution within action workflows whenever an action-cache is used, even if the token only has read access to the repository.

This adds up to a vulnerability that had the potential to compromise a huge number of public and private repositories and potentially, via exfiltrated secrets, infect internal networks including GitHub’s own systems.

Stawinski’s recommendations include cautions about any workflow artifacts, including scanning them for secrets before uploading, not including environment variables, and limiting token permissions to read-only.

More broadly, he said that “GitHub Actions abuse has been around for several years, but it is still one of the highest-impact, least-understood vulnerability classes. That is slowly starting to change.”

The recent compromise of the tj-actions GitHub Action is another example.

Developers asked why GitHub has not yet made immutable actions generally available. This would reduce the risk from compromised actions, by enabling fixed package versions, semantic versioning, and build provenance.

Another suggested that “CI [Continuous Integration] and CD [Continuous Deployment] should be completely separate environments. Compromise of CI should not lead to token leaks related to CD.” While this would be good security practice, it is inconvenient to implement.

It should also be noted that in this case, a tool that was intended to enhance security (and which in many cases has done so) was exploited to show that it could also itself be a vulnerability.