TU Graz’s File Notification Attacks Turn a Decades-Old OS Feature Into a Side Channel

Every modern operating system ships a way for one program to find out, instantly, when another program touches a file. A text editor uses it to notice when a file changes on disk. A sync client uses it to know when to upload a new version. Antivirus software uses it to scan a file the moment it lands. The feature is so ordinary that almost nobody threat-models it. A team from Graz University of Technology (TU Graz) in Austria just showed that on Linux, Android, Windows, and macOS, the watching itself is the vulnerability: an attacker who cannot read a single byte of your files can still watch the notifications about them and reconstruct your keystrokes, your private messages, and your browsing history.

The research, called File Notification Attacks, has been accepted at the ACM Conference on Computer and Communications Security (CCS) 2026, one of the field’s top venues, running November 15 to 19 in The Hague. It comes out of TU Graz’s Institute of Information Security (ISEC), the same lab whose researchers co-discovered the Meltdown and Spectre CPU vulnerabilities in 2018 and designed KAISER, the kernel-isolation technique whose approach was adopted, in one form or another, into every mainstream operating system’s own Meltdown mitigation. This time the target isn’t a CPU cache. It’s a feature almost every developer has used and almost nobody has threat-modeled: inotify on Linux, the FileObserver class on Android, ReadDirectoryChangesW on Windows, and the File System Events API (FSEvents) on macOS. The Register covered the disclosure on September 24, 2026, and the team, doctoral student Sudheendra Raghav Neela along with Xufan Zhao, Jeanette Angelika Wultsch, Hannes Weissteiner, Stefan Gast, Florian Draschbacher, and professor Daniel Gruss, has published a dedicated project page, demo videos, and proof-of-concept code alongside the paper.

A Feature Older Than the Threat Model Around It

File-notification systems exist so an application does not have to constantly re-read a directory to find out whether anything changed inside it. Instead, the operating system’s kernel (or, on Android, a thin wrapper around the Linux kernel’s own mechanism) keeps a list of “watches” and pushes an event to a subscribed process whenever a watched file or directory is opened, closed, modified, or deleted.

Every major platform has its own version, and every one of them predates modern threat modeling by a wide margin:

• Linux: inotify, available since kernel 2.6.13 in 2005.
• Android: the FileObserver class, a Java wrapper around the same Linux inotify mechanism, available since 2008.
• Windows: the ReadDirectoryChangesW Win32 API, available since Windows 2000, and wired up to the .NET FileSystemWatcher class.
• macOS: the File System Events API, available since Mac OS X Leopard (10.5) in 2007.

None of these APIs were designed with cross-user secrecy in mind. They were designed to answer one question fast: did something in this directory just change? The TU Graz team’s contribution is showing, systematically and with working exploits, how much a stranger on the same machine can learn just from the answer to that question, without ever being allowed to read the file itself.

The Bug Every Platform Shares: Watch the Directory, Not the File

The generic issue the paper describes is the same shape on every operating system it tested. If an unprivileged user tries to watch a specific file they cannot read, the OS correctly refuses with a permission error. But if that same file sits inside a directory the user can read, watching the directory instead usually succeeds, and the watcher still receives events about the file it was just denied direct access to.

That distinction, file permission versus directory permission, is exactly the kind of edge case that is easy to get right in a design document and easy to get wrong in twenty years of kernel and API evolution across four independently maintained codebases. The paper’s own framing captures the risk model precisely: the contents of the watched files stay unknown to the attacker. Only the fact that something happened to them, and when, leaks out. That sounds harmless until you realize how much information is encoded in timing and filenames alone.

Linux: A Keyboard Turns Into a Timing Channel

The most severe Linux case involves /dev/input, the directory the kernel uses to expose raw input devices. A user without permission to read a specific input-event file, such as the file that represents the keyboard, cannot watch that file directly. But if /dev/input itself is readable, which it often is on desktop Linux systems, the user can watch the whole directory and receive a notification every time any file inside it is accessed, including every single keystroke.

