CoreMedia CVE-2026-112706: a music file without permission

I read a local music file from an iPhone app that had never been granted access to the music library. The returned bytes matched the original file, while the app’s permission status continued to say access had never been requested. The media service had answered using its own authority and neglected the fairly relevant detail of who was asking.

There was no memory corruption involved. The app did not overwrite a permission setting or persuade the user to approve a prompt. A particular kind of media request received an automatic pass from an access check that otherwise knew how to refuse unauthorized callers. The system’s media service could open the file, so it opened it for an app that could not.

Apple identifies this as CVE-2026-112706, a sensitive-data issue addressed with additional restrictions. Its shared credit names Adriatik Raci, Rodolphe BRUNETTI (@eisw0lf) of Lupus Nova, and Chris Bailey of Short Circuit. My submission documented the permission failure, the complete content read and the comparisons that separated this music-library exception from a general ability to read the device.

Apple’s CoreMedia entry for CVE-2026-112706

The useful evidence was the file, not a success message

My test app had never requested Media & Apple Music access. No consent prompt appeared during the read, and I checked that its authorization state remained ungranted throughout. That excluded an earlier approval or an unnoticed permission change as the explanation for what came back.

I recovered the complete local music file and compared it with the source. The bytes matched. This was more than a song title or a service reporting success: the unauthorized app had the file's contents, without a further permission decision standing between the result and the data.

The library used for the completed test was small and controlled. It proved the full read of a real local track; it was not a demonstration of dumping somebody’s populated music collection. The code analysis supported a broader concern about items available through the same library path, but I keep that inference separate from the file I actually recovered. There is plenty wrong with the demonstrated result without upgrading it in the retelling.

The service was answering the wrong authorization question

Media playback is shared work. An application can ask an operating-system service to perform an operation rather than opening every file and handling every detail itself. The service may legitimately have access that the application lacks. That arrangement is useful precisely because the service can do specialized work without giving every app all of its permissions.

It also creates a responsibility: the service has to distinguish what it is allowed to do from what it is allowed to do for this caller. Its own ability to open a music item is not authorization to disclose that item to whichever application asks. Otherwise, all of the app’s restrictions become optional whenever it can find a sufficiently accommodating helper.

The access-checking code already had the information needed to make that distinction. For ordinary protected-file requests, it used the requesting app’s identity to decide whether the operation was allowed. It could correctly deny access even though the service itself had greater privileges. That was the intended separation between the service’s authority and the caller’s authority, working in practice.

The music-library case took an exception. Once the request was classified as belonging to that category, the check treated it as allowed without making the corresponding decision about the caller. Recognizing what kind of item had been requested replaced checking whether the app was entitled to receive it. The service still knew who had asked; this branch simply failed to use that information.

That is the specific mistake behind the familiar security term “confused deputy.” A more privileged component carries out work for a less privileged requester without preserving the requester’s restrictions. My app never needed to become the media service or acquire its permissions. Receiving the file was sufficient.

The app checked permission; the service made an exception

The normal app-facing route failed loudly. Without the required privacy setup, it terminated my test app for a privacy violation. Yet the service holding the file would release its contents through the affected route. The system managed to enforce the restriction in the requesting app and overlook it in the process that actually had the data.

Those were separate checks. The first ran inside the app; the second belonged to the media service. At that second check, ordinary protected-file requests received a caller-specific decision, while music-library requests took the exception. Testing only the convenient app-facing route would have found a working restriction and missed the operation that released the song.

The refusals helped explain the successful read

I tested ordinary protected-file requests from the same unauthorized app. Those were denied. That comparison matters because it shows the test app had not somehow acquired broad file access, and the service was not indiscriminately releasing anything it could open. The successful music read sat beside a working refusal for other protected content.

Requests for an item that was not present did not produce file content either. A real library item did. That helped distinguish a genuine data path from a service that would return a generic success regardless of what had been requested. The positive result was tied to an existing file, and the file comparison confirmed what came back.

The broader limits were tested or examined separately. The write path continued to check the caller, so this did not provide an ability to replace or damage the library. Other protected content did not inherit the media-library exception. Attempts to turn the result into arbitrary-file access did not establish a way outside the library, and Photos access was not part of this finding.

Digital-rights-management protection remained another boundary. The readable content I demonstrated was local, non-DRM music. DRM-protected media did not become unencrypted audio through this failure. A missing privacy check does not automatically defeat a separate system protecting the content itself.

An unchanged setting did not mean the information stayed private

The app’s permission status is especially revealing here. It did not show a newly granted capability because no capability had been granted. The service carried out the read on the app’s behalf despite that state. Looking at the setting afterward would therefore not describe everything the app had obtained.

A music file need not be a state secret for this to be a privacy bug. The user had not authorized the app to read it, and the system had a specific permission meant to enforce that choice. I do not get to waive that decision because I consider the contents uninteresting.

The practical exposure still required an installed app running on the device and content stored locally. This was not an internet-only attack or a demonstration that somebody could reach into any nearby iPhone.

Why the repair belongs with the service

My proposed correction was to apply the caller-specific permission decision to the media-library case as well. The service already received the caller’s identity and already used it for ordinary protected-file requests. It needed to preserve that distinction when the requested item happened to be music.

Apple’s public entry describes additional restrictions, without specifying the internal patch. Its published coverage lists this CVE in the following October 26, 2026 releases. These are Apple’s correction branches; my end-to-end evidence came from the iPhone test described above.

Install the supported update offered for the device. Reviewing the app’s privacy setting alone would not have repaired this behavior, because the setting remained ungranted during the successful test. The correction has to reach the operating-system component that made the wrong access decision.

Thank you to Apple for addressing the issue, and to Adriatik Raci and Rodolphe BRUNETTI for the work acknowledged in the shared credit.

The other CoreMedia finding: video metadata corrupted a display service’s memory

All seven October Apple credits

Apple’s advisories checked October 26, 2026.