"When a user downloads and opens an app, a plug-in, or an installer package from outside the App Store, Gatekeeper verifies that the software is from an identified developer, is notarized by Apple to be free of known malicious content, and hasn’t been altered," Apple says — a description of its macOS protections that security researchers say can be bypassed.
What Talal Haj Bakry and Tommy Mysk found
Researchers Talal Haj Bakry and Tommy Mysk say they have identified a gap in Gatekeeper and associated code-signing rituals that "allows an attacker to silently replace the main executable of any application downloaded from the web without requiring elevated privileges." Their proof-of-concept alters an app that was downloaded from the internet and run at least once; after Gatekeeper completes its initial validation the app can be swapped for a malicious version and macOS will not force reauthorization.
The weakness is not an instant, remote, zero-click exploit. The attacker needs some means of executing code at the current user level — for example a malicious app, a downloaded script, or another mechanism that can run with the user's privileges — but once that foothold exists the researchers say Gatekeeper's protections prove insufficient.
The tar archive and restore technique the team demonstrated
Bakry and Mysk describe a specific method: archive a downloaded, once-run app with tar, remove the original, then restore an altered bundle in its place. According to the researchers, macOS fails to require revalidation after that archive-and-restore cycle. They recorded a video demonstrating the steps and the result.
The team's tests showed the technique does not affect Mac App Store applications because those bundles are owned by root; a process running with the current user's privileges cannot overwrite them. By contrast, popular apps distributed outside the App Store — the researchers named Brave, Slack, Signal, and Visual Studio Code among many others — remain potentially vulnerable under this scenario.
How the researchers explain the behavior, and Apple's reply
Tommy Mysk said he was uncertain about the exact cause but speculated it "may have something to do with cached value retention." He explained: "When you open the app for the first time and it passes all validation checks, macOS marks the app as trusted and saves this data. Later when I modify the executable, macOS detects a change in the bundle and tries to revalidate its integrity. It seems the cached value of the trust causes macOS to pass the validation even though the bundle has changed."
The Mysk team reported the findings to Apple, which the team says "closed the issue." According to the researchers, Apple's position is that the archive-and-restore process overwrites the bundle in a way that makes the app "locally built," and Apple "doesn't consider this attack to be 'modifying' the signed executable." The Mysk team relayed Apple's rationale that "Locally built app bundles are not covered by macOS guards," and that access to Keychain or TCC-protected directories require system authorization prompts that Apple views as a social-engineering boundary rather than a platform integrity failure.
Apple did not respond to a request for comment.
Attack paths the researchers warned about
The Mysk team listed several practical ways an adversary might get the user-level execution required to carry out the swap. Examples include tools installed through the command line, convincing a user to copy-and-paste a command into a terminal, a downloaded malicious app, a prompt-injection attack on an AI agent, or a supply-chain compromise via package managers such as npm or Homebrew. Once a doppelgänger app is in place, the researchers note, it can display deceptive prompts that users are more likely to trust because they appear to come from a known, previously validated application.
What this means for end users, developers, and security teams
- End users: Applications downloaded from the web and executed once can, according to the researchers, be replaced without macOS forcing a fresh Gatekeeper validation; users should be aware that running an app once is the condition that allows the researchers' method.
- Developers and package maintainers: Apps distributed outside the Mac App Store — examples cited include Brave, Slack, Signal, and Visual Studio Code — were specifically called out as potentially at risk if their bundles are writable by the current user.
- Security teams and operators: The researchers outline multiple attack vectors that start with user-scoped code execution, including supply-chain and social-engineering techniques; teams responsible for macOS endpoints may need to consider controls that prevent untrusted local writes to application bundles or that restrict the command-line tools users can run.
The Mysk team says they have demonstrated the mechanics and reported the issue to Apple, and that Apple closed the report with the view that the archive/restore path produces "locally built" bundles that macOS does not treat as modified. The research raises a pointed question for platform defenders: if a notarized, user-run app can be swapped without revalidation, who — and what mechanisms — will close that gap? Apple did not reply to a request for comment on the record.
