The patch touches Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp, the implementation behind the Entries API (webkitEntries / FileSystemEntry) that a page can obtain from a DataTransfer during drag-and-drop or a file input. Each DOMFileSystem is created with an m_rootPath that scopes all path resolution to files the user actually granted. In DOMFileSystem::listDirectory and DOMFileSystem::getParent, the code resolved a virtual path and then dispatched work to a background queue to enumerate directory children (listDirectoryWithMetadata) or validate/stat the parent directory on the real filesystem. The violated invariant is that these filesystem operations must only run when the object has a valid, non-empty root path scoping it to authorized content; when m_rootPath is empty (for example an entry synthesized from a dropped File whose real path was never actually admitted), path evaluation can still resolve to something outside the intended sandbox, letting the background job touch and report metadata about the local filesystem.

The fix adds an explicit guard at the top of both functions: if m_rootPath.isEmpty(), immediately invoke the completion handler/callback with a NotFoundError (‘Path does not exist’) and return, before any work is dispatched to the work queue. This ensures that an un-rooted DOMFileSystem cannot be used to enumerate a directory’s children or walk to a parent directory. The updated LayoutTest confirms the intent: it now also adds a directory File to the DataTransfer and, for each entry, calls entry.file(), entry.getParent(), and (for directories) createReader().readEntries(), all of which must fail with ‘Should not receive file’ errors. Notably file() was already guarded (the pre-existing single PASS), but getParent() and readEntries() were the newly-closed holes, which is exactly what the two new guards in listDirectory and getParent cover.

The result is that previously an attacker could distinguish existence/metadata of local paths (a fingerprinting/info-leak oracle) via these two entry points; the fix removes the oracle by refusing the operation outright when there is no legitimate root.

The primitive is an information-disclosure/fingerprinting oracle, not memory corruption: a page could learn about the existence and metadata of local filesystem paths through getParent and readEntries on an un-rooted DOMFileSystem, consistent with the CVE’s ‘fingerprint the user’ description and medium severity. There is no write or control-flow primitive here and no path to code execution from this bug alone. It is confined to the WebContent process’s WebCore layer, but the leaked signal is about the host filesystem, so the privacy impact crosses the sandbox conceptually even though execution stays in-process. Escalation would be limited to enriching a broader fingerprint or informing a separate exploit, not to direct compromise.