Mac Extended Attributes Expose Authentication Tokens in macOS

Artur - AFINE cybersecurity team member profile photo
Karol Mazurek
Nov 21, 2025
3
min read
mac extended attributes

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.

mac 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.

mac extended attributes kMDItemWhereFroms exposing authentication token in macOS Finder Get Info panel

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")
mdls command showing mac extended attributes with kMDItemWhereFroms exposing authentication token in macOS terminal

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.”:

Apple Product Security response

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.

macOS Tahoe 26.0.1 terminal showing mac extended attributes patched with kMDItemWhereFroms returning null values

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.

Monthly Security Report

Subscribe to our Enterprise Security Report. Every month, we share what we're discovering in enterprise software, what vulnerabilities you should watch for, and the security trends we're seeing from our offensive security work.

By clicking Subscribe you're confirming that you agree with our Terms and Conditions.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Gradient glow background for call-to-action section