With attachment elements enabled, WebPasteboardProxy (UI process) returns file paths (pathsForFileUpload) obtained from the pasteboard to the WebContent process, but it did not record which paths it had legitimately vended — ‘Missing validation for incoming file paths from web content process when attachment elements are enabled’. Without an allow-list, a malicious or compromised WebContent process could later reference arbitrary file paths (including path-traversal outside the intended files) in attachment/file operations, and the trusted UI/Network process would act on them, disclosing sensitive local files.

The fix adds addAllowedAttachmentFilePaths() and invokes it on every path that vends pasteboard file paths — getPasteboardPathnamesForType, allPasteboardItemInfo (including the iOS HEIC-transcoding continuation, which now captures the IPC::Connection by Ref so the async main-thread hop can still register paths), and informationForItemAtIndex — registering each vended path through WebProcessProxy::addAllowedAttachmentFilePath.

The restored invariant is that the WebContent process may only reference attachment file paths the UI process actually provided, so incoming paths can be validated against this per-process allow-list. INFERENCE: the enforcement check that rejects non-allow-listed incoming paths (the consumer of addAllowedAttachmentFilePath) is outside this hunk; the diff establishes population of the allow-list.

This is a local-file information-disclosure / path-traversal issue across the WebContent->UI process boundary, not a memory-safety bug. It requires attachment elements to be enabled and a WebContent process willing to send crafted IPC (a malicious or already-compromised web process), so it is a defense-in-depth boundary hardening rather than a direct remote primitive; its payoff is reading files outside the intended attachment set.