Reading view

There are new articles available, click to refresh the page.

Apple’s .01 updates are out

Yesterday Apple released several updates for its operating systems. iOS 26.0.1 and iPadOS 26.0.1 iOS 18.7.1 and iPad OS 18.7.1 macOS Tahoe 26.0.1 macOS Sequoia 15.7.1 macOS Sonoma 14.8.1 visionOS 26.0.1 watchOS 26.0.2 tvOS 26.0.1 Most include security updates.  Some have complained about battery drain on iOS 26 but I’ve found that right after a […]

Apple addresses dozens of vulnerabilities in latest software for iPhones, iPads and Macs

Apple’s latest operating systems for its most popular devices — iPhones, iPads and Macs — include patches for multiple vulnerabilities, but the company didn’t issue any warnings about active exploitation. 

Apple patched 27 defects with the release of iOS 26 and iPadOS 26 and 77 vulnerabilities with the release of macOS 26, including some bugs that affected software across all three devices. Apple’s new operating systems, which are now numbered for the year of their release, were published Monday as the company prepares to ship new iPhones later this week.

Users that don’t want to upgrade to the latest versions, which adopt a translucent design style Apple dubs “liquid glass,” can patch the most serious vulnerabilities by updating to iOS 18.7 and iPad 18.7 or macOS 15.7. Most Apple devices released in 2019 or earlier are not supported by the latest operating systems.

None of the vulnerabilities Apple disclosed this week appear to be under active attack, Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CyberScoop.

Apple previously issued an emergency software update to customers last month to patch a zero-day vulnerability — CVE-2025-43300 — that was “exploited in an extremely sophisticated attack against specific targeted individuals,” the company said in a series of updates for iOS, iPadOS and macOS.

The company has addressed five actively exploited zero-days this year, including defects previously disclosed in January, February, March and April. Seven Apple vulnerabilities have been added to the Cybersecurity and Infrastructure Security Agency’s known exploited vulnerabilities catalog this year. 

Unlike many vendors, Apple doesn’t provide details about the severity of vulnerabilities it addresses in software updates. Childs noted it would be helpful if Apple issued some sort of initial severity indicator alongside the vulnerabilities it patches — even if it doesn’t follow the Common Vulnerability Scoring System.

A pair of vulnerabilities patched in macOS — CVE-2025-43298, which affects PackageKit, and CVE-2025-43304, which affects StorageKit — are concerning because exploitation could allow an attacker to gain root privileges, Childs said. 

“On the iOS side, I don’t see anything that makes me sweat immediately but there are a lot of bugs addressed,” he added.

Apple also patched seven defects in Safari 26, 19 vulnerabilities in watchOS 26, 18 bugs in visionOS 26 and five defects in Xcode 26

More information about the vulnerabilities and latest software versions are available on Apple’s security releases site.

The post Apple addresses dozens of vulnerabilities in latest software for iPhones, iPads and Macs appeared first on CyberScoop.

Apple’s new Memory Integrity Enforcement system deals a huge blow to spyware developers

Apple has unveiled a comprehensive security system called Memory Integrity Enforcement (MIE) that represents a five-year engineering effort to combat sophisticated cyberattacks targeting individual users through memory corruption vulnerabilities.

The technology is built into Apple’s new iPhone 17 and iPhone Air devices, as well as the A19 and A19 Pro chips. It combines custom-designed hardware with changes to the operating system to deliver what Apple describes as “industry-first, always-on” memory safety protection. According to Apple’s security researchers, the system is primarily designed to defend against sophisticated attacks from so-called “mercenary spyware,” rather than from typical consumer malware.

“Based on our evaluations pitting Memory Integrity Enforcement against exceptionally sophisticated mercenary spyware attacks from the last three years, we believe MIE will make exploit chains significantly more expensive and difficult to develop and maintain, disrupt many of the most effective exploitation techniques from the last 25 years, and completely redefine the landscape of memory safety for Apple products,” the company wrote in a blog posted Tuesday. “Because of how dramatically it reduces an attacker’s ability to exploit memory corruption vulnerabilities on our devices, we believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems.”

Memory corruption vulnerabilities have long accounted for some of the most pervasive threats to operating system security. These flaws happen when software doesn’t properly control how it reads from or writes to memory, allowing attackers to change, overwrite, or access parts of a computer’s memory they shouldn’t be able to.

