Apple Maildrop URLs Expose Unsigned, Client-Controlled Filename, Size, and Icon Parameters

1. Summary

Apple’s Maildrop attachment service hosts mail attachments up to 5 GiB and presents recipients with a download page on icloud.com. The per-attachment URLs it generates contain three client-controlled, unsigned parameters:

Any party in possession of a valid Maildrop URL can rewrite f= and sz= and obtain a fully functional Maildrop URL that: displays the fake filename and file-type icon on the landing page; displays the fake file size; and causes the CDN to serve the file with Content-Disposition: attachment; filename="<fake name>", so the browser saves it under the fake name regardless of the file’s actual MIME type or extension. The URL remains on icloud.com throughout. There is no visual indicator that displayed metadata is sender-controlled rather than server-attested.

2. Technical Detail

2.1 URL Structure

A canonical Maildrop URL has the shape:

https://www.icloud.com/attachment/?u=<percent-encoded inner CDN URL>
                                  &uk=<user key>
                                  &f=<filename>
                                  &sz=<file size in bytes>

The inner u= value, once decoded, is the CDN URL the browser fetches when the user clicks “Download”. Its shape is approximately:

https://cvws.icloud-content.com/B/<content hash>/${f}?o=...&k=${uk}&...

2.2 The CDN Template Substitution

The two ${...} tokens in the CDN URL are template substitutions. The ${f} token is replaced with whatever value is in the outer f= parameter at request time. The ${uk} token is replaced with uk=.

This means f= is not a cosmetic landing-page label. It is also part of the path the CDN serves, and the CDN echoes it back via the Content-Disposition response header. Modifying f= changes what the recipient’s browser names the downloaded file.

2.3 Signed vs. Unsigned Components

The structural deficiency is the absence of an HMAC over the outer query string. A short keyed signature parameter would prevent the attack class entirely.

2.4 Python PoC — maildrop_spoof.py

A short Python script captures the entire primitive. Given any valid Maildrop URL, the script parses the four parameters, prints the detected template variables, and produces a spoofed URL with operator-chosen filename and size:

# maildrop_spoof.py — public PoC
import sys
from urllib.parse import urlparse, parse_qs, urlencode, urlunparse, unquote

def analyse(url):
    p = urlparse(url)
    q = parse_qs(p.query, keep_blank_values=True)
    inner = unquote(q.get('u', [''])[0])
    print('[Analysis]')
    print(f'  f=  : {q.get("f", ["(missing)"])[0]}')
    print(f'  sz= : {q.get("sz",["(missing)"])[0]}')
    print(f'  uk= : {q.get("uk",["(missing)"])[0]}')
    print(f'  CDN URL embeds ${{f}}  : {"${f}" in inner}')
    print(f'  CDN URL embeds ${{uk}} : {"${uk}" in inner}')

def spoof(url, name, size):
    p = urlparse(url)
    q = parse_qs(p.query, keep_blank_values=True)
    q['f']  = [name]
    q['sz'] = [str(size)]
    return urlunparse(p._replace(
        query=urlencode({k: v[0] for k, v in q.items()})))

if __name__ == '__main__':
    if len(sys.argv) < 2:
        print('usage: maildrop_spoof.py <maildrop-url> [fake-name] [fake-size]')
        sys.exit(1)
    url  = sys.argv[1]
    name = sys.argv[2] if len(sys.argv) > 2 else 'Invoice_Q1_2026.pdf'
    size = int(sys.argv[3]) if len(sys.argv) > 3 else 204800
    analyse(url)
    print()
    print('[Spoofed URL]')
    print(spoof(url, name, size))

Run against a real Maildrop URL, the script reports which template tokens the CDN URL embeds and produces a rewritten link. Opening the original and spoofed links side-by-side in a browser shows: original landing page with real filename, real size, real icon; spoofed landing page with attacker-chosen filename, size, and icon — all inferred from the operator-chosen f= value. Both URLs reside on icloud.com; both produce a working download. The Content-Disposition header on the downloaded file bears the spoofed filename.

3. Attack Model

The attack requires nothing beyond a text editor and a browser. Three realistic operator positions:

[Operator-as-sender]

The attacker uploads a payload (malware archive, malicious document, fake invoice) via Apple Mail and obtains a Maildrop URL. They rewrite f= to a trustworthy filename — Invoice_Q1_2026.pdf, MarketingSlideDeck.pptx, CV_J_Smith.docx — and sz= to a size matching the social pretext.

