Graz researchers use file-change notifications to infer keystroke timing on Linux, plus other leaks on Android and Windows

Access control on these systems guards the contents of a file, not the metadata a change notification carries about it. Register a watch on a directory and the kernel reports which path changed, what kind of change it was, and when, even when you cannot open the files inside. ^[4] The path names and the timestamps are enough. Unprivileged code, or an Android app that requested no permission, turns that stream into a record of another user's activity. ^[3]

On Linux the tool is inotifywatch. Point it at a directory you have no read access to and the gaps between keystrokes still come through, because each keystroke a target application handles produces a file event you can time. ^[5] Windows leaks something cruder: browser storage keeps site names in the paths themselves, so a watch on a drive root gives up browsing destinations directly. ^[11] On Android the same idea runs through FileObserver and exposes WhatsApp media filenames and app launches. ^[12]

The KDE attack works differently. The researchers watch /usr/bin/pkexec to catch the moment Polkit spawns an authentication prompt on KDE 5 and 6, then draw a fake password window over the real one to collect what the victim types. ^[6] That one is narrower: it needs the attacker's process running under the victim's account in the same graphical session, and the victim has to type into the fake screen. ^[7] Plain activity monitoring shows nothing on screen at all. ^[13]

Two mitigations exist and neither closes the demonstrated attacks. The Linux kernel got a partial fix, CVE-2025-68788, in the 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65 and 6.18.3 kernels shipped in January. ^[9] It suppresses access and modify notifications for special files and does not resolve all the leaks in the paper. ^[8] LWN reports that both the keystroke-timing flaw and the KDE clickjacking flaw are still present today. ^[10]

On Windows, Microsoft added access checks to NTFS and ReFS change notifications in updates from April 8, 2025, behind a setting named EnforceDirectoryChangeNotificationPermissionCheck. It is disabled by default, and an administrator has to test compatibility before turning it on. ^[14]

Blocking the notification APIs outright is not an option, because ordinary applications use them, so spotting a malicious watch or the fake-prompt process needs endpoint telemetry that most shared hosts do not run. ^[15] The Graz group disclosed the work on 24 September 2026. ^[1] The proof-of-concept code is public, and active exploitation in the wild has not been confirmed. ^[16]