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 and Office macros
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:
- AppleScriptTask. This API allows a Microsoft Office macro to run a preassigned AppleScript. The script must be under the directory ~/Library/Application Scripts/[bundle id]/, which is not accessible for writing from within Office itself. Therefore, script execution cannot be used for VBA-based sandbox escape purposes.
- GrantAccessToMultipleFiles. This API grants read and write access to files out of the sandbox from within the macro, which involves heavy user interaction to select and approve those files.
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.
File access approval using kernel tokens
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:
- HMAC-SHA256 authentication. The key used for that HMAC is generated in each boot by the Sandbox.kext kernel extension.
- Volume, node information, and other file metadata.
- Capability (such as com.apple.app-sandbox.read-write).
- File path.
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:
- Given a sandbox extension token, validate its authenticity and generate a new, serializable object called “bookmark,” which will have a long-term HMAC-SHA256 authentication.
- Given a bookmark, validate its authenticity and generate a new sandbox extension token.
Applications such as Microsoft Office could then use those capabilities to maintain long-term file access:
- On the first call to GrantAccessToMultipleFiles, Office checks if there are file entries in its securebookmarks.plist file. Since there are no matching entries, Office consults the Open dialog service, which requires user interaction and receives a sandbox extension token. That token is sent to the ScopredBookmarkAgent, which validates the token and then signs it with its own unique, long-term cryptographic key. That data is then serialized by Office to the securebookmarks.plist file for later use.
- On the next call to GrantAccessToMultipleFiles, Office finds the entry in its securebookmarks.plist file and sends the data to the ScopedBookmarkAgent, which validates the signature and generates a sandbox extension token that Office can use without user interaction involved.
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.
Escaping the App Sandbox via the keychain
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:
- Delete the old signing secret from the keychain and decide on a new known secret that is accessible to all processes.
- Calculate the cryptographic key for an app since its bundle ID is known (key = HMAC-SHA256(knownSecret, [bundle-id])).
- Artificially sign new entries in the persistent scoped bookmarks PLIST file that is accessible since it persists in the Containers directory.
- Invoke GrantAccessToMultipleFiles, which sends the newly self-signed bookmarks to ScopedBookmarkAgent. Since ScopedBookmarkAgent uses the new secret, the bookmarks are considered authentic, and therefore ScopedBookmarkAgent grants the sandboxed app the access token without user interaction.
- Use the new arbitrary file access capability to escape the macOS sandbox.
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.
Strengthening device security through vulnerability management and threat intelligence sharing
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
References
Learn more
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.