Evil Twin Apps Slip Past macOS Gatekeeper Warnings

The macOS Gatekeeper evil twin app problem is simple: Apple can approve a downloaded app once, then macOS may let a malicious replacement inherit the user’s trust. XOOMAR’s view: that is not a harmless edge case. It cuts straight into the promise of Gatekeeper.

Researchers Talal Haj Bakry and Tommy Mysk say they found a way to replace the main executable of certain web-downloaded macOS apps after they have been opened once, without elevated privileges and without triggering fresh warnings, according to The Register Security.

Apple’s own description sets the bar high:

“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.”

That promise collapses if the checked object and the launched object can quietly diverge.

Apple's Gatekeeper promise collapses when macOS app downloads can be swapped for evil twins

Apple has trained users to trust the dialog box. Most people don’t inspect app bundles, quarantine flags, signatures, ownership metadata, or launch paths. They see Slack, Signal, Brave, or Visual Studio Code in the expected place, with the expected icon, and they assume macOS already handled the hard part.

That assumption is exactly what this research challenges.

The reported attack applies to apps downloaded from the web, not apps from the Mac App Store. The Mysk team told The Register the technique does not work on Mac App Store apps because those are owned by root, so a process running with current user privileges cannot overwrite them.

That distinction matters, but it does not save Apple’s position. Plenty of serious Mac software lives outside the App Store. The researchers name examples including Brave Browser, Cursor, Mullvad Browser, Proton Mail, Slack, Visual Studio Code, Xcode, and Signal, while making clear Signal was only a demonstration target, not the source of the flaw.

How the macOS evil twin app swap undercuts Gatekeeper's first line of defense

The sequence is not magic. It is worse: it is ordinary.

A user downloads a macOS app from the web. They open it once. Gatekeeper performs its initial checks. After that, the researchers say an attacker with code execution as the current user can archive the app bundle with tar, remove the original, restore the archive, and then replace the app’s main executable under /Contents/MacOS/.

The result, according to the researchers, is a modified app that launches without a fresh Gatekeeper warning.

This is not a zero-click remote exploit. The attacker first needs a foothold, such as a malicious app, a downloaded script, a copied terminal command, a prompt injection attack on an AI agent, or a supply-chain route through npm, brew, or another package manager, as the Mysk team described.

That limitation is real. So is the danger. Attackers often win by chaining small weaknesses, not by smashing through every wall at once.

The macOS security story breaks when users must police invisible trust signals

Apple cannot ask users to trust its security ceremony, then declare the ceremony irrelevant when the wrong object gets launched later.

The user problem is blunt. People download apps for work, school, development, finance, creative tools, encrypted messaging, password management, and crypto workflows. They are not checking whether the bundle they launch today is the exact bundle Gatekeeper inspected yesterday.

The Mysk team’s write-up says a malicious replacement could impersonate a trusted application in permission prompts for Keychain secrets and files protected by Transparency, Consent, and Control, or TCC, including items in ~/Desktop and ~/Documents. TCC is Apple’s privacy permission system for sensitive data and protected locations.

The supplied reports do not claim this technique is being exploited in the wild. That restraint matters. But as risk analysis, the path is obvious: if a malicious twin can wear the name and icon of an app the user already trusts, social engineering gets sharper. A fake permission prompt from a random binary is suspicious. A prompt from the app you use every day feels routine.

Related XOOMAR reading on Apple’s wider platform control includes Apple Mac AI Overhaul Throws Mac Buyers Into Limbo and Samsung Galaxy Card Takes Aim at Apple's Wallet Grip. The common thread is trust in Apple-controlled user decision points. Security dialogs are the highest-stakes version of that trust.

Apple's muted response tells developers and attackers the macOS threat model has holes

The most damaging part may be Apple’s reported response.

The Mysk team says it reported the finding to Apple, which closed the issue. The researchers described Apple’s reasoning this way:

“Apple doesn't consider this attack to be 'modifying' the signed executable,” the Mysk team explained. “Instead, Apple says that by archiving/restoring the app bundle, the proof-of-concept code overwrites the entire app bundle, making it locally built.”

Apple did not respond to The Register’s request for comment.

That leaves developers, enterprise admins, and security teams with fog where there should be a rule. If macOS treats a restored app bundle as locally built, and if locally built app bundles are outside certain guards, Apple should document the boundary plainly. If another control is supposed to stop realistic abuse, Apple should say which one.

Silence is not neutral here. Apple benefits from the perception that macOS guardrails are stricter than the average user can manage alone. That perception creates an obligation: when researchers show a trust gap, Apple should either patch it, explain it, or warn admins how to monitor it.

Attackers read vendor responses too. A technique dismissed as out of scope can become a recipe for targeting users who believe the platform is doing more than it actually is.

Yes, macOS can't stop every local app trick, but Gatekeeper still needs stricter boundaries

The strongest counterargument is fair: no operating system can protect users from every local file replacement after malicious code is already running in the user’s environment.

Gatekeeper is also only one layer. macOS includes notarization, XProtect, sandboxing, permission prompts, and enterprise endpoint tools. The researchers themselves note that access to Keychain or TCC-protected directories still requires system authorization prompts.

But layered defense does not excuse a broken handoff. If Gatekeeper’s user-facing promise is that downloaded apps are checked before execution, then macOS should care when the app bundle changes in a meaningful way after that approval.

Tommy Mysk offered one possible explanation:

“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,” he said. “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.”

That is the core defect in plain language: trust appears to survive the thing it was supposed to describe.

Apple should fix the evil twin gap before macOS users learn security warnings are theater

Apple should treat the macOS Gatekeeper evil twin app issue as a design flaw, even if it does not fit the narrow shape of a traditional vulnerability.

The reasonable fixes are not exotic:

• Revalidation: Re-check app bundles when the main executable changes or when the bundle has been removed and restored.
• Binding: Tie Gatekeeper’s approval more tightly to the inspected object, not just to a path, bundle identity, or cached trust state.
• Warnings: Alert users when a previously approved downloaded app has been swapped or materially changed.
• Admin guidance: Publish clear advice for managed Mac fleets on monitoring web-downloaded app paths and replacement behavior.
• User education: Make clear that app names and icons are not proof that the original app is still intact.

Enterprises should not wait. Managed macOS fleets can restrict untrusted software, watch high-risk app directories, and educate users that a familiar prompt from a familiar icon can still be hostile if the app underneath has changed.

Gatekeeper does not have to be perfect. But if it blesses the original and waves through the evil twin, Apple should stop calling that gate kept.

Impact Analysis

• The finding challenges Gatekeeper’s promise that downloaded apps remain verified and unaltered after approval.
• Users may keep trusting familiar app names and icons even if the executable has been swapped.
• The issue is significant because many widely used Mac apps are distributed outside the Mac App Store.