The notification does not reveal which key was pressed, only that a key event occurred and precisely when. That is still enough. Researchers have studied inter-keystroke timing attacks for more than two decades (the paper cites work going back to Song et al. in 2001, through Zhang and Wang in 2009 and Monaco in 2018, up to Qiu et al. in 2025), and the TU Graz team turned this notification stream into exactly that kind of attack. Neela told The Register the technique achieved keystroke-timing accuracy of “93.1 to 100 percent” across seven local test users, and a perfect 100 percent when the same technique was pointed at a remote target over SSH by watching /dev/pts instead.

The team also built a second Linux demo that has nothing to do with keystrokes: an authentication-prompt redress attack against KDE Plasma 6 running under Wayland, the display protocol explicitly designed to prevent one application from snooping on or drawing over another. By watching for access events on /usr/bin/pkexec, the binary Linux’s Polkit authorization framework uses to show a password dialog, an attacker process can tell the instant a real authentication prompt is about to appear and draw a convincing fake password window directly on top of it, fast enough that the victim never sees the real dialog underneath. The same trick works on SteamOS, which also runs KDE Plasma 6, though the team’s own SteamOS demo was captured inside a virtual machine, so behavior on real hardware may differ. According to the team, KDE’s own security response was that its focus-stealing prevention “isn’t designed to be a security mechanism,” which is a polite way of saying Wayland’s anti-snooping guarantees do not cover this particular path.

Linux is also the only one of the four platforms with an assigned CVE. CVE-2025-68788, published by NVD in January 2026, describes the fix as changing fsnotify so it no longer generates ACCESS or MODIFY events to parent-directory watchers when the child is a “special file” like a device node. It shipped in kernels 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.64, and 6.18.3, and the fix is described in NVD’s own record as closing “some side-channels,” not all of them. That hedge matters: this patch stops the specific /dev/input keystroke-timing path, but the underlying design pattern, that a readable parent directory can expose events on unreadable children, still exists everywhere else it applies.

Android: Watching WhatsApp From Outside the Sandbox

Android’s per-app storage model is supposed to keep one app from seeing another app’s private files, enforced through a FUSE (Filesystem in Userspace) layer that presents each app with its own isolated view of storage. The team found that FileObserver, Android’s Java wrapper around inotify, sits underneath that isolation layer rather than being constrained by it. An unprivileged app that can obtain a file-notification watch can see events on another app’s private folder even though it was never granted access to browse or read that folder through the normal FUSE-mediated path.

The team demonstrated this directly against WhatsApp, watching its private media folder and recovering exactly when photos, videos, and documents were sent, received, or deleted, by filename and timestamp, without ever opening or reading a single one of those files. According to the project’s own published Q&A, no mitigation has shipped for Android as of publication, despite the team reporting the issue during the same August-to-October 2025 responsible-disclosure window it used for the other three platforms.

Windows: A Directory Watch Becomes Real-Time Browsing History

Windows produced the most striking single demo. Mounting a ReadDirectoryChangesW watch on a directory a user cannot read normally fails with a permission error, exactly as expected. But mounting that same watch on the root of a drive, C:\, bypasses the check entirely. From there, the watcher receives the full path of every file touched anywhere on the system, by any user, regardless of whether it had permission to read that file, according to Neela’s account to The Register.

The team turned this into a live browsing-history leak. Firefox creates a separate profile subdirectory for every website that uses local storage, IndexedDB, or a cache, and that subdirectory’s name contains the site’s own domain. An attacker watching C:\ and filtering for filenames that look like URLs can watch, in real time, which sites another logged-in user is visiting, no file contents required. The project’s own site demonstrates this live against arstechnica.com and reports an F1 score of 97.8 percent monitoring the top 1,000 websites this way. Separately, in his email to The Register, Neela cited a related fingerprinting result of 87.9 percent against the top 100 sites, a second, distinct evaluation of the same underlying technique rather than the identical figure restated.