Exploits targeting these flaws — in particular buffer overflows and use-after-free errors — have underpinned the sophisticated, multi-million-dollar exploit chain that powers spyware. Attackers exploit these flaws, often in “zero-click” (no user interaction required) scenarios, to run harmful code, steal data, or crash systems. For example, NSO Group’s Pegasus spyware was powered by three memory corruption vulnerabilities that were chained together. 

Recognizing this, Apple expanded efforts over the past five years to address memory safety “at scale.” The company worked closely with the chip designer Arm to improve a memory protection system where memory checks happen immediately, every single time memory is used, instead of sometimes waiting, which could leave a small window open for attackers. This led to the creation of Enhanced Memory Tagging Extension (EMTE), a key part of Apple’s new system.

EMTE works by giving each piece of memory a special secret tag. Whenever the device tries to use a particular section of memory, the hardware checks the tag to make sure it is correct. If the tag doesn’t match what is expected, the device will immediately stop the program and record the incident. By ensuring every block of memory has its own unique tag, and by changing these tags whenever memory is reused, Apple’s system blocks unauthorized access efforts before they can cause damage.

“Apple has a deep understanding of this problem space, and because they control both the hardware (Apple Silicon) and the software (iOS), they have the unique ability to engineer a tightly integrated and very effective security mechanism,” said Patrick Wardle, co-founder and CEO of DoubleYou, a company that specializes in Apple security. “This kind of approach, which depends on tight coupling between the chip and the operating system, is something most other vendors cannot replicate as easily since they do not own both sides of the stack.”

The company acknowledges in a blog post that the system does not entirely eliminate spyware’s ability to be executed on an Apple device, but makes it extremely difficult for attacks to successfully run spyware or maintain access if a device has been compromised. 

“While there’s no such thing as perfect security, MIE is designed to dramatically constrain attackers and their degrees of freedom during exploitation,” the blog post reads. 

The efforts mirror similar systems put in place by Microsoft, which has a memory integrity feature in Windows 11, and Google, which has a similar system in its Pixel devices.

Natalia Krapiva, senior tech-legal counsel at Access Now, told CyberScoop she thought it was “great” that Apple was taking effective measures since it’s “always a cat-and-mouse” game when large tech companies create ways to thwart spyware developers.

“These spyware developers like finding new ways of targeting people, evading detection and so on,” Krapiva told CyberScoop. “This is great to see Apple coming up with new ways to protect high-risk users.

The one drawback Krapiva did highlight is that this system is only available on new devices. AccessNow works internationally with groups that are often targeted by spyware on devices that are several generations older than what most consumers use. 

“For our communities, oftentimes these are grassroots, independent media. It’s very hard to afford new devices, especially Apple devices,” she told CyberScoop. “It could be a nice thing for Apple to have some kind of a program to allow for these types of groups to be able to access this.”

MIE can also be taken advantage of by third-party applications, including social media and messaging applications. Additionally, EMTE is available to all Apple developers in Xcode, its developer toolkit, as part of the Enhanced Security feature it rolled out earlier this year. 

The post Apple’s new Memory Integrity Enforcement system deals a huge blow to spyware developers appeared first on CyberScoop.

Apple discloses actively exploited zero-day affecting iOS, iPadOS and macOS

Apple rushed an emergency software update to its customers Wednesday to address an actively exploited zero-day vulnerability affecting the software powering the company’s most popular devices. The out-of-bounds write defect — CVE-2025-43300 — allows attackers to process a malicious image file resulting in memory corruption. 

“Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals,” the company said in a series of security updates for iOS, iPadOS and macOS.

The Cybersecurity and Infrastructure Security Agency added the defect to its known exploited vulnerabilities catalog Thursday.

Apple did not say how many active exploits it’s aware of or how many people are impacted. The company did not respond to a request for comment. 

Apple typically shares limited details about in-the-wild exploitation of zero-days, yet it has used stronger language in at least five vulnerability disclosures this year to indicate when sophisticated attackers are involved or specific people are targeted by these attacks, according to Satnam Narang, senior staff research engineer at Tenable.

“This language suggests that Apple is being purposeful in its external communication,” Narang said in an email. “While the impact to the wider populace is smaller because the attackers exploiting CVE-2025-43300 had a narrow, targeted focus, Apple wants the public to pay attention to the threat and take immediate action.”

