macOS: Researchers Replace Downloaded Apps with Malicious Twins - and Apple Shrugs

Researchers demonstrate that a local attacker can intercept and replace a macOS application during its download, before Gatekeeper has finished its job. Apple, informed, downplays it. Details of a "dumb and nasty" attack that highlights a gray area in the macOS trust model.

The Register publishes on July 23, 2026 the work of researchers describing a local attack on macOS consisting of replacing a downloaded application with a "malicious twin" - a copy signed by the attacker and disguised as a legitimate app - before the system has completed its security verification. Apple's response: the company does not see this as a vulnerability to fix.

Facts

• Who: researchers cited by The Register (name of the team and link to the article below). Publication of the demonstration on 2026-07-23.
• What: during an application download in a user folder (typically ~/Downloads), a third-party process with user rights can, under certain conditions, replace the .app or .dmg file between the moment the download ends and the moment Gatekeeper / XProtect perform the signature verification at first launch. The user then believes they are launching Firefox, Discord, or VS Code, and actually launches a malicious app signed differently but visually identical.
• Prerequisites: the attacker already has local execution with user rights (no magical remote RCE). This point is central to understanding Apple's response.
• Apple's Response: The Register reports that Apple, contacted, considers the scenario as covered by the standard threat model - a process that already has user rights can, in any case, do a lot of damage.

Analysis

Technically, Apple is not strictly wrong: in the macOS threat model, a binary running with user rights already has access to everything the user can reach. The signature, Gatekeeper, and Notarization mainly protect against the binary downloaded from the Web by an uncompromised user, not against an attacker who is already executing locally.

But it also overlooks an important nuance. The realistic scenario is the slightly malicious app already installed - a free utility retrieved from a third-party site, or a menu-bar extension - which, in the background, waits for the user's downloads and replaces those that interest it. The attacker thus increases his persistence: instead of remaining a small parasitic app, he becomes "Firefox" or "Slack" in the victim's mind, with the usage habits that go with it (access to the keychain, permissions, startup behavior). This is a posture escalation, not a privilege escalation in the Unix sense.

This is exactly the type of scenario that intelligence and APTs exploit: they do not look for the spectacular CVE, they stack small "not serious" primitives until it holds. Apple's position - "no vulnerability" - is technically defensible, but it leaves a usable primitive permanently.

What to do now

• macOS Users: download your apps from official primary sources (editor sites, Mac App Store, Homebrew with checksum verification) and launch them immediately, without leaving a mounted .dmg or a .app in Downloads for hours.
• Check the signature manually for sensitive installations: codesign -dv -verbose=4 /path/to/App.app and compare the announced Team Identifier with the one documented by the publisher.
• Fleet Admins: harden the policy via MDM (Jamf, Kandji, Intune) to restrict authorized Team IDs and prohibit non-notarized binaries - this is the enterprise lever that the user alone does not have.
• Follow-up: we will follow this story, especially if public exploits or campaigns using this primitive emerge. At this stage, there is no public PoC of exploitation under real conditions.

Primary Sources: to be consulted in The Register for the technical details and the timeline with Apple.