SAN FRANCISCO — July 6, 2026. Homebrew, the package manager that mediates software installation for an estimated 20 million-plus macOS and Linux developers, has spent the past eight years absorbing a slow drumbeat of security incidents that keep landing in the same three places: leaked CI credentials, unverified downloads, and untrusted third-party code execution. The latest homebrew formula security incident — a March 2026 supply-chain compromise that spilled from the Trivy scanner project into Homebrew's own bottle-delivery pipeline — pushed the project's maintainers to ship its most consequential security change in years: Homebrew 6.0.0's "Tap Trust" model, released June 11, 2026. Taken together, the incidents form a case study in how convenience-first package ecosystems accumulate supply chain risk, and why enterprise security teams cannot treat brew install as a trusted operation by default.
A Pattern, Not a Single Event
Security researchers and Homebrew's own maintainers have now documented at least four distinct classes of homebrew formula security incidents since 2018:
- 2018 — CI credential leakage. A publicly exposed Jenkins instance leaked a GitHub API token with push access to
Homebrew/brewandHomebrew/homebrew-core. - 2023 — Systemic code-execution weaknesses. A Trail of Bits audit sponsored by the Open Technology Fund found 25 distinct defects, several of them capable of full CI/CD compromise.
- 2025–2026 — Unverified download channels. Independent research disclosed that a subset of official Homebrew Cask formulae fetched installers over plain HTTP with checksum verification disabled.
- 2026 — Upstream compromise propagation. A credential-theft attack against the Trivy security scanner's release pipeline reached Homebrew users directly through a compromised custom tap.
No single one of these was a catastrophic, wormable breach. What they share is a structural theme: Homebrew formulae and taps are, by design, executable Ruby code with the privileges of the invoking user, and every incident has been a variation on "arbitrary code ran before anyone checked whether it should."
The 2018 Incident: 30 Minutes to Commit Access
The clearest illustration of that structural risk came from researcher Eric Holmes, who in July 2018 discovered that Homebrew's CI infrastructure exposed a GitHub API token through a publicly reachable Jenkins server. Builds tied to the "Homebrew Bottles" project were making authenticated pushes back into homebrew-core using that token — and the token itself was retrievable by anyone who knew where to look. Holmes reported gaining commit access to Homebrew/brew and Homebrew/homebrew-core within roughly 30 minutes of starting his research, and made a test commit to prove impact.
His own assessment of the blast radius was blunt: "If I were a malicious actor, I could have made a small, likely unnoticed change to the openssl formulae, placing a backdoor on any machine that installed it." Given that OpenSSL underlies TLS for a huge share of macOS developer tooling, a tampered formula binary could have propagated a backdoor to a meaningful fraction of the millions of machines that run Homebrew. Homebrew's response was fast — credentials were revoked and rotated within hours, and branch protections were added so non-administrators could no longer push directly to master — but the incident set the template that recurs across every later report: a single leaked or compromised credential is enough to compromise a formula that reaches millions of endpoints.
2023: An Audit Finds 25 Defects, None Fixed by Luck
Five years later, an independent security audit — commissioned by the Open Technology Fund and performed by Trail of Bits — formalized what practitioners had suspected: Homebrew's own codebase carried systemic weaknesses. The August 2023 report identified 25 distinct issues spanning path traversal, sandbox escape, insufficient integrity checks, permissive default rules, weak cryptographic choices, and privilege escalation paths. Several of the flaws were assessed as capable of letting an attacker load executable code, tamper with binary builds, or otherwise influence CI/CD workflow execution — the same category of risk the 2018 Jenkins leak had already demonstrated in the wild.
Homebrew maintainers resolved 16 of the 25 findings promptly and continued remediation on the rest, with a handful acknowledged as accepted risk rather than fully closed. The audit is a useful reference point for security teams precisely because it is not theoretical: it confirms that the trust assumptions baked into a widely deployed package manager had measurable, exploitable gaps, evaluated by an independent third party rather than surfaced only after an attacker found them first.
2025–2026: When "Working as Designed" Is the Vulnerability
Not every homebrew formula security incident stems from a bug — some stem from defaults. Research published under the name "Brew Hijack" examined Homebrew's official homebrew-cask tap and found roughly 20 casks that downloaded installer .dmg files over unencrypted HTTP while also setting no_check, the flag that disables Homebrew's checksum verification for that download. The researchers demonstrated the practical consequence directly: intercepting one of these installs, substituting a malicious .dmg, and watching Homebrew drop the attacker's payload straight into /Applications with no warning shown to the user. Because the affected casks sat in the tap Homebrew trusts by default, the exposure applied broadly across users of those specific applications — the report estimated tens of thousands of installs were reachable through the vulnerable configuration.
Homebrew maintainers, following responsible disclosure, reviewed every flagged cask and either migrated the download to HTTPS or disabled the cask outright where a secure transport wasn't available. The incident is a reminder that "unverified download over plaintext HTTP with checksum checking turned off" is not a hypothetical configuration mistake — it existed in a curated, official channel used by a mainstream package manager, and it took external researchers to find it.
March 2026: An Upstream Compromise Reaches Homebrew Directly
The most recent and most damaging homebrew formula security incident didn't originate inside Homebrew at all — it arrived through a downstream dependency relationship. On March 19, 2026, a threat actor identified as TeamPCP used compromised maintainer credentials to publish a malicious v0.69.4 release of the Trivy vulnerability scanner, simultaneously force-pushing malicious commits across the majority of aquasecurity/trivy-action version tags and every tag in aquasecurity/setup-trivy. The payload was a credential-stealing implant that harvested SSH keys, cloud provider tokens, Kubernetes credentials, and environment variables from process memory and disk, encrypting the haul with AES-256-CBC/RSA-4096 and exfiltrating it to a typosquatted domain designed to look like Aqua Security's own infrastructure.
Critically for Homebrew users, a custom third-party Trivy tap was compromised in the same incident window, meaning brew install was a viable delivery path for the malicious release alongside GitHub Actions and container registries. The exposure window for the tainted binary itself was roughly three hours; the compromised GitHub Action ran for closer to twelve. The compromise was compounded by a non-atomic credential rotation after an earlier, related disclosure on March 1, 2026 — not every credential was revoked at once, leaving a live token that let the attacker re-establish access and exfiltrate freshly rotated secrets days later. Homebrew's mitigation was to pin the formula back to the last known-good v0.69.3 build, but the episode demonstrated that Homebrew's trust boundary is only as strong as the taps and release pipelines feeding it — a lesson the project's maintainers moved quickly to act on.
Homebrew's Response: Tap Trust in 6.0.0
Homebrew 6.0.0, shipped June 11, 2026, is the project's direct answer to the pattern above. The headline feature, Tap Trust, changes a long-standing default: third-party taps, tap-qualified formulae and casks, and external commands now require explicit trust — via brew tap --trust user/repo or the new brew trust command — before Homebrew will evaluate or execute their Ruby code at all. Official Homebrew taps remain trusted by default; everything else is gated. The change directly targets the root cause common to the 2018, 2025, and 2026 incidents: a tap is fundamentally a Git repository of unsandboxed Ruby that runs with the invoking user's full privileges the moment Homebrew loads it, and until 6.0.0 that loading happened with no trust checkpoint at all.
What This Means for Security Teams
For organizations that permit or standardize on Homebrew across developer laptops and CI runners, the throughline across eight years of incidents is that package-manager trust is transitive and often invisible: a compromised CI credential, a plaintext download, or a compromised upstream maintainer account can each independently turn a routine brew install into an initial-access vector. Tap Trust reduces one major class of exposure but does not eliminate the need for organizations to independently verify what formulae and casks are actually running in their environment, monitor for anomalous package behavior, and maintain an inventory that can be cross-referenced the moment the next advisory drops.
How Safeguard Helps
Safeguard is built for exactly this class of problem: catching a homebrew formula security incident — or the next one, wherever it originates — before it reaches production. Safeguard's SBOM generation and ingest continuously catalog every formula, tap, and transitive dependency installed across developer and CI environments, so when an advisory like the Trivy/Homebrew compromise breaks, security teams can query affected inventory in seconds instead of grepping Slack. Griffin AI correlates that inventory against emerging threat intelligence and flags compromised or newly-untrusted taps automatically, cutting the manual triage time that let incidents like the 2026 credential rotation gap linger for days. Reachability analysis then tells teams which of the flagged packages are actually exercised by running code paths, separating genuine exposure from noise so remediation effort goes where it matters. When action is needed, Safeguard's auto-fix PRs pin affected formulae to known-good versions or enforce trust requirements directly in CI configuration, turning a multi-day incident response into a same-day merge.