Gatekeeper lets user-run macOS apps be silently swapped after first launch

Apple’s Gatekeeper has a simple promise: downloaded apps should be checked, notarized, and protected from alteration after the first run. That’s the “gate” in Gatekeeper. But researchers Talal Haj Bakry and Tommy Mysk argue macOS can still be tricked, letting an attacker silently replace the main executable of an app downloaded from the web, without elevated privileges.

Here’s the part that matters for decision-makers: the team says they can alter a once-run internet-downloaded app and Gatekeeper does not object. They do it by archiving the app with tar, removing the original, and replacing it with a malicious version. macOS then does not require reauthorization, even though the original app had already passed Gatekeeper’s initial validation when the user opened it.

To understand why this is a big deal, you have to look at how the macOS trust system is supposed to behave. Apple’s own explanation, as cited by The Register, is that when a user downloads and opens an app, a plug-in, or an installer package from outside the App Store, Gatekeeper verifies it is from an identified developer, is notarized by Apple to be free of known malicious content, and hasn’t been altered. The researchers say they found a gap in Gatekeeper and “associated code signing rituals” that allows replacement of the main executable without needing elevated privileges.

This is not framed as a zero-click, drive-by remote hack. The Mysk team says the attacker needs user-level code execution available, such as a malicious app or downloaded script. That constraint matters, because it shifts the risk profile from “internet malware takes over your Mac instantly” to “if an attacker can get code running as you, they can swap trusted software with a lookalike.” In practical terms, that is still a serious threat. The researchers note apps downloaded from the web, including Brave, Slack, Signal, and Visual Studio Code, among many others, could be in scope.

The attack’s workflow also includes a credibility amplifier. Once a doppelganger version of an app is in place, it can magnify its mischief by presenting deceptive prompts that appear to come from a known app. Users are more likely to trust the prompts because the UI and app identity look familiar. That is the kind of second-order effect that tends to bypass even strong technical controls, because people are part of the system. A technically “valid” looking UI is a social engineering delivery mechanism.

There’s a key boundary condition: the researchers say the technique does not work on Mac App Store apps, because those apps are owned by root. A process running with current user privileges would not be able to overwrite them. For organizations, that difference is important for procurement and deployment decisions. The risk is concentrated around the large universe of internet downloads that are outside the App Store, where users and IT teams still commonly install tools, updates, and integrations.

Tommy Mysk was also uncertain about the exact cause, but speculated it may have something to do with cached value retention. The idea is straightforward: when you open the app for the first time and it passes validation, macOS marks the app as trusted and saves data. Later, when the executable is modified, macOS is supposed to detect the change and revalidate. The researchers claim the cached trust causes macOS to pass validation even when the bundle has changed.

So what did Apple do after being told? The Mysk team reported the findings to Apple, which reportedly closed the issue. Apple’s response, as described, draws a line based on how the proof of concept operates: Apple does not consider this attack to be “modifying” the signed executable. Instead, Apple says the archive and restore approach overwrites the entire app bundle, making it locally built. Apple argues locally built bundles are not covered by macOS guards. And because locally built bundles are treated differently, access to Keychain or TCC protected directories requires system authorization prompts, which Apple frames as a matter of social engineering that is out of scope for macOS guards.

From an enterprise and investor perspective, the strategic takeaway is not just “macOS has a bug.” It is that trust models often contain seams between initial validation and later lifecycle events, like update, packaging, caching, and restore. Even with notarization, the system’s definition of “modification” and what counts as “locally built” can become the decisive factor. For security leaders, the operating question becomes: do your policies assume Gatekeeper is continuous enforcement, or do they plan around the possibility that once something is accepted, it might be manipulated later through creative filesystem and packaging steps?

This is exactly the kind of mismatch that regulators and customers eventually care about. As compliance expectations around software provenance and integrity keep tightening, scrutiny lands not just on malware prevention, but on what users and administrators can reasonably assume about post-install integrity. And for boards and executives, the reputational risk is the same even when the technical fix arrives quickly: the market remembers when a core trust feature got called out, and it asks whether the organization’s own software supply chain controls are hardened enough to avoid being the “user-level code execution” stepping stone an attacker needs.