Apple has shipped an emergency fix for CVE-2026-20700, a memory-corruption flaw in iOS and iPadOS that the company says was already abused "in an extremely sophisticated attack against specific targeted individuals" — its first confirmed in-the-wild zero-day of 2026. The bug affects iPhones and iPads on releases prior to iOS 26 and is resolved in iOS 26.3 and iPadOS 26.3. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to the Known Exploited Vulnerabilities catalog one day after Apple's disclosure, making an immediate update the clear priority for affected devices.

What was patched

The vulnerability lives in dyld, Apple's open-source dynamic link editor responsible for securely loading applications at runtime. According to Apple, an attacker who already has the ability to write to memory may be able to leverage the flaw to execute arbitrary code. In the official CVE record dated February 11, 2026, the issue is described as a memory corruption problem addressed through improved state management, with fixes landing in iOS 26.3 and iPadOS 26.3 as well as macOS Tahoe 26.3 and tvOS.

The flaw was reported by Google's Threat Intelligence Group. Apple seldom discusses active exploitation in any detail, but it noted that the observed attacks mirrored earlier campaigns directed at a narrow group of high-value targets — the hallmark of commercial spyware operations.

Connection to two WebKit bugs

Apple also tied two previously disclosed WebKit vulnerabilities — CVE-2025-14174 and CVE-2025-43529 — to attacks that involved CVE-2026-20700, without spelling out exactly how the three fit together. All three are memory-corruption defects in mobile operating systems, the class of bug that VulnCheck's Caitlin Condon noted is routinely weaponized in targeted spyware against dissidents, journalists, and public figures.

The iOS 26.3 and iPadOS 26.3 updates close 38 vulnerabilities in total, but CVE-2026-20700 was the only one Apple flagged as actively exploited ahead of public disclosure.

A public research exploration of the dyld primitive

Separately from Apple's limited account of the real-world attacks, an independent researcher has published a proof-of-concept repository that probes the underlying mechanism. This is a controlled research exploration — not the exploit chain used against the targeted individuals — framed around dyld's page-in linking and chained-fixup machinery as a PAC signing oracle.

On arm64e, every function pointer is hardware-authenticated via pointer authentication codes (PAC). The repository's stated aim is to demonstrate that dyld can be steered — through a hand-crafted Mach-O — into producing PAC-valid pointers in attacker-chosen locations using nothing more than its own normal fixup path. The author reports testing on an iPhone 14 (iOS 18.5, arm64e).

The write-up describes three observed behaviors:

  • Controlled chained-fixup bind — dyld accepts a crafted Mach-O dylib and writes PAC-valid function pointers into chosen slots within its own __DATA.
  • Deterministic crash in fixupPage64 — malformed page_start / next values push dyld past the page boundary, demonstrating that the branch is reachable.
  • Dispatch event-loop execution — the PAC-valid pointer dyld writes is registered as a dispatch_source_t timer handler and invoked naturally through the event loop, without the PoC ever calling it directly.

The repository layout:


dyld-signing-oracle-poc/
├── Makefile                        ← orchestrates the full pipeline
├── src/
│   └── launcher.c                  ← iOS launcher (2 threads + dispatch chain-close)
├── generators/
│   ├── gen_exports.py              ← generates exports.c  (N dummy symbols)
│   ├── gen_client.py               ← generates client.c  (N imports, dyld gate stress)
│   └── gen_malformed_dylib.py      ← generates libmalformed.dylib (hand-crafted Mach-O)
├── tools/
│   ├── scan_pointers.py            ← classifies Mach-O pointer sections as W/R
│   └── inspect_fixups.py           ← parses LC_DYLD_CHAINED_FIXUPS header
└── blog/
    ├── it/
    │   └── dyld-signing-oracle.md  ← write-up completo in italiano
    └── en/
        └── dyld-signing-oracle.md  ← full write-up in English

Building the project requires the iOS SDK, whose path can be located with:


xcrun --sdk iphoneos --show-sdk-path

Technical background

dyld resolves imported symbols at load time by applying fixups — rewriting placeholder pointers in a binary's data segments to the real runtime addresses of the functions and data they reference. Modern Mach-O binaries encode these as chained fixups: rather than a flat list of relocations, each fixup record stores a small next offset pointing to the following record, forming a linked chain walked page by page. The LC_DYLD_CHAINED_FIXUPS load command holds the metadata that tells dyld how to traverse those chains.

On Apple silicon's arm64e ABI, pointer authentication adds a cryptographic signature (PAC) to pointers stored in memory; the CPU validates that signature before a signed pointer is dereferenced or branched to, which is designed to stop attackers from forging function pointers. Because dyld is one of the trusted components that legitimately signs pointers while binding imports, any way to influence which values it signs — by feeding it a malformed but accepted chained-fixup structure — is valuable to an attacker, since it can turn a memory-write primitive into control over a PAC-valid pointer.

As a generic illustration, a tool that parses chained-fixup metadata from a Mach-O file might be invoked like:


otool -l ./target.dylib | grep -A4 LC_DYLD_CHAINED_FIXUPS

The specifics of how Apple's patch hardens this path are captured in the "improved state management" language of the advisory, which tightens dyld's validation of fixup state so malformed chains no longer drive it out of bounds.

Mitigation

There is no configuration workaround: the fix is to update. Affected iPhones and iPads should be moved to iOS 26.3 / iPadOS 26.3 immediately, and the same release train (macOS Tahoe 26.3, tvOS) carries the corresponding fix on other Apple platforms. Given that CVE-2026-20700 is confirmed exploited and now listed in CISA's KEV catalog, organizations managing fleets of Apple devices should treat the update as urgent.