CVE-2026-112909

Affected versions of the `filelock` package are vulnerable to Link Following due to truncating, and with an explicit `mode` also changing the permissions of, whatever regular file is found at the lock path, whether or not the acquire created it. `UnixFileLock`, the backend of `FileLock` and `AsyncFileLock` on Unix, empties the file at the lock path once it holds the lock, and the `O_NOFOLLOW` defence added for CVE-2025-68146 does not see a renamed file or a hard link. A local attacker who can rename or hard-link one of the lock user's files onto the lock path gets that file truncated by the next `acquire()`, and with a mode such as `0o666` gains read and write access to it.