No technology is perfect, and Homebrew believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in Homebrew, we encourage you to notify us. We welcome working with you to resolve the issue promptly. Thank you for keeping Homebrew and its users safe!

Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue. Please bear in mind we're a project run entirely by volunteers in our spare time.

Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with our explicit permission.

Please report suspected security vulnerabilities through GitHub's private vulnerability reporting for the affected repository. For Homebrew/brew, use the security advisory form.

If it's a straightforward fix: please submit a pull request on GitHub.

We will respond to and fix reported, reproducible security vulnerabilities as soon as possible. A gentle reminder that we are a volunteer-run project so please cut us some slack here. Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.

Homebrew is a rolling release package manager. This means:

• only the latest release and latest commit on the main (or master if not yet migrated to main) branch of Homebrew/brew are supported.
• only the latest commit on the main (or master if not yet migrated to main) branch of all Homebrew repositories is supported.

Homebrew protects the integrity of Homebrew-maintained code, official formula and cask metadata, official bottle metadata, checksum verification, update and install logic, CI and release infrastructure, build sandboxing and credential filtering.

Security issues are defects in Homebrew-maintained code or infrastructure that let an attacker violate those guarantees without already controlling the user's account, local machine, maintainer account, command line, environment, configuration, third-party tap, mirror, wrapper or repository.

Homebrew is designed around a single-user machine security boundary. Homebrew assumes the user running brew controls and trusts their own account, Homebrew prefix, cache, configuration, taps and shell environment. Shared multi-user Homebrew installations are unsupported and outside Homebrew's security boundary.

Homebrew necessarily executes third-party software chosen by the user. Formulae and casks may run upstream build systems, installers and post-install commands. External taps, mirrors, wrappers and repositories configured by the user are trusted at the level the user granted them.

Installing from a tap is a trust decision for that tap. A tap can provide formulae, casks, external commands and tap metadata that install or run software, so using a tap means trusting its authors for those files.

Homebrew's boundary for upstream software is the brew-managed install, post-install and test execution path. Escapes from Homebrew's intended sandboxing or credential filtering in those phases may be security issues. Once a user runs installed upstream software directly, sandboxing and trusting that software is the user's responsibility.

The following sites and applications are within scope for this program:

• The brew package manager (Homebrew/brew)
• The Homebrew/homebrew-core and Homebrew/homebrew-cask official taps
• Homebrew-run infrastructure, including MacStadium workers and Homebrew-operated software running in cloud providers

Examples of in-scope security issues include:

• bypassing Homebrew's checksum or integrity checks for downloaded files
• running attacker-chosen code through Homebrew's trusted update or release paths, or through installation of formulae, casks or external commands from official Homebrew taps
• leaking credentials that Homebrew intentionally filters from builds or subprocesses
• escaping Homebrew's documented build sandbox or permission hardening
• tampering with official Homebrew metadata, bottles, releases or CI outputs
• silently treating an untrusted tap, mirror, wrapper, fork or repository as an official Homebrew source
• escaping Homebrew's intended install, post-install or test sandboxing on supported configurations

The following do not constitute security vulnerabilities in Homebrew:

A bug triggered only by convincing a user or CI job to run a crafted brew command, pass crafted arguments, set crafted environment variables, edit local configuration or execute an attacker-controlled script is not a security issue. An attacker who can control those inputs can already instruct Homebrew to install or run arbitrary software.

A bug that depends on using an untrusted tap, mirror, wrapper, fork, checkout or repository is not a Homebrew security issue unless Homebrew's own code silently treats it as official or bypasses a documented protection. Users who configure these sources grant them trust outside Homebrew's security boundary, including trust in the tap author's formulae, casks, external commands and tap metadata.

Malware, unwanted behaviour, vulnerable upstream releases, malicious install scripts, vulnerable casks or dangerous upstream build systems are not Homebrew security issues by themselves. Homebrew packages third-party software selected by users; removal or metadata changes for problematic packages should be handled in public issues or pull requests.

Security vulnerabilities in software used by but not written by Homebrew are not Homebrew security issues. Report these to the affected upstream project instead.

A report requiring the attacker to control the same user account, administrator account, shell startup files, PATH, Homebrew prefix, cache, lock files or repository checkout is not a security issue. Homebrew cannot defend against code already running with the user's privileges.

Bugs that only affect Tier 2, Tier 3 or unsupported configurations described in Support Tiers are not security issues unless they also affect Tier 1 configurations. This includes shared multi-user Homebrew installations, non-default prefixes that require source builds, unsupported operating systems, unsupported architectures, deprecated or disabled formulae, --HEAD installs and Homebrew installations managed by wrappers such as Nix.

Bugs in software after Homebrew has installed it are not Homebrew security issues. Homebrew may sandbox or filter credentials while it runs install, post-install and test steps, but users are responsible for deciding whether, how and where to run installed software afterwards.

Crashes, exceptions, hangs, high CPU usage, disk consumption or memory growth are not security issues when they only stop the current command or require attacker-controlled command-line input, configuration, package metadata from untrusted sources or local files. Report them publicly as quality bugs.

Documentation not matching behaviour is not a security issue unless the documented behaviour is a security guarantee that users or callers can reasonably rely on. Otherwise, report the mismatch publicly as a documentation or behaviour bug.

Issues that only affect brew.sh websites, brew.sh domain SPF configuration, nominal clickjacking on static GitHub Pages websites or third-party hosted web services Homebrew relies on but does not run are not Homebrew security issues. Examples of third-party hosted services include GitHub and GitHub Pages. InfluxDB analytics and other Homebrew-run infrastructure remain in scope.

While researching, we ask you to refrain from:

• Denial of service
• Spamming
• Social engineering (including phishing) of Homebrew maintainers or contributors
• Any physical attempts against Homebrew's machines
• Performing vulnerability research in public, such as testing discoveries by opening pull requests to Homebrew's public repositories without prior written approval