Security researchers have disclosed a macOS flaw that allows malware already running under a user’s account to silently replace the executable of trusted applications downloaded from the web, relaunching them without triggering any Gatekeeper warnings. The technique, documented by Talal Haj Bakry and Tommy Mysk, exploits a behavior in how macOS handles application bundles owned by the current user, enabling attackers to swap out a legitimate app’s core binary with a malicious one after the app has been launched at least once. While the method does not bypass Apple’s core security protections, it can cause permission dialogs to display the trusted application’s name and icon, potentially tricking users into granting access to sensitive data such as documents, keychains, or the desktop.
How the macOS Flaw Works: Archive-and-Restore Executable Replacement
The attack centers on a simple but effective technique: archiving and restoring an application’s bundle. According to the researchers, an attacker who already has code execution privileges as the logged-in user can use the macOS Archive Utility to compress the entire application bundle and then restore it. After this operation, macOS no longer prevents the bundle’s main executable from being replaced. The modified application then launches normally without displaying new Gatekeeper or code-signature warnings, because the system treats the bundle as a user-owned file that has already been verified.
This issue affects applications installed outside the Mac App Store that are owned by the current user and have already been launched at least once. Mac App Store applications are not affected because they are typically owned by the root account. Mysk tested the vulnerability on macOS Tahoe 26.x and Golden Gate beta releases, noting that earlier versions are likely affected as well. The researchers demonstrated the technique using Signal as an example, emphasizing that Signal is not inherently vulnerable and that it simply serves as a representative target. They observed the same behavior with numerous other applications, including Brave Browser, Cursor, Mullvad Browser, Proton Mail, Slack, Visual Studio Code, and Xcode.
What Is the Gatekeeper Bypass? A Detailed Explanation
Gatekeeper is a macOS security feature designed to verify that downloaded applications have been signed by an identified developer and have not been tampered with before their first launch. However, the key limitation is that Gatekeeper performs this verification only once, at the time of the first launch, and does not continuously monitor the application bundle for changes afterward. Once an application is deemed safe and has been launched, macOS treats the bundle as a user-owned file that can be modified by the user. The archive-and-restore trick effectively resets the internal state of the bundle, allowing the executable to be replaced without triggering a new Gatekeeper check.
The replacement executable does not inherit the legitimate application’s code-signing identity, entitlements, or previously granted Transparency, Consent, and Control (TCC) permissions. Instead, macOS correctly displays authorization prompts when the modified application attempts to access protected resources such as the Desktop, Documents folder, or Keychain. However, the problem is how those prompts are presented—because the malicious executable resides inside the trusted application’s bundle, macOS displays the legitimate application’s name and icon, making the request appear to originate from software the user already trusts. A user who approves the prompt could unintentionally grant the attacker’s code access to protected data.
Apple’s Response: Why the Company Declined to Fix the Issue
Apple reviewed the report and determined that the behavior does not require a security fix. According to Mysk’s disclosure timeline, the issue was reported privately in June before Apple closed the case on July 14. Apple concluded that the reported behavior does not constitute a security vulnerability for several reasons: the attack requires malware to already be running as the current user, does not bypass Gatekeeper or TCC, and still requires users to approve permission requests. The company also noted that Gatekeeper is designed to verify downloaded applications before their first launch rather than monitoring files that users already own and can modify.
Mysk disagrees with that assessment, arguing that macOS should revalidate an application’s code signature after its bundle changes, and that authorization prompts should identify the code-signing identity or Team ID of the executable requesting access rather than displaying only the application’s name and icon. The researchers contend that the user’s trust in the application name and icon is the very mechanism that attackers exploit, and that Apple’s current approach leaves users vulnerable to social engineering attacks.
What Are the Practical Implications for macOS Users?
For the average macOS user, the most immediate risk is that a malicious application already running on the system—such as a trojan or a backdoor installed via phishing or other means—can silently replace the executable of a trusted app like Signal, Slack, or Visual Studio Code. When that modified app requests access to the user’s Desktop, Documents folder, or Keychain, the permission dialog shows the name and icon of the legitimate app, making it highly likely that the user will approve the request. The attacker’s code then gains access to sensitive data.
This attack requires that the user’s system is already compromised with malware that has code execution privileges. However, once that foothold is established, the technique provides a stealthy way to escalate access to protected resources without triggering additional security warnings. The researchers note that the attack does not require any user interaction beyond the initial malware infection, and the subsequent permission prompts are designed to look completely legitimate.
Why the macOS Flaw Is a Social Engineering Problem, Not a Technical Bypass
The core of the debate between Apple and the researchers centers on whether the issue is a security vulnerability or a social engineering problem. Apple argues that since the system still prompts for permissions and the attacker must already have code execution, the behavior is not a vulnerability. But Mysk and Bakry counter that the trust placed in application names and icons is a fundamental part of macOS security, and that the system should not present a legitimate application’s identity for a malicious executable. The researchers point out that the macOS permission prompts show the application name and icon, but not the code-signing identity or Team ID—information that would allow users to distinguish between a legitimate app and a malicious replacement.
From a user experience perspective, the vast majority of macOS users do not check the code-signing identity of every application that requests access to their files. They rely on the application name and icon as indicators of trust. When a dialog appears saying “Signal wants to access your Keychain,” a user who has been using Signal for years is likely to approve it without a second thought. The attacker exploits this assumption.
How Does This Compare to Other macOS Security Issues?
This flaw is reminiscent of previous macOS vulnerabilities where application bundles could be modified after the initial Gatekeeper check. In 2023, researchers discovered a similar issue involving the com.apple.quarantine attribute, which could be removed from downloaded files to bypass Gatekeeper. However, that required user interaction. The current technique is more insidious because the archive-and-restore operation is silent and can be performed by malware without any user awareness.
Unlike some other macOS vulnerabilities that have been patched quickly, this one remains open because Apple classifies it as a design limitation rather than a bug. The company’s stance is that users who have already been compromised by malware face a broader threat landscape, and that this specific technique does not represent a new attack vector. Critics argue that this reasoning ignores the fact that many malware infections rely on exactly such social engineering and permission abuse to achieve their goals.
What Should macOS Users Do to Protect Themselves?
Users should remain cautious when approving requests for access to sensitive files or Keychain data, even when those prompts appear to originate from familiar applications. The researchers recommend that users check the code-signing identity of any application that requests permissions, especially if the request seems unusual. On macOS, users can right-click an application and select “Get Info” to view the code-signing information, but this is not practical for every permission prompt.
More broadly, the incident underscores the importance of maintaining a secure system in the first place. The attack requires malware to already be running on the machine, so preventing initial infection through safe browsing habits, avoiding suspicious downloads, keeping software up to date, and using endpoint protection remains the most effective defense. Users who download applications exclusively from the Mac App Store are not affected by this specific flaw, as those apps are owned by root and cannot be modified by the current user.
What Is the Future of macOS Security in Light of This Disclosure?
This disclosure highlights a growing tension between Apple’s security design philosophy and the practical realities of user behavior. Apple’s security model relies on a combination of code signing, Gatekeeper, and TCC to create a trusted computing environment. However, as the researchers point out, these protections are not continuous. Once an application passes the initial verification, the system trusts it indefinitely, even if its contents are altered. The archive-and-restore trick exploits this gap.
Mysk has called on Apple to implement revalidation of code signatures whenever an application bundle is modified, and to display the Team ID or code-signing identity in permission dialogs. Whether Apple will adopt these changes remains uncertain, but the public disclosure puts pressure on the company to address the underlying trust issue. In the meantime, users should treat all permission requests with a healthy dose of skepticism, especially if they appear after a system update or after running an application that was recently installed.
The incident also serves as a reminder that no operating system is immune to attacks that exploit human psychology. While technical safeguards are essential, they must be paired with user education and clear, actionable information to help people make informed decisions about their data.
