What Is Pointer Authentication? Apple PAC Explained

Pointer authentication is a processor feature that signs important memory pointers with a secret key and checks the signature before the pointer is used. On Apple silicon, Pointer Authentication Codes (PAC) protect return addresses and function pointers, so an attacker who corrupts memory cannot simply redirect code. A PAC bypass is the bug that defeats this check, which is why it shows up as a required step in modern iPhone exploit chains.

What is pointer authentication?

Pointer authentication is a hardware check that stops a program from jumping to a code address it did not legitimately create. The CPU adds a short cryptographic signature to a pointer and refuses to use it if the signature does not match.

A 64-bit pointer has more bits than the address space needs. Pointer authentication uses those spare upper bits to store a Pointer Authentication Code. The code is computed from the pointer value, a context value and a key the processor holds. Software cannot read the key.

When the program later uses the pointer, for example when returning from a function, the CPU recomputes the code. If it matches, the CPU strips it and continues. If it does not, the pointer is treated as invalid and the process crashes instead of running attacker-chosen code.

Why does Apple use pointer authentication?

Apple uses pointer authentication to make memory corruption bugs much harder to turn into working exploits. As Sekoia put it in its November 2026 report, arbitrary read and write access in the browser renderer "is no longer sufficient" on modern Apple silicon, because an improperly signed pointer crashes the process.

Without pointer authentication, a typical browser exploit followed a familiar path:

1. Trigger a memory corruption bug in the JavaScript engine.
2. Build read and write primitives from it.
3. Overwrite a function pointer or return address.
4. Redirect execution to code the attacker controls.

Pointer authentication breaks step 3. The attacker can still write any value they like into memory, but the forged pointer has no valid signature, so step 4 fails.

What is a PAC bypass?

A PAC bypass is a vulnerability that lets an attacker produce or reuse validly signed pointers without knowing the key. With one, the attacker can again redirect execution even though the signature check is still switched on.

Apple's advisories describe this class in consistent language: "An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication." That wording tells you two things. The bug is not an entry point, because the attacker already needs memory read and write. And it is still essential, because without it the earlier bug cannot finish the job.

CVE-2024-27834 is a good example. Apple fixed it in May 2024 in iOS 16.7.8, iOS 17.5, macOS Sonoma 14.5, Safari 17.5, tvOS 17.5 and watchOS 10.5. Its CVSS score is only 5.5. In November 2026, CISA added it to the KEV catalog after Sekoia found it as the second stage of an APT29-linked chain that stole cookies from iPhones on iOS 16. The full story is in our coverage of CVE-2024-27834 and the Poisoned Source campaign.

How does a PAC bypass fit into an exploit chain?

A PAC bypass is the middle link that converts a memory bug into code execution. Modern iPhone attacks usually chain several separate vulnerabilities, and the bypass sits between the initial bug and the sandbox escape.

A typical Apple browser chain looks like this:

• Initial bug: a WebKit flaw reached through malicious web content gives read and write in the renderer.
• PAC bypass: a second flaw lets the attacker forge signed pointers and run code.
• Sandbox escape: further bugs break out of the restricted WebContent process.
• Kernel bug: a final flaw gives kernel read and write for full device access.

Short chains stop early. In the Sekoia case, the iOS 16 chain stopped after the PAC bypass and used the renderer's access to read cookie files. The longer iOS 18.5 chain added sandbox escapes and a kernel bug and took messages, photos and Keychain data.

Why low CVSS scores mislead on PAC bypasses

CVSS rates each bug in isolation. A PAC bypass requires prior memory access, so it scores as local, low complexity and integrity impact only. That is accurate for the bug alone and misleading for the chain.

When you see a PAC bypass in a vendor advisory or the KEV catalog, read it as "someone needed this to finish an exploit". Apple fixes these alongside WebKit and kernel bugs in the same release. Taking the whole update closes the chain. Picking and choosing does not.

What defenders should take from this

You cannot configure pointer authentication. It is built into the chip and the operating system. What you control is whether devices receive the fixes that keep it effective:

• Keep iOS, iPadOS and macOS on a supported release and at the latest patch level, so each published PAC bypass is closed.
• Enforce minimum versions through MDM rather than relying on users. Our guide on enforcing a minimum iOS version with MDM walks through compliance rules and update deadlines.
• Treat devices that cannot run a current release as exposed, even if they show the last update available to them. The case for replacing them is in why unsupported iPhones belong on a retirement schedule.

Pointer authentication raised the cost of iPhone exploitation. It did not remove the need to patch, because every bypass Apple fixes is still useful against the devices that never installed the fix.