File Notification Attacks: Side-Channel Leakage from the File-Notification System on Linux, Android, Windows, and macOS

File-notification systems tell applications when files change, e.g., opened, closed, written, deleted. With only read permission on a file or directory, an attacker can watch these notifications and reconstruct user behavior. We find generic issues similar on each of Linux, Android, Windows, and macOS. However, there are three issues that are severe and unique to their platform:

1. On Linux, watching a readable directory reports every event on a file inside it, even one the attacker cannot read directly. The most severe case of this is with /dev/input, discussed in Inter-Keystroke Timing below.

2. On Android, FileObserver bypasses the FUSE layer's per-app storage view, letting an unprivileged app watch another app's private folder. We show this against WhatsApp, revealing exactly when photos, videos, and files arrive or get deleted, detailed in Revealing Private Communication below.

3. On Windows, watching the root directory (C:\) reports the full path of every file touched anywhere on the system, regardless of permissions, even across users 🙂. Microsoft considers this an ✨ undocumented feature ✨. The most severe case we found is leaking which websites another user visits in real time, shown in Direct Website Leakage below. Our findings got Microsoft nominated for the lamest vendor response category at the Pwnies Award 2026.

On Linux, the file-notification subsystem is called inotify, allowing cross-user applications to mount watches on files or directories since kernel 2.6.13 (2005).

On Android, this subsystem is called FileObserver class (since 2008), a Java wrapper around inotify.

Windows offers the ReadDirectoryChangesW Win32 API, available since Windows 2000. With this API, cross-user applications can mount watches on directories, getting notifications for operations on the directory, or files within the directory. In dotnet, the FileSystemWatcher class is wired to ReadDirectoryChangesW.

On macOS, the File System Events API allows for applications to know when files in a watched directory change. This API has been around since Mac OS X Leopard version 10.5 (2007); archived link to Apple Developer Connection – Leopard OS Foundations Overview.

We demonstrate four interesting case studies below. The first two are on Linux: inter-keystroke timing and authentication-UI redress. The third is on Android, and the fourth video is on Windows: direct website leakage.

The major point to remember on all systems is that the contents of these files are unknown. We only get notifications on files, which we show is enough to leak user, system, and application behavior. In some cases, we also learn about the existence of files that we traditionally could not have known.

On Linux, mounting an inotify watch on a file without read-permission results in a permission denied error. However, if the file’s parent directory is readable, watching that directory will report all events that occur on the file.

This means that if a user can’t read /dev/input/event4, adding an inotify watch on the file results in a permission-denied error. However, if the user can read /dev/input – i.e., they can list the files in the directory – then an inotify watch on the directory succeeds, and the user receives notifications for all files inside it, as shown below:

On this system, event4 happens to correspond to a keypress. Important to note is that which key is not leaked, but only that a key was pressed. Although this may not sound terrible, there has been 2+ decades of research on inter-keystroke timing attacks: the time taken between keys leaks information. For example, in the word ‘WindRunner’, users tend to type the second ‘N’ faster than the other characters due to the finger already being over the ‘N’ key.

These include: Song et al. (2001), Zhang and Wang (2009), Monaco (2018), and most recently Qiu et al. (2025).

This behavior is also observed when two different users are logged on to the same server via SSH. One user can observe whenever* the other user presses a key by monitoring /dev/pts.

* The input should have a text update on the terminal. Typing into sudo password prompts with pwfeedback disabled does not generate notifications.

We show an authentication-UI redress attack on KDE Plasma running on Wayland, where a same-user process watches /usr/bin/pkexec of polkit for accesses to detect when an authentication prompt appears. As soon as the real password dialog is about to open, the attacker quickly draws a fake password window on top of it, tricking the user into entering their credentials. Even though Wayland is designed to block input snooping, KDE’s focus-stealing prevention isn’t designed to be a security mechanism, according to KDE Plasma’s security team.

Since SteamOS also uses KDE Plasma 6, here’s a picture of the KDE terminal (Konsole) drawn over the authentication prompt window on SteamOS (this was inside a VM so it may differ in practice):

On Android, FileObserver bypasses the FUSE layer’s per-app storage view, letting an unprivileged app watch another app’s private folder. We show this against WhatsApp, revealing exactly when photos, videos, and files arrive or get deleted.

