On July 25, 2026, security researchers Talal Haj Bakry and Tommy Mysk published details of a technique that bypasses macOS Gatekeeper—the built-in safeguard that prevents untrusted apps from running. The method hinges on a behavior many users take for granted: once you’ve launched a legitimate app at least once, Gatekeeper may never check it again, even if the app is later swapped for a malicious lookalike.
Apple reviewed the finding and closed the report, stating that the reconstructed app bundle is treated as locally built software, which falls outside Gatekeeper’s scope. The company sees this as a social-engineering problem, not a vulnerability in its verification system. For Windows users watching the story unfold, it’s a stark reminder that trust-on-entry protections are not the same as continuous integrity monitoring.
What Researchers Found
The bypass requires an attacker to already have user-level code execution on a Mac. That initial foothold could come from a trojanized installer, a malicious script, a compromised package manager, or a phishing attack that tricks the victim into running a harmful command. Once inside, the attacker follows a simple recipe:
- Archive a legitimate application bundle that the user has opened at least once (e.g., a trusted note-taking app).
- Delete the original application from /Applications or wherever the user keeps it.
- Restore a malicious replacement that looks identical—same name, same icon, same location.
When the user double‑clicks the replacement, macOS does not trigger a fresh Gatekeeper verification. The original provenance metadata that prevented an unknown app from launching is effectively discarded because the bundle has been rebuilt locally rather than downloaded from the internet. To the operating system, it’s a different object, even though to the user it’s still “the app I always use.”
Crucially, the researchers did not attempt to tamper with the signed executable in place. That would normally be caught by code‑signing checks. Instead, they replaced the entire application bundle, which Apple views as creating a new, locally constructed artifact. The company’s logic is internally consistent: developers routinely build, archive, and restore apps on their own machines, and Gatekeeper isn’t supposed to block that workflow. But the gap between that technical classification and what a typical user expects is where the risk lies.
What This Means for Mac and Windows Users
For Mac Users
This is not a remote, zero‑click attack. An adversary cannot use the technique alone to compromise a clean Mac. The real danger comes after a foothold is already established—through a phishing email, a malicious browser download, or social engineering. Once an attacker has a toehold, replacing a trusted app can turn a fragile intrusion into something much more dangerous.
A malicious replacement can:
- Ask for sensitive permissions (camera, microphone, screen recording, full disk access, accessibility) while looking like an app you’ve approved before.
- Read or export Keychain items if the user unwittingly authorizes it.
- Persist across reboots as a LaunchAgent or log‑on item, making it harder to spot.
Because the replacement inherits the visual identity of the original, the user may not hesitate to grant those privileges when a legitimate‑looking system prompt appears. macOS will still display a permission dialog—the TCC (Transparency, Consent, and Control) framework remains active—but the request will come from an app you think you trust.
For Windows Users
If you use Windows, you’ve seen similar trust‑on‑entry mechanisms. Microsoft Defender SmartScreen evaluates downloaded files and warns about unverified publishers. Mark of the Web (MotW) flags files from the internet so that applications like Word or Edge can block potentially dangerous content. Windows also relies on code signing, User Account Control, and reputation services to gate software execution.
But these defenses share the same fundamental limitation: they validate software at the point of entry, not continuously afterward. Once a signed app has been run or a file’s MotW is removed, the system trusts it. If an attacker later replaces that trusted binary with a malicious version that matches the same weak policies, the operating system may not object. The lesson from Apple’s Gatekeeper bypass is universal: first‑run trust is a snapshot, not a guarantee.
How We Got Here: Gatekeeper’s Evolving Role
Gatekeeper debuted in macOS 10.7.5 (Lion) in 2012 as a way to enforce code‑signing and notarization for apps downloaded outside the App Store. Over the years, Apple tightened its default settings, eventually requiring all externally obtained software to be signed by a known developer and notarized—a process where Apple scans the app for known malware before attesting to its identity.
The system works well for the moment a new application enters the system. macOS attaches an extended attribute that marks the file as having come from the internet, and Gatekeeper checks it at first launch. But Apple has always drawn a line between downloaded executables and software compiled or reassembled on the local machine. The company argues that imposing Gatekeeper checks on every locally built bundle would cripple development workflows, enterprise deployment, and legitimate repair utilities.
This is not the first time researchers have poked holes in Gatekeeper’s perimeter. In 2021, a flaw allowed attackers to craft malicious documents that smuggled shell scripts past the checks. In 2022, another bypass let malware exploit quirks in the way Safari handled certain archives. Apple patched those quickly because they violated the explicit contract of Gatekeeper. The current technique falls into a different category: it doesn’t exploit a coding bug but rather a design assumption about what “locally built” means.
What You Should Do Right Now
Preventing the initial foothold is the most effective defense. No matter your platform, hardening the endpoint against the first compromise reduces the usefulness of any later trust‑reuse attack.
Individual Users (Mac and Windows)
- Download apps only from official sources. The Mac App Store or a developer’s verified website is far safer than a random link from a forum or social media post.
- Read permission prompts carefully. If a familiar app suddenly asks for camera access, full disk access, or automation control, pause and investigate.
- Use a standard (non‑administrator) account for daily work. This raises the bar for malware that wants to modify system areas.
- Keep your OS and all installed apps updated. Patches close the remote‑execution vulnerabilities that attackers often rely on for that first foothold.
- Monitor Login Items and background processes. On a Mac, check System Settings > General > Login Items; on Windows, inspect the Startup tab in Task Manager. Look for entries you don’t recognize.
- Be skeptical of terminal commands and “fix” scripts. Many Mac infections spread through copy‑paste instructions that promise to activate cracked software or fix performance issues.
Organizations and IT Admins
For businesses that manage fleets of Macs—or Windows PCs—the Gatekeeper bypass underscores the value of defense in depth.
| Control | What it does | Why it matters |
|---|---|---|
| Application allow‑listing (macOS: System Policy, Windows: AppLocker or WDAC) | Only permits approved software to run | Prevents any unknown replacement from executing, even if the original was trusted |
| Endpoint detection and response (EDR) | Monitors process creation, file changes, and network activity | Flags unusual archive‑and‑restore sequences in /Applications and similar directories |
| Hardened admin access | Removes local admin rights for most users, requiring just‑in‑time elevation | Stops malware that relies on administrative privileges to tamper with protected folders |
| Privacy permission audits (MDM) | Regularly review which apps have Full Disk Access, Accessibility, Screen Recording, etc. | Reduces the attack surface if a malicious replacement attempts to exploit those permissions |
| Code‑signature verification | Use codesign -dv --verbose=4 /path/to/app or enterprise management tools to verify that a suspicious app’s signature matches the expected developer |
Helps distinguish a genuine app from a locally rebuilt imposter |
For high‑security environments, consider periodic integrity checks on critical application bundles. A simple script that compares the SHA‑256 hash of a folder against a known‑good baseline can reveal silent replacements. On Windows, file integrity monitoring built into security tools can serve the same purpose.
The Bigger Picture: Trust Isn’t a One‑Time Decision
The Gatekeeper bypass will not lead to a flood of Mac malware, and most users will never encounter it. But the episode exposes a weakness common to all endpoint‑security models: operating systems reward software that has been trusted once and then stop looking at it.
Apple’s defense—that the reconstructed bundle is essentially a new app the user created—is technically defensible but practically unsatisfying. Users don’t think in terms of bundle provenance or quarantine metadata. They see an icon they recognize, and that recognition is the strongest social‑engineering lever an attacker can have.
Windows users should see the story as a mirror, not a spectator sport. SmartScreen, MotW, and code signing all operate on similar trust‑on‑entry assumptions. If an attacker can plant a malicious executable in place of a trusted one—whether through a shared folder, a USB drop, or local manipulation after a foothold—those defenses may not fire.
Ultimately, the Gatekeeper bypass is not a failure of one feature. It’s a signal that security practices must shift from asking “Where did this come from?” to continuously asking “Is this still what it claims to be?” That’s a harder problem, but it’s the one that matters for users across every platform.