Apple said it improved bounds checking to address the vulnerability and advised customers on impacted versions of the affected software to apply the update immediately. The defect affects macOS versions before 13.7 and 15.6, iPadOS versions before 17.7 and iOS and iPadOS versions before 18.6.

“While the possibility of the average user being a target is low,” Narang said, “it’s never zero.”

The vulnerability marks the fifth zero-day Apple has addressed this year, including defects previously disclosed and patched in January, February, March and April. Apple defects have made seven appearances on CISA’s known exploited vulnerabilities this year.

More information about the vulnerability is available on Apple’s website.

The post Apple discloses actively exploited zero-day affecting iOS, iPadOS and macOS appeared first on CyberScoop.

OS news from WWDC 2025

APPLE By Will Fastie Apple’s entire keynote for this year’s Worldwide Developers Conference focused on extensive changes to all its operating systems. There were no hardware or device announcements, but changes to macOS have profound ramifications for Intel-based Apple devices from previous generations. Some Apple users will be unhappy. Read the full story in our […]

Analyzing CVE-2025-31191: A macOS security-scoped bookmarks-based sandbox escape

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.

Screenshot of the proof of concept code for an attack involving user interaction
Figure 1. Proof of concept code for an attack that does involve user interaction
Screenshot of the typical user interaction requiring explicit selection of the folder to grant access to
Figure 2. Typical user interaction requiring explicit selection of the folder to grant access to

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.

Screenshot of the secure bookmarks PLIST file saving the signed user choices with typical metadata
Figure 3. The secure bookmarks PLIST file saving the signed user choices with typical metadata

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.

Screenshot of the Access Control List for the scoped bookmarks secret used for signing purposes
Figure 4. The Access Control List for the scoped bookmarks secret used for signing purposes

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:

Screenshot of the deletion of the old security-scoped bookmarks secret and assigning a new one from within a sandboxed session
Figure 5. Deletion of the old security-scoped bookmarks secret and assigning a new one from within a sandboxed session

Therefore, an attacker can create an elaborate exploit:

  1. Delete the old signing secret from the keychain and decide on a new known secret that is accessible to all processes.
  2. Calculate the cryptographic key for an app since its bundle ID is known (key = HMAC-SHA256(knownSecret, [bundle-id])).
  3. Artificially sign new entries in the persistent scoped bookmarks PLIST file that is accessible since it persists in the Containers directory.
  4. 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.
  5. 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.

Screenshot of Microsoft Defender for Endpoint detection the exploit with the alert Suspicious Keychain item manipulation
Figure 6. Detection of the exploit

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.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution across all platforms.

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.

The post Analyzing CVE-2025-31191: A macOS security-scoped bookmarks-based sandbox escape appeared first on Microsoft Security Blog.

Analyzing CVE-2025-31191: A macOS security-scoped bookmarks-based sandbox escape

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.

Screenshot of the proof of concept code for an attack involving user interaction
Figure 1. Proof of concept code for an attack that does involve user interaction
Screenshot of the typical user interaction requiring explicit selection of the folder to grant access to
Figure 2. Typical user interaction requiring explicit selection of the folder to grant access to

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.

Screenshot of the secure bookmarks PLIST file saving the signed user choices with typical metadata
Figure 3. The secure bookmarks PLIST file saving the signed user choices with typical metadata

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.

Screenshot of the Access Control List for the scoped bookmarks secret used for signing purposes
Figure 4. The Access Control List for the scoped bookmarks secret used for signing purposes

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:

Screenshot of the deletion of the old security-scoped bookmarks secret and assigning a new one from within a sandboxed session
Figure 5. Deletion of the old security-scoped bookmarks secret and assigning a new one from within a sandboxed session

Therefore, an attacker can create an elaborate exploit:

  1. Delete the old signing secret from the keychain and decide on a new known secret that is accessible to all processes.
  2. Calculate the cryptographic key for an app since its bundle ID is known (key = HMAC-SHA256(knownSecret, [bundle-id])).
  3. Artificially sign new entries in the persistent scoped bookmarks PLIST file that is accessible since it persists in the Containers directory.
  4. 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.
  5. 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.

Screenshot of Microsoft Defender for Endpoint detection the exploit with the alert Suspicious Keychain item manipulation
Figure 6. Detection of the exploit

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.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution across all platforms.

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.

The post Analyzing CVE-2025-31191: A macOS security-scoped bookmarks-based sandbox escape appeared first on Microsoft Security Blog.

❌