Microsoft’s response to the report is the detail that has traveled furthest. According to the team, Microsoft called the root-directory bypass an “undocumented feature” and, per Neela, considers the behavior to be by design. The finding earned Microsoft a nomination in the “lamest vendor response” category at the 2026 Pwnie Awards, the security industry’s semi-satirical annual prizes.

There is a wrinkle worth getting right: Windows does have a way to close this specific hole, but it did not come from this disclosure. After the paper was already submitted, the TU Graz team found that Microsoft had separately introduced a registry policy called EnforceDirectoryChangeNotificationPermissionCheck, in response to an unrelated but similar report filed by researcher Sébastien Huneault in April 2025 about unauthorized disclosure of file paths. That policy does mitigate the exact behavior the TU Graz paper describes. The catch is that it ships disabled by default, so, in the team’s own words, “all the attacks we report in this paper work out-of-the-box on Windows systems” unless an administrator turns the policy on manually.

macOS: The One Platform That Mostly Held Up

macOS fares meaningfully better than the other three, though not perfectly. The File System Events API only exposes information tied to globally readable files, and the team found no way to bypass Apple’s permission checks to read private, per-user directories the way the Linux, Android, and Windows attacks do. Of the four platforms tested, macOS is the one that leaked the least to an unprivileged watcher.

That does not mean macOS leaks nothing. FSEvents can still surface system-level metadata changes recorded in property list (.plist) files: audio input and output device changes, power-setting changes, Bluetooth device and printer pairing updates, DNS changes triggered by plugging in a network cable, volume mount and unmount events, and application installs or removals. None of that is as dramatic as timing a fake password prompt or tracking another user’s real-time browsing history, but it is still real behavioral telemetry an unprivileged, cross-user watcher was never supposed to have. As with Android, the project’s own tracker lists no fix for macOS.

Who Is Actually Exposed

It’s worth being precise about the threat model here, because it is easy to overstate. Every attack in the paper requires what the researchers describe as “a local, cross-user attacker,” meaning someone who already has an account, a compromised service, or a foothold via a supply-chain-compromised package running on the same machine as the victim. None of this is a remote, pre-authentication network attack against a random internet-facing server. The researchers’ own FAQ states plainly that they are “unaware of any” case of these specific techniques being exploited in the wild.

Where that threat model is realistic, though, it is very realistic: shared university lab machines, multi-user development servers, SSH bastion hosts, virtual desktop infrastructure, cloud instances where several teams or automated agents share one filesystem, and any Android device where a malicious or compromised app runs alongside sensitive ones like a banking or messaging app. Container and sandbox platforms that put several tenants on shared storage, a pattern this site has covered before with an unrelated Cloudflare Containers bug that let one customer recover another’s leftover disk data, sit in exactly the same risk category: isolation that looks solid at the permission-check layer can still leak through a side channel the permission check was never designed to cover.

What Changes, and What Doesn’t, Right Now

The team disclosed its findings to the Linux, Android, Windows, and macOS security teams between August and October 2025, well over a year before the paper’s CCS 2026 acceptance and public release. The state of remediation, as the researchers describe it today, is uneven:

• Linux has a partial kernel fix (CVE-2025-68788) covering the specific /dev/input-style special-file case, already shipped in current stable kernels.
• Windows has an unrelated, coincidentally-effective registry policy that is off by default.
• Android and macOS have no fix at all as of publication.

The researchers have released working proof-of-concept code on GitHub alongside the paper, and their project page walks through each demo in detail, including the exact commands needed to check whether a given Linux kernel already has the fix. The research was supported in part by the European Research Council, the Austrian Science Fund, and, according to the team’s own acknowledgments, a gift from Intel.

For anyone running a machine that more than one person, service, or process can log into, the practical takeaway is narrow but concrete: a file-notification API you never explicitly configured is quietly watching more than you’d expect, and on three of the four major operating systems, nobody has made it stop.