CVE-2026-112934

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

SoftReadWriteLock (and AsyncSoftReadWriteLock, which wraps one) refreshes its holder record (the file under <path>.rw/holders/ that says a process holds or wants the lock) on every poll of a waiting acquire and on every heartbeat (the periodic refresh a holder runs to keep its record fresh). It does so by reopening <path>.rw/holders/<token> by name with a plain blocking O_WRONLY | O_NOFOLLOW open and writing at offset 0, without checking what it opened. O_NOFOLLOW makes the open fail only when the final name is a symbolic link (a file that redirects to another path).

A different local user (the other user below) who owns the lock's .rw tree reads the token of the user running the lock (the lock user below) from the holders/ listing and renames another node over the record. The other user owns the tree because it created it first in a sticky directory such as /tmp (the sticky bit is a directory flag that lets only a file's owner rename or remove it), or because it can write a lock directory without the sticky bit.

A FIFO (a named pipe: a file whose open for writing blocks until some process opens it for reading) makes the lock user's write_lock() / read_lock() hang regardless of timeout. It also stops a lock holder's heartbeat thread without on_compromise (the callback that tells a holder it lost the lock) ever running, so the lock grants a second process while the first still believes it holds it. This works on a default Linux.

Where the kernel lets a user hard-link a file it does not own (a hard link is a second name for the same file; Linux with fs.protected_hardlinks=0; macOS and the BSDs by their defaults, not executed), a hard link makes the lock user overwrite the first ~135 bytes of one of its own private files with its holder record. Affected versions: filelock >= 4.0.0 and <= 4.2.0. Anthropic's OSS Scanner reported it in private as ANT-2026-AT33VEVC [medium, CWE-62], titled "SoftReadWriteLock holder refresh writes through hard links, hangs on FIFOs".

Severity

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, 6.1 (Medium).

AV:L (local): the other user needs an account on the same host. AC:L (low attack complexity): on a default Linux there is no race. PR:L (low privileges): a local user with ordinary privileges is enough. UI:N (no user interaction): the lock user's process acts on its own. C:N (no confidentiality impact): the other user learns nothing. I:L (low integrity impact): where the kernel permits hard links to files one does not own, the lock user also writes its holder record over the first ~135 bytes of one of its private files. The bytes are filelock's record, not chosen by the other user, so the change stays within that record. A:H (high availability impact): the other user makes a lock user's acquire outlast any timeout and leaves a holder's heartbeat thread asleep. The lock then evicts the holder without telling it, and two processes believe they hold the write lock.

Classification from the external review: conditional security. The owner of a planted .rw tree can make the refresh open a FIFO and stall a lock user, including its heartbeat. Overwriting a file of the lock user through a hard link also needs a permissive hard-link policy. The scanner rated it medium.

Scope and preconditions

• Trust boundary: the other party is a different local account that owns the lock's .rw tree. Either it created <path>.rw (with gen/ and holders/) before the lock's first use in a sticky directory such as /tmp, where prepare() adopts an existing tree whoever owns it and whatever its mode. Or the lock lives in a directory without the sticky bit that the account can write (the scanner checked a root-created 0777 directory). There being first is not needed, because the other user renames the lock user's own 0700 tree aside and puts its own in place; prepare() does not run again for a live lock object, and a waiting lock user recreates its…

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

SoftReadWriteLock (and AsyncSoftReadWriteLock, which wraps one) refreshes its holder record (the file under <path>.rw/holders/ that says a process holds or wants the lock) on every poll of a waiting acquire and on every heartbeat (the periodic refresh a holder runs to keep its record fresh). It does so by reopening <path>.rw/holders/<token> by name with a plain blocking O_WRONLY | O_NOFOLLOW open and writing at offset 0, without checking what it opened. O_NOFOLLOW makes the open fail only when the final name is a symbolic link (a file that redirects to another path).

A different local user (the other user below) who owns the lock's .rw tree reads the token of the user running the lock (the lock user below) from the holders/ listing and renames another node over the record. The other user owns the tree because it created it first in a sticky directory such as /tmp (the sticky bit is a directory flag that lets only a file's owner rename or remove it), or because it can write a lock directory without the sticky bit.

A FIFO (a named pipe: a file whose open for writing blocks until some process opens it for reading) makes the lock user's write_lock() / read_lock() hang regardless of timeout. It also stops a lock holder's heartbeat thread without on_compromise (the callback that tells a holder it lost the lock) ever running, so the lock grants a second process while the first still believes it holds it. This works on a default Linux.

Where the kernel lets a user hard-link a file it does not own (a hard link is a second name for the same file; Linux with fs.protected_hardlinks=0; macOS and the BSDs by their defaults, not executed), a hard link makes the lock user overwrite the first ~135 bytes of one of its own private files with its holder record. Affected versions: filelock >= 4.0.0 and <= 4.2.0. Anthropic's OSS Scanner reported it in private as ANT-2026-AT33VEVC [medium, CWE-62], titled "SoftReadWriteLock holder refresh writes through hard links, hangs on FIFOs".

Severity

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, 6.1 (Medium).

AV:L (local): the other user needs an account on the same host. AC:L (low attack complexity): on a default Linux there is no race. PR:L (low privileges): a local user with ordinary privileges is enough. UI:N (no user interaction): the lock user's process acts on its own. C:N (no confidentiality impact): the other user learns nothing. I:L (low integrity impact): where the kernel permits hard links to files one does not own, the lock user also writes its holder record over the first ~135 bytes of one of its private files. The bytes are filelock's record, not chosen by the other user, so the change stays within that record. A:H (high availability impact): the other user makes a lock user's acquire outlast any timeout and leaves a holder's heartbeat thread asleep. The lock then evicts the holder without telling it, and two processes believe they hold the write lock.

Classification from the external review: conditional security. The owner of a planted .rw tree can make the refresh open a FIFO and stall a lock user, including its heartbeat. Overwriting a file of the lock user through a hard link also needs a permissive hard-link policy. The scanner rated it medium.

Scope and preconditions

• Trust boundary: the other party is a different local account that owns the lock's .rw tree. Either it created <path>.rw (with gen/ and holders/) before the lock's first use in a sticky directory such as /tmp, where prepare() adopts an existing tree whoever owns it and whatever its mode. Or the lock lives in a directory without the sticky bit that the account can write (the scanner checked a root-created 0777 directory). There being first is not needed, because the other user renames the lock user's own 0700 tree aside and puts its own in place; prepare() does not run again for a live lock object, and a waiting lock user recreates its…

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.