Vulnerability in volunteer-run open source project left API token fully exposed

Open source software package management system Homebrew has patched a vulnerability that enabled a security researcher to gain access to GitHub repositories in under half an hour.

Homebrew, which is run by a team of 12 volunteers, was alerted to the breach by white hat hacker Eric Holmes after he was able to exploit the vulnerability in no time at all.

Citing recent breaches at NPM, RubyGems, and Gentoo, Holmes – an operations engineer at Remind – said he came across the bug when researching concerns about the potential for package management systems to be used as attack vectors for distributing malicious software.

“I found that Homebrew runs a Jenkins instance that’s (intentionally) publicly exposed at,” he wrote in his blog.

“After some digging, I noticed something interesting; builds in the ‘Homebrew Bottles’ project were making authenticated pushes to the BrewTestBot/homebrew-core repo. This got me thinking, ‘where are the credentials stored?’”

Following a link to ‘Environment Variables’, Holmes spotted an exposed GitHub API token which gave him access to three core Homebrew repositories: Homebrew/brew, Homebrew/homebrew-core, and Homebrew/

And because the Homebrew/homebrew-core repository did not have a protected master branch, this would have allowed him to make a fast-forward change to refs/heads/master, inserting malicious software that would have been included in any new installations or updates.

Holmes reported the vulnerability to the Homebrew team, who immediately revoked the credentials and updated the repositories so that non-administrators would no longer be able to push directly to refs/heads/master.

Security second?

However, as the team points out, it's near impossible for an open-source project staffed by volunteers to cope with security issues in the same way as a major corporation – this particular problem was resolved by a staff member on paternity leave, while his child took a nap.

Holmes believes that other package managers are likely to be vulnerable too.

He described the way he was able to compromise Homebrew as ‘the scariest, and arguably the easiest method’, pointing out that compromising the infrastructure itself allows any checks and balances to be bypassed. However, other attack vectors may also be possible.

“One way is to compromise user accounts in the distribution system of the package manager. Package managers like RubyGems, NPM, PyPi, and Docker Hub all have webapps and are all likely targets for this, whether it's through phishing, or credential leaks from previous breaches,” he told The Daily Swig.

“In this scenario, the user account for a high-profile package might be compromised and allow an attacker to replace an existing version of the package with a backdoor. You can imagine a scenario where the RubyGems credentials for a Rails maintainer are leaked.”

Holmes said he would like to see authentication and authorisation taken more seriously, using strong forms of multi-factor authentication tools such as time-based one-time password algorithms, aka TOTP, and universal 2nd-factor authentication (U2F).

Package managers should at the very least support signed packages and content addressable identifiers that can be cryptographically validated to protect from tampering. He‘d also like to see more investment from major software players.

“If we don‘t address these things as an industry,” Holmes warned, “we‘re in for a world of hurt in the coming years.”