Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see go/chrome-ai-generated-security-bugs-faq for more information.

Overview: A potential logic vulnerability in the AR Quick Look download flow on iOS allows a malicious cross-origin iframe to trigger a promptless download. This download can overwrite a user’s legitimate in-flight download in the shared temporary directory due to unconditional file deletion and predictable paths. As a result, the user may experience silent data loss and be presented with a spoofed file.

Affected files:

• ios/chrome/browser/download/model/ar_quick_look_tab_helper.mm
• ios/chrome/browser/download/model/browser_download_service.mm
• ios/web/download/download_task_impl.mm
• ios/web/navigation/crw_wk_navigation_handler.mm
• ios/chrome/browser/download/model/download_directory_util.mm

Estimated timestamp from git blame: 2026-02-19

Technical Details

The AR Quick Look feature in Chrome for iOS handles files with specific MIME types (e.g., model/vnd.usdz+zip). A potential logic flaw in how these downloads are initiated allows an attacker to spoof in-progress downloads and cause data loss.

1. Promptless Initiation: In ios/web/navigation/crw_wk_navigation_handler.mm, the kPreventNavigationWithoutUserInteraction policy decision bypasses user-gesture requirements for non-main-frame navigations. This allows an <iframe> to trigger a navigation without user interaction. When the response MIME type is a USDZ format, Chrome refuses to render it and converts it into a WKDownload.
2. Automatic Start: BrowserDownloadService::OnDownloadCreated routes USDZ tasks to ARQuickLookTabHelper::Download(), which immediately calls task->Start() without waiting for user confirmation.
3. Shared Temporary Path: Both AR Quick Look and standard downloads use a shared temporary directory (<tmp>/downloads), defined in ios/chrome/browser/download/model/download_directory_util.mm.
4. Unconditional File Deletion: When a download task starts, DownloadTaskImpl::Start() calls CreateFileForDownload(), which executes base::DeleteFile() on the target path to clear any existing file.
5. File Unlinking Race Condition: Because the target filename is derived from the server-supplied Content-Disposition header, an attacker can target the predictable temporary path of a legitimate in-progress download. base::DeleteFile() will unlink the legitimate file. Under iOS/Unix file semantics, the WKDownload writing the legitimate file continues to write to the unlinked inode without failing.
6. Spoofing: CreateFileForDownload() creates a new file at the exact same path for the attacker’s payload. Once the legitimate download completes, DownloadManagerTabHelper retrieves the file from the temporary path and moves it to the user’s NSDocumentDirectory. It inadvertently moves the attacker’s newly placed file, resulting in download spoofing and the loss of the legitimate file.

Potential Attack Scenario

Note: These are suggested steps; our tooling agent does not have the ability to run code, so this remains a potential exploit chain based on code analysis.

1. A user navigates to a legitimate site and initiates a standard download (e.g., statement.pdf). Chrome begins downloading the file to <tmp>/downloads/statement.pdf.
2. A hidden cross-origin iframe (either embedded on the site or open in another tab) triggers a navigation to an attacker-controlled endpoint.
3. The attacker’s server responds with Content-Type: model/vnd.usdz+zip and Content-Disposition: attachment; filename="statement.pdf".
4. Chrome promptlessly starts an AR Quick Look download. It unlinks the existing <tmp>/downloads/statement.pdf file and creates a new one, writing the attacker’s USDZ payload into it.
5. The legitimate download finishes. Chrome’s DownloadManagerTabHelper moves the file located at <tmp>/downloads/statement.pdf (now containing the attacker’s payload) into the user’s Documents directory.
6. The user attempts to open statement.pdf and opens the attacker’s payload instead, while their actual document is lost.

Suggested Fix

1. Unique Temporary Paths: Download tasks should use unique temporary directories (e.g., using a UUID per task) or append a unique identifier to the filename while downloading, rather than sharing a single <tmp>/downloads/ folder where collisions can occur.
2. Enforce User Interaction: AR Quick Look downloads initiated from subframes should be subject to strict user-gesture requirements before starting automatically.
3. Collision Checks: Do not unconditionally delete existing files in the temporary directory if another active task in the browser is currently writing to that exact path.

Evaluated with Chrome root at commit: 661452647ddb2827305122ff3273bd5dea403f09

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.