Apple’s media service stayed alive while my app corrupted its memory

My app had changed memory inside Apple’s media service, and the process was still running. What gave the change away was its response to the test: four event confirmations, each identifying the object and event I expected. The result showed where the writes had landed without relying on a crash.

In a matched pass with the final writes disabled, there were no confirmations. The preliminary corruption was present in both passes, and the service kept the same process identifier throughout. The difference was the later write and the specific behavior that followed it.

Apple credits Chris Bailey - Short Circuit for CVE-2026-86876 and describes the correction as improved bounds checking for an out-of-bounds write. My submission examined the counting errors behind that write, the live-object experiment and a separate test that ended in a controlled crash. Those were different demonstrations of the same troubled memory handling.

Apple’s CoreMedia advisory entry

The service kept its own event records

The affected service kept timelines of media-related events and records of which objects should be notified about them. My app, running under Apple’s sandbox restrictions, could ask it to create those structures and manage subscriptions. The data lived inside the service’s process; its handling of the app’s requests performed the invalid writes in that memory.

I used the event-notification feature to observe which objects had been affected. The memory errors were in the normal creation and subscription operations. The observation feature supplied evidence of their effect; it did not perform the corrupting writes.

The allocation and the loop disagreed about what to count

The first mistake concerned an array, a sequence of values stored next to one another in memory. The service calculated an item total and used that total to reserve space. It then filled the array by walking through the groups containing those items. The amount of storage and the amount of writing were governed by different quantities.

Those quantities might agree for ordinary inputs. They were not guaranteed to agree for the input an app could supply. When the writing exceeded the reserved space, it continued into neighboring memory. The arithmetic could be internally consistent and still size the wrong thing. Checking the answer does little good if the allocation and the loop are answering different questions.

The second mistake was in an index, the position used to select an entry from another array. The code checked whether the index was below the upper limit. It failed to establish that the position was at or after the beginning. Negative positions passed the one-sided test and referred to memory before the array.

These failures could interact because the earlier corruption affected bookkeeping that later work trusted. The result was more consequential than a count emerging incorrectly in a diagnostic report: the damaged state influenced where another operation would write. My experiment demonstrated a write relative to a neighboring object, with an observable effect on that object’s behavior.

The written value still had limits. In this relative-write result, it was an object reference supplied by the system, not arbitrary bytes of my choosing. The destination was positioned relative to memory involved in the experiment, not an unrestricted absolute address. Describing this as the ability to write anything anywhere would discard the very constraints that the evidence established.

A separate test did crash

Another part of the report demonstrated control over a value in the processor’s working state at a fault. Processors keep temporary working values in registers. In that test, input from the app determined a register’s contents while the media service attempted an invalid memory operation and crashed. The capture came from an iPad running the development software documented in the report.

The live-object experiment showed a system-supplied object reference written to a chosen position relative to another object, with the process still running. The crash captured an app-chosen working value at the fault. The two tests established different kinds of control.

Neither demonstration established arbitrary memory access, execution of my own code, a completed sandbox escape or a kernel effect. Apple’s advisory describes possible circumvention of sandbox restrictions. That is its impact assessment; the narrower result I documented was controlled corruption across the app-to-service boundary. The trigger was a local app, with no demonstrated webpage or remote delivery.

Apple’s published impact and correction

The build comparison had limits of its own

The runtime work covered iPadOS 27 development software and macOS 26.6. Examination of compiled code also found the relevant unchecked operations in older shipping iOS software. That comparison supported concern beyond the development builds, but it was not a substitute for running the complete experiment on every version.

There was a meaningful negative result too: the service connection I tested on macOS 27 was refused. The presence of related code does not establish that the same route is reachable on every platform. Apple’s published correction list is broader than my runtime experiments, and it should be read as Apple’s release coverage rather than a list of devices I independently reproduced the finding on.

The repair needed to reconcile the amount of storage with the amount of writing and check both ends of an allowed index range. My report described those requirements. Apple’s short advisory does not disclose how it changed each operation internally.

Where Apple shipped the correction

Apple lists CVE-2026-86876 in these September 14, 2026 releases:

• iOS 27 and iPadOS 27

• macOS Golden Gate 27

• watchOS 27

• visionOS 27

• iOS 26.7 and iPadOS 26.7

• macOS Tahoe 26.7

• macOS Sequoia 15.8

Install the current supported update offered for the device. This list records the September fixes; it is not a reason to stop updating at those versions. The earlier iPhone, iPad and Mac branches belong in the update check alongside the newest release.

Thank you to Apple’s security and engineering teams for addressing the issue and acknowledging my work.

The five September Apple CVE credits

Related research: ImageIO’s animation-frame bounds failure

Apple’s advisories checked October 26, 2026.