Side-Channel Leakage from the File-Notification System on Linux, Android, Windows, and macOS.
Accepted at The ACM Conference on Computer and Communications Security (CCS), November 15-19, 2026 — The Hague, Netherlands
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.
Demos
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.
1. Linux: Inter-Keystroke Timing
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.
2. Linux: Authentication-UI Redress
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):
3. Android: Revealing Private Communication
As stated before:
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.
4. Windows: Direct Website Leakage
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%.
Here are more examples:
Team
The team comprises of researchers from the Institute of Information Security (ISEC) at Graz University of Technology, Austria:
- Sudheendra Raghav Neela
- Xufan Zhao
- Jeanette Angelika Wultsch
- Hannes Weissteiner
- Stefan Gast
- Florian Draschbacher
- Daniel Gruss
Some Questions and Answers
1. Am I affected?
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.
2. Are there fixes?
» Linux «
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:
inotifywait -m -e access,modify /dev/input
If you do not see any notifications appear (like Video 2 above), then your kernel has the mitigation in place.
» KDE «
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:
» Android «
None
» Windows «
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.
» MacOS «
None
3. What can be leaked?
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.
4. Have these attacks been exploited in the wild?
We are unaware of any such case.
5. Can I use the logo?
Sure, it’s licensed under CC-BY 4.0: Download SVG, PNG.
Please attribute it this way:
Creator: Brinda Neela License: CC-BY 4.0 Link: https://inoti.fyi
6. Is there proof of concept code?
Yes, check out: https://github.com/isec-tugraz/file-notification-attacks.
Acknowledgements
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.