In April 2024, Microsoft uncovered a vulnerability in macOS that could allow specially crafted codes to escape the App Sandbox and run unrestricted on the system. An attacker could create an exploit to escape the App Sandbox without user interaction required for any sandboxed app using security-scoped bookmarks. With the ability to run code unrestricted on the affected device, attackers could perform further malicious actions like elevating privileges, exfiltrating data, and deploying additional payloads. Microsoft’s Threat Intelligence research demonstrates that these exploits would need to be complex, and require Office macros to be enabled, in order to successfully target the Microsoft Office app.
Similar to our discovery of another sandbox escape vulnerability in 2022, we uncovered this issue while researching potential methods to run and detect malicious macros in Microsoft Office on macOS. After discovering this issue, we shared our findings with Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Apple released a fix for this vulnerability, now identified as CVE-2025-31191, as part of security updates released on March 31, 2025. We want to thank the Apple product security team for their collaboration and responsiveness. We encourage macOS users to apply security updates as soon as possible.
This blog post details our investigation into using Office macros to escape the macOS App Sandbox and how we uncovered the CVE-2025-31191 vulnerability. We further demonstrate how the exploit could allow an attacker to delete and replace a keychain entry used to sign security-scoped bookmarks to ultimately escape the App Sandbox without user interaction. This research underscores how security solutions like Microsoft Defender for Endpoint protect devices from cross-platform threats, as well as how collaboration and responsible disclosure are essential to defend users across all platforms and devices.
The macOS App Sandbox is a security mechanism employed on macOS applications, enforcing strict fine-grained rules on what an app can or cannot do. For example, an app can specify whether it should have internet access or whether it should be able to access specific files. To get apps signed by Apple and published in the Mac App Store, developers must have sandbox rules defined for their apps.
Since 2022, Apple has made significant changes to how the App Sandbox is enforced from within Launch Services, making them aware of the XPC client being sandboxed. That means vulnerabilities that use Launch Services, such as the CVE-2022-26706 vulnerability, as well as CVE-2021-30864, CVE-2022-26696, and others, will not work anymore. Since Microsoft Office is heavily sandboxed on macOS, it seems that the impact of malicious Office macros is minimal and cannot be trivially used as an initial access vector.
Nevertheless, our team decided to perform a threat landscape analysis. With modern Microsoft Office for macOS being heavily sandboxed, two new VBA APIs have been introduced and documented:
Since the AppleScriptTask API did not have obvious vulnerabilities, we started focusing on the GrantAccessToMultipleFiles API.
Interestingly, we noticed that the user’s choice is persistently saved and used, even between reboots. This indicates that the user’s consent is stored in a file that we can attempt to access. An attacker could aim to obtain write and read access to arbitrary files without the user’s consent and then escape the macOS App Sandbox by abusing files that would later be used by other apps (such as the file ~/.zshenv that we analyzed in the past). In such an attack, the attacker could rely on unsuspecting users approving file access to allow trivial sandbox escapes.
We discovered that the file that persists the user’s choices is a PLIST file under the Containers folder. The Containers folder is a special folder in which App Sandbox rules do not apply, which means that the sandboxed app has full access to files there. This is quite attractive for vulnerability research purposes since it means that an attacker might be able to add entries to that file and simply get access to arbitrary files mentioned in that PLIST file.
Microsoft Office uses a macOS mechanism called security-scoped bookmarks, which is a mechanism designed by Apple to specifically bypass the App Sandbox rules using explicit, persistent user choices. We do note that the file seems to contain binary signatures, so frivolously adding new entries or modifying existing ones is not possible.
Therefore, our team decided to reverse engineer large parts of the macOS modules that support this behavior. However, to fully understand and appreciate the security design of security-scoped bookmarks, it’s important to understand how sandboxed apps typically get access to files.
In general, sandboxed apps typically get access to files if a user selects them using the Open dialog. That dialog is controlled by an un-sandboxed service called com.apple.appkit.xpc.openAndSavePanelService.xpc. After the user selects the files, that un-sandboxed service transfers access to the selected files to the sandboxed app (using IPC) via a mechanism called sandbox extensions, which was documented well by Jonathan Levin in the past. Essentially, sandbox extensions are tokens created and signed by the kernel that grant the possessing process the ability to access those files, typically using the lower-level API under libsystem_sandbox.dylib. In our case, the Open dialog service passes a sandbox extension token from the kernel to Microsoft Office, which then uses the token for file access purposes, bypassing App Sandbox checks. The token itself contains:
Because the key that is used to sign the HMAC-SHA256 blob is generated in each new boot, the token cannot persist between reboots. To solve that problem, Apple came up with security-scoped bookmarks, which do something very similar. A new un-sandboxed process called ScopedBookmarkAgent was introduced, which can perform two important tasks:
Applications such as Microsoft Office could then use those capabilities to maintain long-term file access:
The HMAC-SHA256 authentication blob generated by ScopedBookmarkAgent cannot be forged unless an attacker has the cryptographic key. The signing key is unique for each app and calculated as such:
cryptoKey=HMAC-256(secret, “[bundle-id]”)
The bundle ID is known (for instance, com.microsoft.Word) and the key persists in Keychain Access on macOS, saved in the keychain entry com.apple.scopedbookmarksagent.xpc.
Therefore, knowing the secret that is stored in the keychain is essential to retrieving the cryptoKey, and that’s the only barrier against an attacker signing their own bookmark entries.
The macOS keychain can be thought of as a built-in password manager, conceptually similar to how Credential Manager works on Windows. The keychain is a container for passwords and has Access Control Lists (ACL) that dictate which process can access each keychain item. The keychain entry we are interested in is com.apple.scopedbookmarksagent.xpc, and its ACL dictates only the ScopedBookmarkAgent has access to it, which is an excellent security decision by Apple, since injection to that process is not trivial, especially from a sandboxed context.
It seems as if an attacker cannot do much as they operate within the sandboxed app context and not the ScopedBookmarkAgent context, so attackers cannot get the key and, therefore, cannot sign arbitrary new entries in the PLIST file indirectly used by the ScopedBookmarkAgent. However, we discovered that the ACL only controls the ability to read the secret. An attacker could completely avoid reading the existing secret and instead can delete the existing entry and add a new entry, with a well-known secret. In addition, the attacker could control the new entry’s ACL and allow anyone to read the contents of the secret, including ScopedBookmarkAgent:
Therefore, an attacker can create an elaborate exploit:
As corroborated by our research, this exploit works against any sandboxed app that uses security-scoped bookmarks and is therefore a generic macOS sandbox escape.
Security technologies such as the macOS App Sandbox are designed to protect the device from malware and other cybersecurity threats, both as a default security measure and a final safeguard. Nonetheless, attackers continue to find new ways of breaking through these defenses for these same reasons, as they can gain full access to the device and run any files or processes they want without being detected by conventional security solutions.
Our research on the CVE-2025-31191 vulnerability highlights why organizations need a security solution like Microsoft Defender Vulnerability Management that enables them to identify and remediate vulnerabilities and misconfigurations on devices in real time and prioritize those in need of immediate attention. Additionally, Microsoft Defender for Endpoint detects and alerts on anomalous device activities using advanced behavioral analytics and machine learning. In this case, Microsoft Defender for Endpoint detects sandboxed apps controlling security keys that normally are not accessed by those apps. Moreover, in the context of our exploit, Defender for Endpoint detects such behavior as suspicious and blocks the activity, rendering the exploit unusable.
Lastly, this research emphasizes the value and necessity of responsible disclosure and collaboration throughout the security community. Vulnerability discoveries, cooperation between security researchers and vendors, and coordinated response across the security community are all paramount to defend against the ever-growing and ever-changing threats across platforms. These activities, along with other forms of threat intelligence sharing, strengthen and enhance our security technologies to help safeguard users across platforms and devices.
Jonathan Bar Or
Microsoft Threat Intelligence
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.
Microsoft Threat Intelligence Center (MSTIC) and Microsoft Security Response Center (MSRC) have discovered post-compromise exploitation of a newly discovered zero-day vulnerability in the Windows Common Log File System (CLFS) against a small number of targets. Microsoft released security updates to address the vulnerability, tracked as CVE 2025-29824, on April 8, 2025.
Using Microsoft Security Copilot to expedite the discovery process, Microsoft has uncovered several vulnerabilities in multiple open-source bootloaders impacting all operating systems relying on Unified Extensible Firmware Interface (UEFI) Secure Boot. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability in the GRUB2, U-boot, and Barebox bootloaders.
Microsoft discovered a macOS vulnerability allowing attackers to bypass System Integrity Protection (SIP) by loading third party kernel extensions, which could lead to serious consequences, such as allowing attackers to install rootkits, create persistent malware, bypass Transparency, Consent, and Control (TCC), and expand the attack surface to perform other unauthorized operations.
Microsoft Threat Intelligence uncovered a macOS vulnerability that could potentially allow an attacker to bypass the operating system’s Transparency, Consent, and Control (TCC) technology and gain unauthorized access to a user’s protected data. The vulnerability, which we refer to as “HM Surf”, involves removing the TCC protection for the Safari browser directory and modifying a […]
