Stranger Things on GitHub

An ordinary programmer googled something and got to a repository with malicious code and decided to find out how many more such infected repositories that are easily googled.

August 3 Stephen Lacy wrote on twitter that he “discovered a massive attack on 35,000 GitHub repositories”, on crypto, golang, python, js, bash, docker, k8s projects, as well as npm scripts, docker images and installation documents. (He later clarified that not “35,000 repositories”, but 35,000 “code hits”)

Shortly after his tweet, either GitHub or the attacker removed most of the public forks, and a couple of hours later appears tweet from a newly created user account @Pl0xPwhere he claims that he is behind the attack, and this is part of the bug bounty audit.

Most of the commits seem harmless, with messages like “upgrade to 0.3.11”.

Some of these repo histories include commits from the original author, but the commit is not verified by GPG:

Some of these repositories have been “archived”, such as this one in 2019.

Some of them are disguised as legitimate-looking pull requests, but the repository has not received any PRs. Every go file in this repository has been infected.

Stephen Lacy discovered the exploit while browsing a project he found in a Google search. He recommends not installing random packages from the internet, and encourages signing GPG commits.

This attack is possibly aimed at users who type in search-engines-related code snippets and end up in these malicious GitHub repositories.

Here is a possible attack scenario:

  • An attacker forks a GitHub repository
  • The attacker modifies the last original commit and adds malicious code using the original commit ID.
  • The malicious payload sends sensitive environment variables to the attacker’s infrastructure and then waits for a command from the attacker to execute on the machine.

It appears that the attacker modified the most recent commit and modified it with malicious code. He may have planned to inject this code into the original forked project.

By making or committing changes in the right way, attackers can impersonate another GitHub user and give the impression that the commit comes from them. This is done by modifying certain environment variables locally to obtain the username and email address of the user that the attacker would like to impersonate.

Screenshot of one of the infected commits. Note that the commit signature is not verified

Infected Golang files


It appears that the attacker ran a program to “fix” each of the cloned project’s “.go” files with an initialization function, thus being able to exfiltrate environment variables and execute code on the victim’s machine. This malicious code will not work if the “e452d6ab=1” environment variable is defined:

NPM infected files

It looks like the attacker ran a program to “fix” each of the cloned project’s “package.json” files with a “postinstall” statement, having the logic to exfiltrate environment variables and execute the code on the victim’s machine:

Infected YAML files

The YAML files, infrastructure configuration, and containers have been modified with additional steps to run the curl command to exfiltrate all environment variables into a custom service:

The claim that this is an “audit” is contradicted by two things:

  1. The code has filtered out important environment variables. Let’s say you’re doing a POC and sending your computer name is more than enough.
  2. After the data was exfiltrated, the server sent commands to be executed on the victim’s machine.

Tane Piper wrote that 5 years ago he reported almost the same exploit in @npmjsbut no one took it seriously.

Sven Slootweg commented: “This is not really so much an ‘npm exploit’ as a more fundamental problem with access control in current generation operating systems. Removing the post-installation scripts won’t really solve anything – instead, you’ll just paste your malicious code somewhere in the package code.”


GitHub as an attack vector in the era of automated ci/cd pipelines is incredibly underrated.

This attack is aimed at naive developers, so be careful when you google code snippets. And if it was still the work of a white hacker, then he chose very potentially malicious methods.

Similar Posts

Leave a Reply