It's time to update your Macs again! This time, I'm not burying the lede. CVE-2025-31250, which was patched in today's release of macOS Sequoia 15.5, allowed for…

…any Application A to make macOS show a permission consent prompt…
…appearing as if it were coming from any Application B…
…with the results of the user's consent response being applied to any Application C.
These did not have to be different applications. In fact, in most normal uses, they would all likely be the same application. Even a case where Applications B and C were the same but different than Application A would be relatively safe (if somewhat useless from Application A's perspective). However, prior to this vulnerability being patched, a lack of validation allowed for Application B (the app the prompt appears to be from) to be different than Application C (the actual application the user's consent response is applied to).

Spoofing these kinds of prompts is not exactly new. In fact, the HackTricks wiki has had a tutorial on how to perform a similar trick on their site for a while. However, their method requires:

the building of an entire fake app in a temporary directory,
the overriding of a shortcut on the Dock, and
the simple hoping that the user clicks on the (now) fake shortcut.
This vulnerability requires none of the above.

TCC
As I explained in my first ever article on this site, TCC is the core permissions system built into Apple's operating systems. It is used by sending messages to the tccd daemon (or rather, by using functions in the private TCC framework). The framework is a private API, so developers don't call the functions directly (instead, public API's call the functions under-the-hood as needed). However, all this wrapping cannot hide the fact that the control mechanism is still simply sending messages to the daemon.

The daemon uses Apple's public (but proprietary) XPC API for messaging (specifically the lower-level dictionary-based API). Prior to this vulnerability being patched, any app with the ability to send XPC messages to tccd could send it a specifically-crafted message that, as described above, would make it display a permission prompt as if it were from one app but then apply the user's response to a completely separate app. But how was this possible, and was it even hard? Before I answer these questions, we need to detour into what will, at first, seem like a completely unrelated topic.

Apple finally adds TCC events to Endpoint Security!
Since the majority of macOS malware circumvents TCC through explicit user approval, it would be incredibly helpful for any security tool to detect this — and possibly override the user’s risky decision. Until now the best (only?) option was to ingest log messages generated by the TCC subsystem. This approach was implemented in a tool dubbed Kronos, written by Calum Hall Luke Roberts (now, of Phorion fame). Unfortunately, as they note, this approach did have it drawbacks: