On 5 August 2018, the maintainers of Homebrew, the popular open-source package manager for macOS, disclosed that a GitHub personal access token with push access to its core repositories had leaked from the project's Jenkins build server. Security researcher Eric Holmes found the token on 31 July 2018 by following an "Environment Variables" link on Homebrew's public Jenkins instance, and confirmed it worked by writing a test object to the Homebrew/homebrew-core repository through the GitHub API. He says the whole exercise took about 30 minutes. The token belonged to the build automation that pushes compiled packages, and Homebrew says its scopes had recently been elevated. Holmes reported the issue through HackerOne, and Homebrew revoked and replaced the credentials within a few hours. GitHub Support verified that the token was not used to push to the core repositories during the exposure, and Homebrew said no packages were compromised.
Key takeaways
- A GitHub token used by Homebrew's build automation was visible on the "Environment Variables" page of its publicly reachable Jenkins server, according to the researcher, Eric Holmes.
- Holmes says the token had push rights on Homebrew/brew, Homebrew/homebrew-core and Homebrew/formulae.brew.sh, and admin rights on the BrewTestBot fork. He confirmed write access with a harmless API call.
- Anyone holding the token could have changed the package definitions that Homebrew users install from. Homebrew-core had no protected master branch at the time, Holmes wrote.
- Homebrew revoked the token within hours of the HackerOne report, and GitHub Support verified it had not been used to push to the core repositories. No malicious use has been reported.
- The identity lesson: a CI server holds the most powerful tokens in a software project, so its configuration pages are part of the attack surface.
At a glance
| Organisation | Homebrew (open-source package manager for macOS and Linux) |
|---|---|
| When | Token found and reported 31 July 2018; disclosed by Homebrew on 5 August 2018; researcher's write-up 7 August 2018 |
| Attacker | None known. Found by security researcher Eric Holmes and reported through Homebrew's HackerOne programme |
| Entry point | Homebrew's publicly reachable Jenkins instance, whose job configuration exposed environment variables |
| Identities abused | A GitHub personal access token used by the BrewTestBot build automation, with recently elevated scopes that allowed pushes to Homebrew's core repositories |
| Impact | Researcher obtained a live token able to push to core repositories; GitHub verified no pushes to Homebrew/brew or Homebrew/homebrew-core; no packages compromised, according to Homebrew |
| Category | NHI. Incident class: confirmed NHI breach (live CI token obtained and used by a researcher; no malicious use) |
What happened
Homebrew builds pre-compiled packages, called bottles, on a Jenkins server. In his write-up, Eric Holmes explains that he first searched Homebrew's GitHub organisation for leaked credentials with the tool gitrob and found nothing useful. Reading earlier disclosed reports on HackerOne, he learned that Homebrew ran a public Jenkins instance. He noticed that jobs in the "Homebrew Bottles" project made authenticated pushes to the BrewTestBot/homebrew-core repository, and went looking for where those credentials lived. The "Environment Variables" link on the Jenkins page showed a GitHub API token.
Holmes then asked the GitHub API what the token could reach. According to his post, it had admin, push and pull rights on BrewTestBot/homebrew-core and push and pull rights on Homebrew/brew, Homebrew/homebrew-core and Homebrew/formulae.brew.sh. To prove write access without changing anything users would see, he created a Git blob containing the word "test" in Homebrew/homebrew-core and reported the issue. He added that homebrew-core had no protected master branch at the time. "If I can gain access to commit in 30 minutes, what could a nation state with dedicated resources achieve...", Holmes wrote, as quoted by The Register.
Homebrew's disclosure, posted by Mike McQuaid, says a token "with recently elevated scopes" leaked from its Jenkins and gave git push access to Homebrew/brew and Homebrew/homebrew-core. Within a few hours the credentials were revoked, replaced and sanitised within Jenkins. GitHub Support confirmed the token had not been used to push to either repository while it had the elevated scopes, and Homebrew concluded that "no packages were compromised and no action is required by users due to this incident." The post notes that the maintainer who handled the fix was on paternity leave, and asked for volunteers and donations.
Homebrew also changed its controls. Non-administrators can no longer push directly to master on Homebrew/brew and Homebrew/homebrew-core, most other repositories now need passing CI checks on a pull request, and branch protection and required reviews were extended. Maintainers were asked to prune their personal access tokens and disable SMS fallback for two-factor authentication. A proposal to require GPG-signed commits in homebrew-core was rejected by a non-unanimous vote of the project's leadership committee because of workflow concerns. Commenting on the case, Paul Ducklin of Sophos described the token simply: "This is essentially an access key," as quoted by ADMIN Magazine.
Timeline
| Date | Event |
|---|---|
| 31 July 2018 | Eric Holmes finds the GitHub token on Homebrew's public Jenkins and reports it through HackerOne; Homebrew revokes and replaces it within hours. |
| 5 August 2018 | Homebrew publishes its security incident disclosure. |
| 7 August 2018 | Holmes publishes "How I gained commit access to Homebrew in 30 minutes". |
| 8 August 2018 | The Register reports the finding. |
How it happened: the identity attack path
- Public build server. Homebrew's Jenkins instance could be browsed from the internet, as earlier HackerOne reports had already shown.
- Token in job configuration. The bottle-building jobs pushed to GitHub with a personal access token, and the Jenkins page listed it among the job's environment variables.
- Over-broad scopes. The token had recently been given wider scopes, so a credential meant for a bot's fork could push to Homebrew's main repositories.
- Write access confirmed. Holmes listed the repositories the token could reach through the GitHub API and wrote a harmless blob to homebrew-core.
- Revoked and audited. Homebrew revoked the token within hours, and GitHub Support checked that it had not been used to push to the core repositories.
Impact
- Confirmed: a live GitHub token with push access to Homebrew's core repositories was exposed on a public page and obtained by a researcher, who used it to prove write access.
- No malicious use found: GitHub Support verified no pushes to Homebrew/brew or Homebrew/homebrew-core during the elevated-scope period, and Homebrew said no packages were compromised and users did not need to act.
- Potential: an attacker with the token could have altered package formulae installed by Homebrew users. ADMIN Magazine noted that openssl was the most downloaded Homebrew package in the previous 30 days.
- Response: branch protection, required reviews and CI checks were added, and maintainers were asked to review their tokens.
What this means for NHI governance
This is an early example of a pattern now common in open-source supply chain incidents: the most valuable credential in a project belongs to its automation, not its people. BrewTestBot's token could push to the repositories that define what Homebrew users install, yet it sat in a CI job's environment where a public web page could show it. Its scopes had been widened for convenience, and the core branch had no protection that would have forced a review before a change reached users.
The same lessons apply to every CI system. Tokens should be scoped to the one repository and action a job needs, short-lived where possible, masked in every user interface and log, and backed by branch protection so that a single stolen token cannot ship code on its own. Homebrew's fast response, with GitHub confirming no misuse, is the model for what to do afterwards. The eslint-scope npm compromise a few weeks earlier showed what happens when a publishing credential does reach an attacker. Our CI/CD Pipeline Identity Security Guide and Secrets Management Guide cover these controls.
Recommendations
- Never expose CI servers or their configuration pages to the internet. Put build servers behind authentication and review what anonymous users can see. See our CI/CD Pipeline Identity Security Guide.
- Store CI tokens as masked secrets, not plain environment variables. Use the CI system's credential store or an external secrets manager so tokens are never rendered in pages or logs. See our Secrets Management Guide.
- Scope bot tokens to the minimum repositories and permissions. A token that pushes bottles to a fork should not be able to push to the main repositories; prefer fine-grained or app-based tokens that expire.
- Protect release branches. Require reviews and passing checks before anything reaches the branch users install from, so one token cannot ship code alone.
- Revoke first, then audit. Rotate an exposed token immediately and ask the code host to confirm whether it was used. See the Leaked Credential Response Playbook.
- Run a disclosure programme and fund the response. Homebrew's HackerOne programme brought the report in quickly; volunteer projects need people on call to act on it.
Frequently asked questions
Was Homebrew hacked in 2018?
A researcher, Eric Holmes, obtained a GitHub token from Homebrew's public Jenkins server that could push to its core repositories, and used it only to prove write access before reporting it. Homebrew revoked the token within hours, GitHub verified it was not used to push to the core repositories, and Homebrew said no packages were compromised.
How was the Homebrew GitHub token exposed?
The token was used by Homebrew's bottle-building jobs to push to GitHub and was visible through the "Environment Variables" link on the project's publicly reachable Jenkins instance, according to Holmes and The Register.
Did Homebrew users need to do anything?
No. Homebrew said "no packages were compromised and no action is required by users due to this incident." The project instead tightened its own controls with branch protection, required reviews and a review of maintainers' tokens.
Related NHI Mgmt Group resources
eslint-scope npm Compromise 2018 · Python/PyPI admin GitHub token in Docker image · SpotBugs Token Leak 2025 · CI/CD Pipeline Identity Security Guide · Secrets Management Guide
How NHI Mgmt Group can help
Build systems hold the tokens that can change what users install. We help teams inventory CI and bot credentials, cut their scopes, move them into managed secret stores and put owners and expiry on each one. See our NHI and AI agent security training.
References
- Homebrew (Mike McQuaid): Security Incident Disclosure (5 August 2018)
- Eric Holmes: How I gained commit access to Homebrew in 30 minutes (7 August 2018)
- The Register: Researcher found Homebrew GitHub token hidden in plain sight (8 August 2018)
- ADMIN Magazine: One Hacker Could Have Taken Control of Macs Used by IT Professionals (14 August 2018)