Zero-Click Exploits

A zero-click exploit requires no interaction from the target. No clicking a link, no opening an attachment, no visiting a website. The attacker sends a message — or a packet, or an image — and the target's device is compromised. This is the apex predator of the vulnerability ecosystem, and the NSO Group's FORCEDENTRY exploit against iMessage is the most extraordinary example ever publicly documented.

Building a Computer Inside a Codec

Google Project Zero's analysis of FORCEDENTRY reads like science fiction written by someone who actually understands CPU architecture. The exploit arrives as an iMessage containing a PDF. Inside the PDF is a JBIG2-compressed image stream. JBIG2 is an image codec designed for compressing black-and-white document scans — fax pages, basically. It has a feature called "symbol segments" that lets it describe recurring glyphs as templates and differences. This is where things go sideways.¹

JBIG2's refinement coding works by taking a reference bitmap and applying a series of XOR, AND, and OR operations to produce the output bitmap. The exploit authors discovered that these operations, combined with JBIG2's ability to reference the output of previous operations as input to later ones, constitute something very close to a universal logic gate set. By carefully crafting the JBIG2 data, they constructed a complete virtual computer architecture inside the codec — with registers, a full 64-bit adder, and comparators. They then wrote a program for this virtual computer that implements a more conventional exploit, escaping the IMTranscoderAgent sandbox and achieving arbitrary code execution.¹

I want to be precise about what this means. The attackers did not find a buffer overflow. They did not corrupt memory directly. They abused the intended functionality of an image codec to build a Turing-complete computation environment, then ran an exploit program inside that environment. The JBIG2 standard was never designed to support arbitrary computation, but the combination of bitwise operations and self-reference made it accidentally capable of it. This is the computational equivalent of discovering that your fax machine contains a hidden general-purpose computer.

The implications for supply-chain-trust are severe. JBIG2 is present in every PDF renderer on every Apple device. It processes untrusted input — any image in any PDF. Before this exploit was discovered and patched, every iPhone in the world could be silently compromised by a text message. The attack surface isn't a bug in the traditional sense; it's an emergent property of a specification that was more computationally powerful than its authors intended.

The PGP Problem

If FORCEDENTRY represents the bleeding edge of exploit craft, PGP represents the opposite failure mode: a security tool that is technically not broken but practically unusable, and whose continued existence makes everyone less safe. Latacora's comprehensive teardown is devastating.²

The core argument: PGP was designed in the 1990s for a threat model (email encryption for privacy advocates) that has been superseded by modern tools that are simpler, safer, and more narrowly targeted. PGP's problems are not individual bugs but architectural:

Complexity creates attack surface. PGP supports RSA, DSA, ElGamal, ECDH, ECDSA, EdDSA, multiple hash algorithms, multiple symmetric ciphers, compression, signatures, encryption, key exchange, web of trust, key servers, subkeys, revocation certificates, and arbitrary packet nesting. Each of these features has to be implemented correctly and interact safely with every other feature. The result is that PGP implementations have had a steady stream of serious vulnerabilities — EFAIL exploited the interaction between encryption and HTML rendering, SigSpoof exploited GnuPG's status interface, and there have been multiple AEAD-related issues.²

Long-lived keys are a liability. PGP keys are designed to last years or decades. Modern cryptographic practice has moved toward ephemeral keys that provide forward secrecy — if a key is compromised, only the current session is exposed, not every message ever encrypted with that key. Signal generates new keys for every message. PGP reuses the same key for everything, forever, and if that key is compromised (or if the passphrase is brute-forced, or if the key server serves a poisoned key), the attacker gets everything.

The web of trust never worked. PGP's decentralised trust model requires users to verify and sign each other's keys. In practice, almost nobody does this, and the key servers are a mess — anyone can upload a key claiming to be anyone, and keys can't be deleted. The SKS key server network was effectively DoS'd in 2019 by poisoned key certificates that caused GnuPG to hang when processing them.

Latacora's recommendation: use Signal for messaging, age or libsodium for file encryption, and signify or minisign for signatures. Each tool does one thing, does it well, and makes it hard to misuse. PGP's sin is doing too many things, all of them slightly wrong.

The Portal Hole

The <portal> HTML element security analysis illustrates how new web platform features can punch through existing security boundaries in unexpected ways. Portals were designed as a smoother alternative to iframes — they render content from another origin and can be "activated" to become the top-level page, enabling seamless page transitions.³

The security researcher found that portals, because they're treated as top-level browsing contexts rather than embedded frames, weren't subject to the same restrictions as iframes. Specifically: you could load file: and chrome: URLs in a portal, bypassing the restrictions that prevent web pages from accessing local files. This resulted in a Same Origin Policy bypass and local file disclosure — a $10,000 Chrome bug bounty.³

The deeper issue: the portal specification had been shipped to Chrome Canary without "Security Considerations" figured out. This isn't unusual — new web platform features regularly introduce security gaps because the security model of the web (Same Origin Policy, Content Security Policy, frame restrictions) evolved incrementally and doesn't have a clean theory that you can apply to novel features. Every new capability is a new surface that has to be audited against every existing assumption.

Mercurial Cores

There's a hardware dimension to this too. Google and Facebook have both published research showing that modern CPUs are silently producing wrong results more frequently than previously believed. Google calls these "mercurial cores" — individual CPU cores that occasionally miscalculate, under unpredictable circumstances, in ways that defy conventional diagnostics.⁴

These aren't design bugs. They're not caught by manufacturing tests. They emerge after deployment, possibly as a result of physical deterioration or thermal effects at ever-smaller feature sizes. Google's paper documents machines that were "credibly accused of corrupting multiple different stable well-debugged large-scale applications" — the same machine, repeatedly, by independent teams — while conventional hardware diagnostics found nothing wrong.⁴

At hyperscale, rare events become routine. If a CPU core has a one-in-a-billion chance of producing a wrong result per operation, and you're running billions of operations per second across hundreds of thousands of cores, you'll see multiple silent corruptions per day. Facebook's companion paper proposes detection strategies, but the root cause — semiconductor manufacturing pushed to limits where reliability guarantees weaken — doesn't have a simple fix. This is a new kind of attack surface: not exploitable by an adversary, but capable of corrupting data and computations in ways that no software validation can fully prevent.