CVE-2026-112908

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.

StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel (the lock file at <path>) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims, <path>.filelock and <path>.filelock/claims, with a bare mkdir(). That gives 0o777 filtered through the umask (a per-process mask that removes permission bits from new files and directories) or, under a parent with a default ACL (an access control list on a directory that sets the permissions of entries created inside it), through that ACL.

A hold consists of two claim names in that directory, which has no sticky bit (a directory flag that lets only a file's owner remove it). When the environment leaves another local user (the other user below) a write bit on the directory, that user can unlink the holder's 0600 claims. Three settings do this: umask 000 in a sticky directory such as /tmp, umask 002 with the other user in the directory's group, or a default ACL on the lock's parent that grants the group write (the kernel then ignores the umask). After the unlink, the next contender of the holder's account finds the directory empty and enters. The first holder keeps reporting is_locked == True and later releases with no error. Affected versions: filelock >= 3.30.0 and <= 4.2.0 (finding ANT-2026-AD6SUOON).

Severity

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

AV:L (local): the other user needs an account on the same host. AC:H (high attack complexity): the holder must pass a restrictive mode while its umask or the parent's default ACL leaves the other user a write bit on new directories, and a contender of the holder's account must ask for the lock after the claims are gone. With the common umask 022 and no default ACL the directories are 0755, and the kernel refuses the other user's unlink. PR:L (low privileges): an unprivileged account is enough. UI:N (no user interaction): the holder's processes act on their own.

C:N (no confidentiality impact): the 0600 claim files stay unreadable. I:H (high integrity impact): two holders then write the data the lock protects, and neither learns of the other. A:L (low availability impact): the same write access lets the other user create names in claims, and an empty file named held-v1-<32 zeros>.claim makes the next acquire() raise SoftFileLockProtocolError ("malformed claim record") until someone removes it. Classification from the review: security, conditional on a lax umask or a permissive default ACL. The scanner rated it high (CWE-732).

Scope and preconditions

• The holder passes a restrictive mode such as 0o600. Without one, the umask decides the permissions by documented design (the "File permissions and mode" section of docs/concepts.rst defines mode only for the lock file). Umask 000 with the default mode gives the same two-holder result but is outside this finding.

• The holder's environment leaves the other user a write bit on new directories. The scanner measured three ways, with mode=0o600 and the other user a member of group team:

  | lock's parent directory | holder's umask | <path>.filelock and claims/ | who can unlink the claims | |---|---|---|---| | 1777, like /tmp | 000 | 0777 | any other local user | | root:team, 3775 (setgid, so new entries inherit the group, and sticky) | 002 | 2775 | any member of team | | root:team, 1770, default ACL group:team:rwx (setfacl -d -m g:team:rwx) | 077 | 0770 | any member of team | | root:team, 3775, no ACL | 022 | 2755 | no one; the second process times out |

  The default-ACL row is the strongest. A holder with a private umask and mode=0o600 still gets group-writable claim directories. The lock file in that row is 0600, because its mode reaches os.open and masks the inherited ACL.

• A contender that may enter asks for the…

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.

StrictSoftFileLock and AsyncStrictSoftFileLock apply the caller's mode to the sentinel (the lock file at <path>) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims, <path>.filelock and <path>.filelock/claims, with a bare mkdir(). That gives 0o777 filtered through the umask (a per-process mask that removes permission bits from new files and directories) or, under a parent with a default ACL (an access control list on a directory that sets the permissions of entries created inside it), through that ACL.

A hold consists of two claim names in that directory, which has no sticky bit (a directory flag that lets only a file's owner remove it). When the environment leaves another local user (the other user below) a write bit on the directory, that user can unlink the holder's 0600 claims. Three settings do this: umask 000 in a sticky directory such as /tmp, umask 002 with the other user in the directory's group, or a default ACL on the lock's parent that grants the group write (the kernel then ignores the umask). After the unlink, the next contender of the holder's account finds the directory empty and enters. The first holder keeps reporting is_locked == True and later releases with no error. Affected versions: filelock >= 3.30.0 and <= 4.2.0 (finding ANT-2026-AD6SUOON).

Severity

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

AV:L (local): the other user needs an account on the same host. AC:H (high attack complexity): the holder must pass a restrictive mode while its umask or the parent's default ACL leaves the other user a write bit on new directories, and a contender of the holder's account must ask for the lock after the claims are gone. With the common umask 022 and no default ACL the directories are 0755, and the kernel refuses the other user's unlink. PR:L (low privileges): an unprivileged account is enough. UI:N (no user interaction): the holder's processes act on their own.

C:N (no confidentiality impact): the 0600 claim files stay unreadable. I:H (high integrity impact): two holders then write the data the lock protects, and neither learns of the other. A:L (low availability impact): the same write access lets the other user create names in claims, and an empty file named held-v1-<32 zeros>.claim makes the next acquire() raise SoftFileLockProtocolError ("malformed claim record") until someone removes it. Classification from the review: security, conditional on a lax umask or a permissive default ACL. The scanner rated it high (CWE-732).

Scope and preconditions

• The holder passes a restrictive mode such as 0o600. Without one, the umask decides the permissions by documented design (the "File permissions and mode" section of docs/concepts.rst defines mode only for the lock file). Umask 000 with the default mode gives the same two-holder result but is outside this finding.

• The holder's environment leaves the other user a write bit on new directories. The scanner measured three ways, with mode=0o600 and the other user a member of group team:

  | lock's parent directory | holder's umask | <path>.filelock and claims/ | who can unlink the claims | |---|---|---|---| | 1777, like /tmp | 000 | 0777 | any other local user | | root:team, 3775 (setgid, so new entries inherit the group, and sticky) | 002 | 2775 | any member of team | | root:team, 1770, default ACL group:team:rwx (setfacl -d -m g:team:rwx) | 077 | 0770 | any member of team | | root:team, 3775, no ACL | 022 | 2755 | no one; the second process times out |

  The default-ACL row is the strongest. A holder with a private umask and mode=0o600 still gets group-writable claim directories. The lock file in that row is 0600, because its mode reaches os.open and masks the inherited ACL.

• A contender that may enter asks for the…

filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1,  StrictSoftFileLock  and  AsyncStrictSoftFileLock  on POSIX systems create coordination and claim directories without applying the caller’s restrictive lock mode. A permissive umask or inherited default ACL can leave these directories writable by another local user, allowing that user to delete an active holder’s claims. Another authorized process can then acquire the lock while the original holder remains in its critical section. An attacker can also plant malformed claims to prevent acquisition. This issue is fixed in version 4.2.1.