"StrictSoftFileLock" and "AsyncStrictSoftFileLock" check "<path>.filelock" (the coordination directory that holds the lock's state) with one "lstat" call on its name. "lstat" reports what a name is without following a symbolic link (a file that redirects to another path). After that check, the code reaches "<path>.filelock/claims" by pathname for every later operation ("mkdir", scan, publish, link, unlink). "_open_directory" passes "O_NOFOLLOW" (a flag that makes an open fail when the final name is a symbolic link), but the flag covers only the final "claims" component. The kernel follows a symbolic link in any earlier component. Another local user (the other user below) who can rename "<path>.filelock" exchanges it for a symbolic link after the check. In a shared directory without the sticky bit (a directory flag that lets only a file's owner rename or remove it), any user with write access can do this. Where the shared directory is sticky, such as "/tmp", only the user who created "<path>.filelock" before the user running the lock (the lock user below) first used it can. The lock user's process (root's, if root takes the lock) then creates a "claims" directory and claim files (the files whose presence says a process wants or holds the lock) inside a directory the other user chooses but only the lock user can write. When the link points at another strict lock's ".filelock" directory, the stranded claims make that lock time out for every process until an operator finds and force-breaks each one. The "claims" property and "force_break()" resolve the same path with no check at all. Affected versions: filelock >= 3.30.0 and <= 4.2.0 (finding "ANT-2026-SVFEYX89").