Shortcuts CVE-2026-112455: private text in action choices

My app received message and note text while Shortcuts was working out the possible choices for an action. No Shortcut needed to finish running. The information was already in the helper's answer, returned to an application that had not been authorized to read it.

The more interesting result was the refusal next to it. Another operation in the same service rejected my app. The service had access-control machinery and used it. The operation that helped find an action's possible inputs simply went ahead under the service's own authority. Apparently, preparing to do something was entitled to considerably more privacy latitude than actually doing it.

That was the authorization gap in my Shortcuts report, now covered by CVE-2026-112455. It matters because software does a surprising amount of reading before presenting an apparently harmless choice. The disclosure had happened before there was any final action for a permission check to stop.

The descriptions contained the messages

In my captures, the returned descriptions included complete message text and the sender's handle, such as a phone number or messaging email address. They were not merely anonymous references that would require a second authorized read to become useful. An unauthorized application could already inspect what had been returned. Calling a field a display description does not make the sentence inside it less of a private message.

Notes made that point particularly clear. I checked a note with text beyond its heading, and the returned description contained its body. Notes without additional body text produced an empty-content indication in that part of the representation. The difference tied the response to the note's content rather than to a generic label, an app name or some unrelated cached description.

The same report also captured a Journal entry’s body after I added an entry and queried again, along with conversation names or handles from Messages. Those are different privacy consequences: the text reveals what was written, while the conversation list reveals whom the user talks to. Neither requires opening the original database from my app.

Other populated responses were less expansive but still useful to an unauthorized reader. Weather returned saved places with their coordinates; those describe places the user follows, not a live location fix. Voice Memos returned recording names, creation information and durations. Names derived from where a recording was made can reveal context, but the reply did not include the audio or a transcript. I am keeping those distinctions because “access to Voice Memos” is a much larger claim than the fields the service actually returned.

The disclosure was complete when that reply reached my app. It did not need to open the source database, display a list or persuade the user to select an item: the private text was already readable in the answer. No consent step occurred in those tests.

The private data inside a choice

An action that uses a note needs a way to identify the note. Shortcuts asks the app that owns the records for possible choices and descriptions a person can recognize. The system helper coordinates that lookup, using access an unrelated app may not have.

In the affected path, that helper ran the lookup under its own identity and returned the answer without the required caller check. The owning app had supplied information for a system service; a different app received it. The helper’s permission to perform the lookup had become a reason to disclose the result to a caller whose access it had not checked.

The service could say no. It was selective about when.

The strongest comparison came from other operations exposed by the same service. A broader data-query operation refused the unentitled app. Operations dealing with the user's stored shortcuts also had authorization checks. This was not an investigation where every request succeeded and the researcher declared the whole platform open for business.

Those neighboring checks gave the successful read context. They showed that the service knew how to reject a caller, that the rejection machinery was present, and that ordinary reachability did not imply unrestricted access. They also made the gap more concrete: one category of operation enforced the caller's authority while the supporting lookup that returned private text did not.

I also checked that responses tracked the requested action rather than arriving as a fixed bundle of data. Requests unrelated to a real action produced no content. The returned information belonged to the action being resolved. Together with the actual message and note text, that control helped distinguish a meaningful lookup from a misleading response that merely looked populated.

Other categories returned result containers with no records in these tests. That showed a difference between handling a request and refusing it; it did not establish that content had been disclosed. The populated message, note, Journal and descriptive-field captures are the evidence for the privacy impact.

My runtime evidence came from a development-signed test app on an iPhone running an iOS 27 beta. The app had no private entitlement granting the access at issue. Those are the conditions I established for this report. Apple's coverage of additional platforms comes from its advisories; my on-device tests for this finding were on that iPhone.

The captured content included the text and descriptive fields discussed above. I did not demonstrate access to message attachments, voice-message audio, photo contents or a persisted write through this path. This was an authorization failure in a local service used by an installed app, with no demonstrated memory corruption, kernel compromise or remote Internet attack.

Permission has to arrive before the answer

The obvious place to think about authorization is the operation with a visible consequence: send something, modify something, run an automation. That can leave the preparatory work looking unimportant. But finding candidates for an action may require reading precisely the private information that the final operation is supposed to protect.

A later refusal cannot undo that read. If a helper returns the full text of a note as a possible input, blocking a subsequent action does not make the requesting app forget the note. The permission decision must therefore cover the resolution step itself, including which caller is requesting it and what data the answer will contain.

This is the part of the bug I find most useful beyond Shortcuts. Supporting operations deserve to be assessed by their outputs. If an operation returns private text, it is a private-data read, however administrative its name or preparatory its purpose may sound. The neighboring checks were doing real work. They simply were not protecting this answer.

Apple describes CVE-2026-112455 as an authorization issue that could allow an app to access sensitive user data, addressed through improved state management. That description confirms the vendor's impact assessment and release coverage. The entry does not spell out how Apple changed the helper.

Apple’s Shortcuts entry for CVE-2026-112455

Apple lists the fix in these releases, published October 26, 2026:

Use the applicable supported update for each device. Apple’s entry does not report active exploitation; the research described here is evidence from my testing.

Apple credits Chris Bailey - Short Circuit and Rahul Raj. Thank you to Rahul and to Apple’s security and engineering teams for their contributions to getting this addressed.

Apple’s published Shortcuts credits

The seven Apple CVEs credited to Short Circuit this October

Apple’s advisories checked October 26, 2026.