Security2 publishers3 min readPublished
Seven of Homebrew's eight advisories shipped before 7.0.0, including the sudo-level cask bug
Homebrew rated the unsigned cask removal metadata path High and closed it back in 6.0.12. The 7.0.0 upgrade adds one Moderate sandbox escape through LaunchServices, plus a scanner for installed formulae.
The Watch · Security desk

What happened
- Homebrew shipped version 7.0.0 on Sunday and closed eight security advisories with the release, rated one High, two Moderate and five Low.
- Seven of the eight fixes shipped in 6.0.x releases; the eighth, a cask escaping the macOS install sandbox through LaunchServices, needs 7.0.0 installed.
- The release adds brew vulns, which checks installed formulae against OSV.dev records with no extra tap or gem and filters output by severity, dependencies and available fixes.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- contradiction Both root-capable paths were closed in 6.0.12, so an auto-updating fleet was never waiting on 7.0.0; the machines carrying the sudo bug are the ones pinned below that release, and the coverage does not quantify them.
- exposure Tap trust is still the boundary. A cask from a tap the user added can hand over a vendor .pkg that runs outside the sandbox and asks for sudo, and none of the 7.0.0 controls change that.
- capability Security teams get a CC0 feed that records Homebrew's backported patches, so triage stops depending on an upstream version string that Homebrew did not move when it fixed the bug.
- cost Fleets still on Intel Macs now pay in build time for fixes that arrive in a new formula version, because routine Intel bottle builds have ended.
The fix that actually requires 7.0.0 is the LaunchServices escape, and Homebrew rates it Moderate. Until the upgrade is installed, a malicious cask can execute code outside the macOS install sandbox [4]. Homebrew closes it by restricting application launching, Mach services and Unix socket connections [8].
Both paths that reach root privilege landed in 6.0.12 [1]. The High one let unsigned removal metadata for a cask execute commands with sudo, and Homebrew deleted the vulnerable recovery code and the API accessors that reached it [2][6]. The second is a Moderate in the same release: the macOS installer read Git configuration owned by the Homebrew prefix, and that could execute programs as root [7]. The five Low entries, fixed in 6.0.6 and 6.0.7, cover redirects that could carry secret headers to another host or become server-side request forgery, Git redirects that sidestepped tap restrictions, Subversion URLs that turned into command options, and patches writing outside the staged source tree [9]. A machine that has been auto-updating already carries all seven [3]. The installs still exposed to the sudo path are the ones pinned below 6.0.12. Neither writeup says how many that is.
Any of it needs a cask from a tap the user chose to add. Tap trust remains the main protection against a malicious third-party cask, and Homebrew says sandboxing "cannot make untrusted software safe to run" [14][15]. An installed application runs with the user's privileges, and vendor .pkg installers run outside the sandbox and can ask for sudo [14]. BleepingComputer notes that threat actors frequently target the project to push info-stealer malware, including through clone sites and ClickFix lures [23].
brew vulns determines each formula's upstream repository and version or tag, uses SBOM data for installed packages or derives the source from the formula definition, batch-queries OSV.dev, verifies potential matches, and then checks whether Homebrew has already applied a security patch [22]. That last step is where the false alarms go. When Homebrew backports a fix without moving the upstream version number, a scanner reading the version string alone flags a hole that is already closed [12]. The project team said: "Homebrew publishes advisory findings in the formula API and a downloadable advisory index, helping other tools distinguish outstanding vulnerabilities from fixes already shipped" [13]. The records are OSV-format and CC0 [11].
Intel x86_64 is now Tier 3 after unreliable infrastructure ended routine Intel bottle builds. Existing bottles stay available, but an updated formula may have to be compiled locally. That local build is how an Intel user picks up a fix that ships in a new version [20]. Homebrew gives 1 September 2027 as the point after which Intel runs without project support [21].
On Linux, Landlock replaces the Bubblewrap sandboxing introduced in June. Kernels without Landlock keep running in the less secure configuration that predates 6.0.0, and brew doctor reports the gap as an advisory [19].
The install-time Ruby is going, slowly. 7.0.0 sandboxes formula and cask operations and delivers setup instructions as signed data [16]. Official taps already reject post_install and cask flight blocks; third-party taps may keep using them until 11 December 2027 [17].
What to watch
- Whether third-party taps drop post_install and cask flight blocks before the 11 December 2027 cutoff or run to the deadline.
- Whether Intel fleets start missing fixes because an updated formula has no prebuilt bottle and has to be compiled locally.
- Whether the clone-site and ClickFix lures aimed at Homebrew move to malicious taps now that install-time Ruby is being cut.