A Windows permission check shipped in April 2025 can stop one of the sharpest attacks in a new cross-platform security paper. It still leaves that check disabled by default. In the researchers' test, a second unprivileged Windows account used ordinary file-change notifications to identify Firefox visits among 1,000 popular sites with a 97.8% F1 score. The attacker never opened the browser's private files. Microsoft's support note calls the underlying behavior a vulnerability, but says the fix may disrupt applications.
That awkward default sits inside a wider finding. Researchers at Graz University of Technology found that the file watchers built into Linux, Android, Windows, and macOS can expose what another user or application is doing. Their 15-page paper, accepted for ACM CCS 2026, turns routine events such as open, modify, move, and delete into signals for typing, website visits, authentication prompts, and message attachments.
This is a local attack, not a website reaching through the browser to inspect a machine. The paper assumes that an attacker can run unprivileged code under another account, or that a service or software dependency has been compromised. Shared workstations, multi-user servers, and background services fit that model more readily than a locked-down personal laptop. The boundary matters because the attack asks for neither administrator access nor the contents of the target file.
A watcher sees more than a reader
File notification APIs solve a basic engineering problem. An editor needs to know when a document changes, a sync client needs to notice a new file, and a development server needs to rebuild after a source edit. Polling the whole directory wastes time and power, so operating systems send events instead. Linux exposes inotify, Windows has ReadDirectoryChangesW, Android wraps Linux's mechanism in FileObserver, and macOS provides FSEvents. The research project page traces those interfaces back as far as Windows 2000 and Linux kernel 2.6.13.
The permission mismatch appears when the event stream says more than the caller could learn by reading the file. On Linux, watching a readable parent directory could report activity on an unreadable child. On Windows, the team found that a watcher placed on C:\ could receive paths for changes across the drive, including another user's profile. Android's app-specific media directories looked empty to an unprivileged app, yet FileObserver still reported events and filenames inside them. macOS leaked less because the researchers found no comparable route into private directories.
Knowing that a file changed can sound harmless. Timing and filenames make it less so. The team's templating process recorded which filesystem events accompanied a known action, then matched later event traces against those labeled patterns. The watchers added at most 0.21% CPU use in the experiments and delivered enough timing resolution to separate actions without opening the files, according to the paper's measurements.
Firefox paths turn into a browsing signal
Firefox creates per-site directories for storage mechanisms such as local storage, IndexedDB, and cache. Those paths contain the site's origin. A watcher running as another Windows user could therefore observe a path containing a domain when Firefox touched that site's storage. Of the 1,000 sites in the test set, 975 responded. Firefox created identifiable directories for 95.7% of them, producing a 97.8% F1 score with no false positives. Edge exposed fewer sites because its observed directory pattern depended on IndexedDB, leaving its F1 score at 48.5%, the researchers report.
F1 combines precision and recall, so 97.8% does not mean the watcher recovered every page in a person's full history. The experiment recognized visits within a defined set, and sites that did not create the expected storage path could be missed. It is still an unusually direct signal: on Firefox, the path itself names the site. There is no need to infer a page from noisy CPU load or network packet sizes.
Microsoft's mitigation adds a FILE_LIST_DIRECTORY permission check on the parent of each changed item before Windows reports it. The company says the check is present in updates released on or after April 8, 2025 for NTFS and ReFS volumes, covering two earlier issues tracked as CVE-2025-21197 and CVE-2025-27738. Its published PowerShell method requires an administrator:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Policies" `
-Name "EnforceDirectoryChangeNotificationPermissionCheck" -Value 1 -Type DWord
The default value remains 0. Microsoft cites possible application disruption and unspecified security risks from changing established notification behavior. That is a compatibility decision administrators now have to weigh against a concrete privacy leak, especially on machines where mutually untrusted users or services share one Windows installation.
Linux patched the loudest leak
Linux exposed a different timing signal. A user who could list /dev/input could watch the directory for access events on a keyboard device even without permission to read that device. The event did not reveal which key was pressed. It did reveal when a press occurred, which is enough for inter-keystroke timing analysis. Across seven users, the paper reports F1 scores from 93.1% to 100%. A related watch on /dev/pts observed typing timing from another user's SSH session.
The Linux kernel team partially closed that route under CVE-2025-68788 by suppressing access and modify notifications on special files. The research page lists fixes in maintained kernel lines including 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65, and 6.18.3. It also gives a narrow check for the keyboard-event leak:
inotifywait -m -e access,modify /dev/input
On a mitigated kernel, pressing keys should produce no notifications from that watch. This test covers the severe /dev case, not every file-notification channel described in the paper. The authors say ordinary files can still expose events through a readable parent directory. Updating the kernel closes the demonstrated device-file path without settling the broader permission model.
A same-user KDE Plasma demonstration shows how a small signal can become part of a larger attack. The process watched /usr/bin/pkexec for access, used that event to predict an authentication dialog, and placed a fake prompt over the real one. KDE told the researchers that its focus-stealing prevention is meant to reduce popup races, not enforce a security boundary. The file event supplies the timing that makes the imitation prompt plausible, while the overlay performs the credential theft.
Android leaks the envelope
Android's case exposes the distinction between content and metadata most cleanly. Scoped storage stopped the test app from listing WhatsApp's media files under /sdcard/Android/media/com.whatsapp/WhatsApp. A permissionless FileObserver could still watch that location and receive filenames plus move, open, modify, and delete events, according to the team's demonstration.
Those events did not reveal the photo, voice note, or document itself. They revealed its type, arrival time, deletion, and whether it was sent or received because WhatsApp separates sent media into named subdirectories. One captured image appeared in its final directory about 100 milliseconds after download and decryption. That is enough to build a communication timeline around a person even when the messages and attachments stay encrypted or unreadable. The project page lists no Android mitigation.
macOS is the useful control in the study. Its FSEvents output still exposed activity involving globally readable paths, including application starts and some system-setting changes, but the researchers did not find the private-directory bypasses seen on Windows, Linux, and Android. The result points toward a practical rule for API designers: notification access should follow the permissions on the affected object, not merely the directory where a watcher was first attached.
The next defaults matter
The researchers have published proof-of-concept artifacts for all four platforms, though the repository says ACM's artifact evaluation is still in progress and warns that its Linux VM deliberately uses a vulnerable kernel. The work is more useful as a permission-model audit than as a reason to run attack code on a normal machine. Developers of sync tools, editors, security agents, and runtimes need notification APIs to keep working, so any tighter check will need tests for missed events and compatibility.
Three concrete changes will show whether this research alters that balance: Microsoft could enable its existing check by default, Android could bind FileObserver to scoped-storage visibility, and Linux could extend permission checks beyond special device files. Until then, security reviews of shared systems should treat a file-change event as data in its own right. The filename may be hidden from open() and still arrive, on time, through the watcher.