Every app is assigned a private folder at /sdcard/Android/, hidden from other apps through Android’s FUSE layer, and Android’s FUSE layer is supposed to keep it hidden from every other app. Normally, an unprivileged app calling File.listFiles() on WhatsApp’s private media folder, e.g., /sdcard/Android/media/com.whatsapp/WhatsApp, gets empty subfolders and no files returned by the kernel. The FUSE layer filters WhatsApp’s files out of the listing entirely, and therefore the folder looks empty to other apps. Our research shows that this protection doesn’t extend to file notifications: a second unprivileged app with no permissions can still mount a FileObserver watcher on that same folder and gets notified of every file event (plus file name!) inside it, despite not being able to list a single file in it.

For example with WhatsApp, incoming media shows up as a MOVED_TO event with the file name. In our logs, IMG-20260401-WA0011.jpg is moved to WhatsApp Images/ about 100ms after WhatsApp finishes downloading and decrypting it (the .Shared/), as seen from our proof-of-concept app’s (enormous) logcat output:

Sent media is kept separate, so the attacker also learns whether the image was sent or received. Images are located in WhatsApp Images/Sent/, documents are located in WhatsApp Documents/Sent/, everything else received stays in the parent folder. Since file names alone reveal the media type (image, video, voice note, or document) and their creation time, an attacker builds a timeline of exactly what and when a user sent and received. Deleting files also generates events, so removing a message’s media afterwards can be observed.

On Windows, mounting a ReadDirectoryChangesW watch on a non-readable directory results in a permission-denied error. However, mounting it on the root directory (e.g., C:\) bypasses this restriction, causing Windows to report all filesystem events system-wide along with the filename, regardless of whether the affected files are readable. In our responsible disclosure with them, Microsoft said that they consider this an undocumented feature.

One example where filenames leak information is the directory created by browsers when visiting a website. Firefox creates and uses a separate directory for every website that uses local storage, IndexedDB, or cache. Notably, this directory contains the name of the website. On Firefox, an attacker can reliably monitor top-1000 websites with an F1 score of 97.8%.

The team comprises of researchers from the Institute of Information Security (ISEC) at Graz University of Technology, Austria:

If you use Linux, Android, Windows, or macOS, you are most certainly affected to varying degrees.

While macOS exposes the least information via only globally readable files, with no leaks of private information (unlike Linux, Android, and Windows), we find that user, application, and system behavior can still be tracked, although to a much smaller extent.

In December 2025, the Linux issue was partially mitigated to not generate ‘access’ / ‘modify’ events on special files, essentially character files, which the files in /dev/ basically are. We thank Amir Goldstein, Jan Kara, Greg Kroah-Hartman, and the Linux Kernel Security Team for discussing and partially mitigating the issue. While it’s not fully mitigated, the most severe issues are mitigated. This issue was assigned CVE-2025-68788 and was mitigated in kernels 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65, and 6.18.3.

You can check whether this command generates notifications when you press keys on the keyboard:

If you do not see any notifications appear (like Video 2 above), then your kernel has the mitigation in place.

In our emails with the KDE security team, they replied that focus-stealing prevention is not meant as a security measure, but rather to avoid race conditions with annoying popups.

What we find works for the time being in KDE Plasma 5 and 6:

Open a terminal, type pkexec ls (doesn’t matter where). Right click on the top of the password window > More Actions > Configure Special Application Settings > Add Property > Keep Above Other Windows (click +) > close the properties window > Set “Keep above other windows” to “Force” and click “Yes” > OK.

Here’s a video to walk you through it:

Well after our paper was submitted and despite our report to Microsoft, we independently came across: Access check enhancements to prevent unauthorized disclosure of file paths which are similar to our Windows findings, the bugs reported to Microsoft by Sébastien Huneault in April 2025. Microsoft introduced a new registry policy, EnforceDirectoryChangeNotificationPermissionCheck, which mitigates the behavior we report. This policy is disabled by default, i.e., all the attacks we report in this paper work out-of-the-box on Windows systems. The earlier linked post has instructions to enable this on your device.

The major point to remember on all systems is that the contents of these files are unknown. Only notifications on files are leaked, which we show is enough to leak user, system, and application behavior. In some cases (Windows, Android), we also learn about the existence of files that we traditionally could not have known.

Note that the attacks we present require a local, cross-user attacker (think of a compromised user/system service), or a supply-chain-attacked package.

We are unaware of any such case.

Sure, it’s licensed under CC-BY 4.0: Download SVG, PNG.

Please attribute it this way:

Yes, check out: https://github.com/isec-tugraz/file-notification-attacks.

This research is supported in part by the European Research Council (ERC project FSSec 101076409), and the Austrian Science Fund (FWF SFB project SPyCoDe 10.55776/F85). Additional funding was provided by a generous gift from Intel. Any opinions, findings, and conclusions or recommendations expressed in this paper and website are those of the authors and do not necessarily reflect the views of the funding parties.