CoreMedia CVE-2026-112688: the check that let the write happen

I could make a video overwrite working memory in a system display service. CoreMedia had already noticed that the metadata exceeded its limits, but it carried on writing anyway. The check existed; what it lacked was any useful influence over the operation it was supposedly checking.

Values I selected in the video appeared in the service’s damaged working state, and the service subsequently crashed trying to use that state. That gave me a direct connection between file content and the failure, rather than an unexplained playback crash. The affected service was running outside the process handling the webpage.

Apple credits Chris Bailey of Short Circuit alongside 정우 하 (@0xfa11babe) for CVE-2026-112688 and describes the correction as improved memory handling.

Apple’s CoreMedia entry for CVE-2026-112688

The part of the video that was supposed to describe the picture

The vulnerable data was Dolby Vision metadata, which helps the display system determine how to present a video's picture. CoreMedia translated those descriptions into groups of records in temporary working memory. Each group had a limited amount of room, and the parser used a record count to decide where its next write belonged.

The file could influence both the count and the contents of the records. An excessive count could therefore send a write beyond the space reserved for that group. The parser needed to reject the value before using it to calculate a memory location. It already had a comparison intended to recognize that situation.

An error message is a poor substitute for stopping

The comparison looked promising until I followed the branch taken by an excessive count. It checked whether diagnostic logging was enabled, then rejoined the record-writing operation. The original, unsafe count was still in use. The code had a way to complain about the input without declining to process it.

That distinction was the defect. The same value that failed the comparison still determined where data would be written. Rejecting the record or enforcing a safe bound at that operation would have prevented the write. Whether a warning appeared in the log made no difference to the memory being changed.

I also examined an implementation in an earlier software branch that looked more defensive. It restricted how a counter would advance, but the current write still used the untrusted value. Correcting the bookkeeping for the next operation cannot retroactively make this operation safe. Different code can therefore preserve the same defect, even when one version looks reassuringly more complicated.

The first overwrite changed the rules for the next one

The initial out-of-bounds write was only part of the problem. Out of bounds means the program writes beyond the storage reserved for the object it is working on. What occupies the neighboring memory determines what happens next. Some overwritten bytes may be unused; others may still be essential to the program.

Here, an earlier group of records could overrun its storage and damage the count for a later group. That later count was not discarded as suspect. The parser subsequently trusted it to decide how much more data to write. The first failure therefore changed the bookkeeping that governed the following operation, extending the corruption beyond the initial overrun.

This is why describing the issue simply as an oversized record misses the consequential part. The damaged value was an instruction to the parser about its own future work. Once file content could alter that value, later processing relied on information that the earlier write had already corrupted.

The contents of the records mattered too. I was not limited to making the software spill whatever happened to be adjacent in the file. Selected data from the media influenced the working state that was overwritten.

The comparison video did its job

A crash report is evidence, but it does not automatically explain itself. Media playback crosses enough components that an unrelated failure can look persuasive if all you have is a timestamp and a broken screen. My report included a conforming video sent through the same page and playback path as the failing case. The relevant difference was in the metadata counts.

I recorded process and crash inventories around the runs. The comparison video left the display service running, while the malformed metadata produced a new crash report for that service and a subsequent restart. This was a recorded comparison, rather than an assumption that ordinary video probably worked.

The crash evidence also preserved values selected in the media file. Separate failing runs showed different chosen values being used after corruption. That made the relationship stronger than “I loaded a video and something crashed”: the file influenced the state the service later tried to use, and the failure reflected that state.

I also exercised the parser directly and captured its state after processing. That isolated the corruption in the parser. The browser-based capture established that playback could carry the same defect into a system service in the tested configuration.

The webpage was not where the crash ended up

Safari handled the page, but the affected metadata also reached the system machinery responsible for presenting the video. The crash occurred in a service involved in composing what appears on the display. That service ran outside the webpage process and under a different set of restrictions.

For the captured iPhone playback runs, I used a test configuration with the relevant display-processing path enabled. That condition is part of the result. The captures do not establish the same browser reachability on every device under its default settings. The parser defect also reproduced in a direct test, but that separate result does not remove the condition on the playback demonstration.

What stopped short of code execution

My tests demonstrated controlled memory corruption and a crash, not control over which instructions executed. They also did not return information from the damaged service to the webpage. Apple lists possible arbitrary code execution in its impact assessment; that is a broader potential outcome than the result I obtained.

Apple’s published impact assessment

The control-flow routes I examined used pointer authentication, which checks certain references before execution follows them. That analysis identified a further obstacle to turning damaged data into control over the program. I did not obtain controlled execution through those routes.

That is a limit on what I established, not proof that exploitation was impossible. The pointer protections and the parser’s failure are separate findings about the same path.

The correction has to affect the write

My proposed correction focused on the operation that used the count. A meaningful bound must govern the destination and extent of the write, or stop the operation before it occurs. That is a different requirement from detecting that the count is excessive, recording it or adjusting a later counter update.

Apple describes the shipped correction as improved memory handling. I am not claiming that wording confirms a particular internal implementation. The published release coverage is the practical part for device owners: Apple lists this CVE in the following October 26, 2026 updates.

Install the supported update offered for the device, including the appropriate earlier macOS branch where applicable. The release list comes from Apple; the research combined direct device tests with examination of shipped code.

Thank you to Apple for fixing the issue and crediting the work, and to 정우 하 for the contribution recognized alongside mine.

The other CoreMedia finding: a media service skipped the app’s permission check

All seven October Apple credits

Apple’s advisories checked October 26, 2026.