AppleSEPKeyStore IOKit Use-After-Free (CVE-2026-20637)

Metadata

Affected Target

Summary

The AppleSEPKeyStore kernel driver exposes an IOKit user client (AppleKeyStore) whose command gate can be freed while still being accessed, producing a use-after-free. The PoC opens repeated IOServiceOpen connections while separate threads race IOConnectCallMethod calls against IOServiceClose on the same connection with no delay, creating a tight window where the command gate is used after being torn down. When the race lands, the kernel panics with an “element modified after free” error inside IOCommandGate. Apple’s own advisory (iOS 26.3 / iPadOS 26.3) describes this as a use-after-free “addressed with improved memory management” in AppleKeyStore.

Vulnerability Details

Root Cause

A race between IOKit user-client method invocation (IOConnectCallMethod) and connection teardown (IOServiceClose) allows the underlying IOCommandGate object to be freed by one thread while another thread is still dereferencing it, corrupting freed memory.

Attack Vector

1. Open the IOKit service AppleKeyStore via IOServiceGetMatchingService / IOServiceOpen, repeating across 100,000 iterations with varying client “type” values.
2. Spawn 8 high-priority “caller” threads that continuously invoke IOConnectCallMethod against the current connection across selectors 0–15, with no throttling.
3. Simultaneously spawn 4 high-priority “closer” threads that continuously call IOServiceClose on the same connection and immediately clear it.
4. The unsynchronized close-vs-call race eventually frees the command gate while a caller thread is still operating on it, causing a kernel panic.

Impact

Reliable local denial of service (kernel panic / device reboot); the underlying UAF class of bug is also a plausible primitive for local privilege escalation if made deterministic and paired with heap grooming, though this PoC only demonstrates the crash.

Environment / Lab Setup

Target:   iOS/iPadOS 26.1-26.2 or macOS 26.1-26.2, physical device (simulator cannot reach the driver)
Attacker: Xcode, ability to build and run a native Objective-C IOKit-calling app/binary on the target device

Proof of Concept

PoC Script

See poc.m (standalone command-line harness) and ViewController.m (the same trigger logic wired into a one-button iOS app) in this folder.

1

clang -framework Foundation -framework IOKit poc.m -o poc && ./poc

The program locates the AppleKeyStore IOKit service, then spins up 8 caller threads hammering IOConnectCallMethod and 4 closer threads hammering IOServiceClose, while the main thread opens 100,000 new connections back-to-back with no delay, maximizing the odds of hitting the use-after-free race.

Detection & Indicators of Compromise

panic(cpu 4 caller 0xfffffff015b84ae0): [iokit.IOCommandGate]: element modified after free
  (off:72, val:0xfffffffffffffe00, sz:80, ptr:0xffffffe69b7d0db0)
Kernel Extensions in backtrace:
   com.apple.driver.AppleSEPKeyStore(2.0)[...]

Signs of compromise:

• Device panic logs referencing iokit.IOCommandGate “element modified after free” with AppleSEPKeyStore in the backtrace.
• Repeated, rapid IOServiceOpen/IOServiceClose cycles against the AppleKeyStore service from a single unprivileged process shortly before a panic.
• Unexplained spontaneous reboots correlating with a third-party app running heavy multithreaded IOKit activity.

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/enfilade-labs/CVE-2026-20637-AppleSEPKeyStore-UAF on 2026-07-05.