
Over two years after the report, Apple quietly patched a mac extended attributes vulnerability that leaked sensitive authentication tokens via file metadata – without providing transparency to the security research community. The issue centered on the kMDItemWhereFroms extended attribute, a macOS feature that stores download URLs in mac extended attributes, including sensitive query parameters and authentication tokens.
This vulnerability was reported on 05/11/2023. The impact of the vulnerability is not high, and risk of exploitation low, but the functionality of the Apple bug bounty program is questionable.
Mac Extended Attributes URL Metadata Leak
When macOS users download files through web browsers, the system automatically stores the complete download URL as an extended attribute called kMDItemWhereFroms.

This metadata appears in Finder’s “Get Info” panel under “Where from” and persists indefinitely -surviving reboots. However, the impact is relatively low because this information is lost after transferring the file to another machine. Still, macOS stores the entire URL, including path and query parameters. Many web services embed authentication tokens, session identifiers, and API keys directly in URLs for “temporary” access control.

These tokens were being silently written to the filesystem, readable by any process with file access.
Proof of Concept: Mac Extended Attributes Token Exposure
The link below was created in 2023. It was meant for “temporary” access. Yet, such API tokens often persist for an extended period. The one below still works. In any web browser, download the file:
https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLHccaucjYmWcCK0uMLEQ%2Fuploads%2FfyUSfiWjJrlMGC88QXw3%2FSPECIAL_CHARS.xlsx?alt=media&token=81ff0b0c-5d40-4db5-9b70-aa8cf465880e
Examining a test file downloaded from GitBook demonstrates the exposure. Running mdls SPECIAL_CHARS.xlsx reveals:
textkMDItemWhereFroms = ( "https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLHccaucjYmWcCK0uMLEQ%2Fuploads%2FfyUSfiWjJrlMGC88QXw3%2FSPECIAL_CHARS.xlsx?alt=media&token=81ff0b0c-5d40-4db5-9b70-aa8cf465880e")
The API token was permanently stored in the file metadata.
Why URL Tokens Are Dangerous in Metadata
A local attacker may use exposed API tokens for lateral movement to third-party services, a technique commonly tested during red team engagements. Security professionals have long warned against transmitting sensitive data in URLs. Even with HTTPS encryption protecting transmission, URL parameters leak through multiple channels:
- Server access logs capture complete request URLs, including query strings
- Browser history stores full URLs with embedded credentials
- Referer headers expose URLs to third-party resources like analytics platforms
- Shared systems allow anyone with access to view the URL history
The macOS metadata extended this exposure. While a server log might be rotated or a browser history cleared, file extended attributes persist until explicitly removed. OAuth 2.0 specifications and modern authentication frameworks explicitly prohibit passing tokens in URLs for these reasons. Despite widespread adoption of header-based authentication (like the Authorization: Bearer pattern), many legacy systems and cloud storage services still use URL-embedded tokens for backwards compatibility.
To conclude, API tokens should not be used directly in the URL in the first place. However, operating systems should also provide a defense in depth if the web service does not follow best practices.
Final Words on the Mac Extended Attributes Vulnerability
The vulnerability was reported to Apple Product Security on November 5, 2023. After around a month, it was marked to be patched in Fall 2024. A year later, it was marked to be patched in Fall 2025, and finally, in September 2025, it was marked as “We’re unable to identify a security issue in your report.”:

However, it appears to be fixed in macOS Tahoe 26.0.1. It is a bit confusing since the report was closed, but with information that Apple is still reviewing for potential enhancements.

It is unknown if this is due to some communication problems between the bug bounty triage team and the engineering team at Apple, but it looks like violating responsible disclosure norms two years after the initial report and this is not the quality we expect from Apple.




