A zero-day is a security flaw that is being exploited before the vendor has a fix for it, so named because defenders have had zero days to respond. It is the most alarming category of threat because the usual advice, “keep your software updated”, does not apply yet: there is nothing to update to. This article looks at what these flaws have actually looked like on Apple platforms, drawing on Apple’s own security releases, Google Project Zero and the Citizen Lab, and then at the one thing an unknown exploit still has to do after it succeeds.
One point needs stating up front, because the marketing around this topic is often misleading: no firewall stops an exploit. Not FireAI, not any other. A firewall cannot see a malformed image being parsed inside iMessage or a kernel bug being triggered from a web page. What a firewall can do is watch what happens next, and that turns out to matter more than it first appears.
What the record actually shows
Apple documents every security fix on its Apple security releases page, and when a flaw was already being used against real people it says so with a standard phrase: “Apple is aware of a report that this issue may have been actively exploited.” Reading that page over a few years gives a more grounded picture than any headline. Google Project Zero keeps a complementary public record, its 0-day “In the Wild” tracker, which lists exploits detected in real attacks before a patch existed. Project Zero is careful to note that the tracker only contains cases that were detected, which by definition are the attacker’s failures, so it cannot be used to count how much exploitation actually happens or to compare platforms.
Three documented cases show the shape of the problem.
FORCEDENTRY, 2021
In March 2021 the Citizen Lab at the University of Toronto analysed the phone of a Saudi activist and recovered an exploit it named FORCEDENTRY. It was a zero-click attack: a specially crafted file, delivered through iMessage, that required no tap from the victim and installed NSO Group’s Pegasus spyware. Citizen Lab found evidence it had been in use since at least February 2021. Apple patched the flaw, CVE-2021-30860 in the CoreGraphics image parser, on 13 September 2021 in iOS 14.8, macOS Big Sur 11.6 and a security update for Catalina; its own Big Sur 11.6 release notes confirm the flaw “may have been actively exploited”.
Google Project Zero later published a technical analysis that explains why this kind of thing is so hard to catch. The bug was in the JBIG2 image compression code used inside PDFs. NSO’s exploit used the format’s own logical operators to build, out of more than 70,000 image-segment commands, a small working computer inside the image decoder, and ran the rest of the attack on it. Nothing about that looks like a program from the outside. It is an image, opened by a legitimate, signed system process.
The Hong Kong watering hole, 2021
In late August 2021, Google’s Threat Analysis Group found a watering-hole campaign targeting visitors to the websites of a Hong Kong media outlet and a pro-democracy group. Against Macs it chained a WebKit flaw that had already been patched in January with a kernel privilege-escalation bug, CVE-2021-30869, that was still unpatched on macOS Catalina; Apple fixed it on 23 September 2021. The payload, a backdoor Google called MACMA, could fingerprint the machine, capture the screen, record audio, log keystrokes, upload and download files and run terminal commands.
This example is instructive because the exploit and the payload are separate things. The exploit was invisible: a web page. The payload was an ordinary implanted program that, to be of any use to its operators, had to establish a command-and-control channel and move data off the Mac. Google’s write-up describes exactly that infrastructure.
BLASTPASS, 2023
In September 2023, Citizen Lab reported BLASTPASS, another zero-click iMessage chain delivering Pegasus, this time through PassKit attachments containing malicious images. Apple assigned CVE-2023-41064 and CVE-2023-41061 and shipped fixes for iPhone, iPad, Mac and Apple Watch. Notably, both Apple’s security engineers and Citizen Lab said they believed Lockdown Mode blocked this particular chain, which is the strongest public evidence that reducing attack surface, rather than detecting the attack, is what works against this class of threat.
Why detecting the exploit itself is so hard
Put the three cases side by side and the pattern is clear. The exploit arrives as data (an image, a PDF, a web page) rather than as an app. It is processed by legitimate, Apple-signed code. There is no file for XProtect to match, no unsigned binary for Gatekeeper to refuse, and often no new process for an endpoint-security tool to flag, because the hostile code runs inside a process that was already trusted. Detection, when it happens, is usually forensic: Citizen Lab found FORCEDENTRY by examining artefacts on a device after the fact, not by a scanner catching it live.
This is why Apple’s advice for people who believe they may be targeted is not “install a detector” but Lockdown Mode, which on macOS Ventura and later blocks most message attachment types, disables complex web technologies, refuses unknown FaceTime callers and prevents configuration profiles from being installed. It works by removing the code paths an exploit needs, at a cost in convenience Apple is explicit about.
Why the network step is different
An exploit is the beginning of an attack, not its purpose. Pegasus exists to send messages, photos and microphone audio to its operator. MACMA’s screen captures and keystrokes were worthless on the victim’s disk. In every documented case the value was realised by traffic leaving the machine, and in the MITRE ATT&CK matrix for macOS that phase has two columns of its own, command and control and exfiltration, because it is a distinct, observable step that attackers cannot skip.
This step has properties the exploit did not. It comes from an identifiable process with a code signature (or, tellingly, without one). It goes to a destination with an IP, a hostname and a history. It often uses an unusual port, a raw IP instead of a name, or a hosting provider that has no relation to any app on the Mac. None of that requires knowing the flaw that was used. It only requires seeing the connection and being allowed to say no.
This is the part FireAI is built for. Its per-app rules are keyed to the code signature of the process making the connection, so an implanted binary that is not an app you approved gets a permission prompt rather than a free pass, with the on-device model’s reason shown in plain language. Its threat-intelligence feeds (abuse.ch, Spamhaus, FireHOL, OpenPhish, Phishing Army and the current list of Tor exit nodes) are applied locally, so a known command-and-control address is refused whether or not anything else on the Mac recognised the payload. The Under attack and Paranoid modes tighten the default to blocking unsigned apps and unknown destinations outright, and the kill switch cuts the internet while keeping the local network, which is the right first move when you suspect a compromise and want to preserve evidence.
What this does not cover
Honesty requires the other half of the list. If a payload runs entirely inside an allowed app, for example inside a browser you have already permitted, its traffic inherits that app’s permissions and FireAI will not distinguish it. Encrypted traffic to a destination with a clean reputation looks like any other connection. A feed only contains addresses someone has already reported; a fresh command-and-control server is not on it yet. And FireAI does not detect, remove or analyse the exploit or the implant: it does not scan files or memory, and it is not an antivirus. On a Mac you believe has been compromised by a state-level actor, the correct path is Apple’s threat-notification guidance and a forensic specialist, not a firewall setting.
The practical defence against unknown flaws is therefore layered and unglamorous: apply Apple’s updates the day they ship, since most exploitation targets flaws that already have a fix; turn on Lockdown Mode if your work makes you a plausible target; keep attack surface small; and control which apps on your Mac are allowed to talk to the internet at all, so that when something unknown does get in, the step it cannot skip is the step you are watching.
How FireAI and HisnLabs fit in
FireAI cannot stop an exploit and does not claim to; what it does is sit on the one step every documented case above could not skip, the connection out, and ask, for each unknown process, whether that connection should be allowed at all.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.