github.com/b1n4r1b01

This vulnerability has been labeled under the title CoreMedia, which is a gigantic sub-system on Apple platforms. CoreMedia includes multiple public and private frameworks in the shared cache including CoreMedia.framework, AVFoundation.framework, MediaToolbox.framework, etc. All of these work hand in hand and provide users with multiple low level IPC endpoints and high level APIs. There are tons of vulnerabilities labeled as CoreMedia listed on Apple's security advisory website and these vulnerabilities range from sensitive file access to metadata corruption in media files. In fact, iOS 18.3, where this bug was patched lists 3 CVEs under the CoreMedia label but only this one is labeled as an UAF issue so we can use that as a starting point for our research.

After a lot of diffing, I found that this specific vulnerability lies in the Remaker sub-system of MediaToolbox.framework. The vulnerability lies in the improper handling of FigRemakerTrack object.

remaker_AddVideoCompositionTrack(FigRemaker, ..., ...)
{

// Allocates FigRemakerTrack (alias channel)
ret = remakerFamily_createChannel(FigRemaker, 0, 'vide', &FigRemakerTrack);

...

// Links FigRemakerTrack to FigRemaker
ret = remakerFamily_finishVideoCompositionChannel(FigRemaker, ..., ...);

if (ret){
    // Failure path, means FigRemakerTrack is not linked to FigRemaker
    goto exit;
}
else{
    // Success path, means FigRemakerTrack is linked to FigRemaker

    ...

    ret = URLAsset->URLAssetCopyTrackByID(URLAsset, user_controlled_trackID, &outTrack);

    if (ret){
        // Failure path, if we can make URLAssetCopyTrackByID fail we never zero out FigRemakerTrack
        goto exit;  // <-- buggy route
    }
    else{
        // Success path

        FigWriter->FigWriter_SetTrackProperty(FigWriter, FigRemakerTrack.someTrackID, "MediaTimeScale", value);

        FigRemakerTrack = 0;
        goto exit;
    }

}

exit:

// This function will call CFRelease on the FigRemakerTrack
remakerFamily_discardChannel(FigRemaker, FigRemakerTrack);

...

}
By providing an OOB user_controlled_trackID we can force the control flow to take the buggy route where we free the FigRemakerTrack object while FigRemaker still holds a reference to it.

Reaching the vulnerable code
Reaching this vulnerable code was quite tricky, as you need to deal with multiple XPC endpoints. In my original POC I had to use 6 XPC endpoints which were com.apple.coremedia.mediaplaybackd.mutablecomposition.xpc, com.apple.coremedia.mediaplaybackd.sandboxserver.xpc, com.apple.coremedia.mediaplaybackd.customurlloader.xpc, com.apple.coremedia.mediaplaybackd.asset, com.apple.coremedia.mediaplaybackd.remaker.xpc, com.apple.coremedia.mediaplaybackd.formatreader.xpc to trigger the bug but in my final poc I boiled them down to just 3 endpoints. Since I'm not using low level XPC to communicate with the endpoint, this poc would only work on iOS 18 version, my tests were specifically done on iOS 18.2.

To reach this path you need to:

Create a Remaker object
Enqueue the buggy AddVideoComposition request
Start processing the request (this should free the FigRemakerTrack)
???
Profit?
Impact
This bug lets you get code execution in mediaplaybackd. In the provided poc, I am simply double free'ing the FigRemakerTrack by first free'ing it with the bug and then closing the XPC connection to trigger cleanup of the FigRemaker object and thus crashing. Exploiting this kind of CoreFoundation UAF has been made hard since iOS 18 due to changes in the CoreFoundation allocator. But exploiting this bug on iOS 17 should be manageable due to a weaker malloc type implementation, I was very reliably able to place fake objects after the first free on iOS 17.

In-The-Wild angle
If you look at this bug's advisory you can find that Apple clearly says that this bug was a part of some iOS chain: "Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 17.2.". Now the weird part is you don't see the exploited against versions of iOS before iOS XX.X line very often in security updates, if we look around CVEs from those days we see a WebKit -> UIProcess (I guess?) bug CVE-2025-24201 with very similar impact description "This is a supplementary fix for an attack that was blocked in iOS 17.2. (Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 17.2.)" And if we go back to iOS 17.2/17.3 we see couple of CVEs which look like some chain all labeled as actively exploited and not designated to any 3rd party like Google TAG or any human rights security lab. Now I believe this mediaplaybackd sandbox escape was a 2nd stage sandbox escape in an iOS ITW chain. Here's what my speculated iOS 17 chain looks like (could be totally wrong but we'll probably never know):

WebKit (CVE-2024-23222)
↓
UIProc sbx (CVE-2025-24201)
↓
mediaplaybackd sbx (CVE-2025-24085)
↓
Kernel ???
↓
PAC?/PPL (CVE-2024-23225 / CVE-2024-23296)
Question is: how many pivots are too many pivots? :P