The victim receives a link on icloud.com, sees an Apple-rendered landing page presenting a PDF named “Invoice_Q1_2026.pdf” weighing 204 KB, and clicks “Download”. The browser save-as prompt shows “Invoice_Q1_2026.pdf”. The actual file content is whatever the attacker uploaded. This is the dominant case. It is trivial.

[Operator-as-forwarder]

A legitimate Maildrop URL is forwarded to a wider audience — common in corporate environments where shared files traverse multiple mailing lists. An attacker on that audience-list path can modify f= and sz= before re-sharing, producing a spoofed link pointing to content they did not upload.

[Operator-as-link-collector]

Maildrop URLs leak by ordinary means — chat logs, screenshots, copy/paste into ticketing systems, accidental wider cc’ing. Any exposed URL is rewritable for the remainder of its 30-day window. No upload step required; the attacker only needs to have observed the URL.

4. Impact

There is no published CVSS scoring framework that captures phishing-aid bugs cleanly. A score of 5.4 Medium understates the social-engineering value because the standard does not weight Apple-branded presentation. In an enterprise threat model the bug ranks materially higher than the base score implies.

5. What End-Users Can Do Today

Because the bug is server-side, there is no patch end-users can apply. Practical defensive guidance for individuals and security teams:

1. Treat the displayed filename, icon, and size on a Maildrop landing page as advisory, not authoritative. They reflect what the sender chose to put in the URL, not what Apple has verified about the file.
2. Where the underlying file matters, ask the sender for a second-channel checksum (SHA-256) and verify after download. This is the only reliable defence available today.
3. In enterprise environments, consider blocking https://www.icloud.com/attachment/ and cvws.icloud-content.com at the proxy unless the workflow specifically requires Maildrop. Most organisations do not.
4. Email security gateways that classify URLs by domain reputation should not extend Apple’s reputation to content served via Maildrop URLs. The two are not coextensive.

No mitigation removes the attack surface; only a server-side fix at Apple does.

6. Recommended Fix

Three options, in increasing order of architectural cleanliness:

Option 1 — HMAC the outer query string. Append a sig= parameter computed by Apple’s Maildrop service over the canonical concatenation of u, uk, f, sz. Reject requests where the signature does not match. Implementation: one HMAC computation per URL generation, one per download request. Backward compatibility: accept unsigned URLs for the remainder of their 30-day life; sign all newly-generated URLs.

Option 3 — Remove the ${f} and ${uk} template substitution from the CDN URL entirely. The CDN path can be made canonical and content-hash-addressed, with filename presentation handled by the landing page from server-side metadata.

7. On Responsible Disclosure

This document is published after 34 months of vendor exclusivity. The author considers this appropriate because:

1. The vendor has had ample time. No reasonable interpretation of coordinated-disclosure norms gives a vendor approaching three years to deploy a server-side parameter signing change. Industry-standard windows (Google Project Zero, ZDI, CERT/CC) range from 90 to 120 days. Apple has had approximately ten such windows.
2. The bug is rediscoverable by inspection. Any researcher who examines a Maildrop URL and notices the unsigned parameters can reproduce the entire finding in minutes. There is no reverse-engineering barrier, no compiled-binary friction. The author considers it highly likely that independent rediscovery has already occurred.
3. End-users are currently defenceless against this attack class. They have no way to know that Maildrop’s landing-page presentation is sender-controlled. Disclosure enables informed defence at the user, enterprise, and email-gateway level.
4. The remediation is purely server-side. No client-side action, no patch propagation, no compatibility chain — Apple can deploy the fix at any time, and the bug is closed everywhere the moment they do.
5. The author has provided the vendor with a working PoC, a video demonstration, and a written write-up specifying the fix. Three separate forms of evidence. Apple has had every artefact required to act.

This disclosure does not include credentials, account-specific URLs, or any non-public Apple infrastructure detail. The technical content is reproducible from any Maildrop URL the reader generates themselves.

8. Reproducibility

This document is licensed CC BY 4.0; reuse, citation, and redistribution are permitted with attribution. The PoC requires Python 3 and a Maildrop URL generated by sending a small file to oneself via Apple Mail. No credentials, no API keys, no proprietary tooling. The maildrop_spoof.py script is reproduced in full in §2.4 above and is also available separately on request.

Vendor case OE1950888220 was originally filed on 2023-07-07; refreshed PoC and analysis filed 2026-04-04; vendor status as of 2026-05-13 is “Prioritised for review”.