filelock@4.0.2

Affected versions of this package are vulnerable to Incorrect Permission Assignment for Critical Resource via the Windows file lock backend (WindowsFileLock), which ignores the mode parameter when creating lock files. An attacker with local access can observe or interfere with lock files that should have been created with restrictive permissions (e.g. mode=0o600), because the NtCreateFile call is made without a security descriptor regardless of the requested mode, leaving the file with the directory's default ACL instead of an owner-only ACL. This also affects deadline handling and lock file integrity in the affected backends.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Incorrect Permission Assignment for Critical Resource via the strict-mode lock implementation in _strict.py and related soft read-write lock components, where claim directories are created with permissions that allow other local users to list or remove claim files. An attacker sharing the same host can delete a victim process's claim files from the lock's claims directory while the victim holds the lock, causing a second process to enter the critical section concurrently and bypassing the mutual-exclusion guarantee.

Note: This is only exploitable when no other user can replace the lock's directory or any of its ancestors, meaning the attack requires write access to the claims directory itself, which is possible when the victim process runs with a permissive umask (e.g. 0o000) that leaves the claims directory world-writable.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Improper Locking via SoftFileLock.acquire on Windows, where a os.open call used to read a soft-lock marker file blocks indefinitely when another handle holds a Level 1 or batch oplock on that file and never acknowledges the break request. An attacker holding such an oplock can cause acquire to stall well past the caller-specified timeout, effectively preventing lock acquisition for the duration of the oplock hold.

Note: This is only exploitable on Windows (NTFS) when another handle holds a Level 1 or batch oplock on the lock file and does not acknowledge the break.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Time-of-check Time-of-use (TOCTOU) Race Condition via SQLite side-file handling in _read_write.py on Windows, where a local attacker can plant adversarial -wal or -journal side files adjacent to the lock database in a shared directory (such as C:\Windows\Temp). When the lock user's process opens the database, SQLite processes the attacker-controlled side file, causing an OperationalError (disk I/O error or inability to open the database) that prevents lock acquisition and crashes the locking operation.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Symlink Attack via the lock file open logic in _api.py and related platform backends, where an existing lock file's permissions are not preserved on Unix systems. An attacker with local access can observe the file mode applied to a newly created lock file, potentially reading its contents or inferring sensitive path information that would otherwise be restricted by the original file's ACL.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Insufficient Verification of Data Authenticity via owner_is_stale in src/filelock/_soft.py and src/filelock/_identity.py, when a process owner identity comparison is performed between a lock holder whose start token was recorded without a boot ID (high 64 bits equal to zero) and a new process whose token includes a boot ID. Because the original comparison used set membership (process_start_token(pid) in {None, start_token}) rather than a boot-ID-aware equality check, a live lock holder can be incorrectly classified as stale when the reader and the owner run in different Linux time namespaces or when one side cannot read /proc/sys/kernel/random/boot_id. This allows a competing process to prematurely reclaim the lock, corrupting the mutual-exclusion guarantee and enabling unauthorized writes to the protected resource.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Use of Incorrectly-Resolved Name or Reference via the lock-file open logic in _unix.py and related backends, where acquiring a lock on a file that does not yet exist creates it with a permissive mode (e.g. 0o666) rather than preserving the permissions of an existing lock file or applying a restrictive default. A local attacker who can observe or race the lock-file creation can read file contents that are written to the lock file (such as a SQLite journal) by a more-privileged process, or replace the lock file to redirect locking operations, achieving information disclosure and integrity impact.

Note: The protection against another local user holds only when no other user can rename entries in the lock's directory; passing a permissive explicit mode (e.g. 0o666, 0o660, 0o644) to the lock constructor also widens the exposure beyond the default truncation-only risk.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to UNIX Hard Link via OsFiles.overwrite() in SoftReadWriteLock, which refreshes holder records by name without verifying the file identity. A local attacker who has rename access to the lock directory can replace a holder record with a named pipe to stall the lock, or, under a permissive hard-link policy, hard-link a reachable target file and cause the lock user to write through it.

Note: The hard-link vector requires a non-default kernel hard-link policy (e.g., fs.protected_hardlinks=0 on Linux, or macOS/BSD default behavior); the named-pipe vector requires rename access to the lock directory.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Unverified Ownership via the strict lock implementation in _strict.py and related claim directory handling, where mkdir(mode=0o700) only enforces private permissions when it creates the directory and the subsequent lstat check reads neither st_uid nor the permission bits. A local attacker who can replace the lock's claim directory or any of its ancestors can hijack the lock, leading to integrity violations or denial of service against processes relying on the lock for mutual exclusion.

Note: This is only exploitable when another local user can replace the lock's directory or any of its ancestors.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Time-of-check Time-of-use (TOCTOU) Race Condition via the stale-lock-breaking logic in _try_break_expired_lock and _try_break_stale_lock, where a race condition allows an attacker with write access to the lock directory to replace a held lock file with a new file between the time the inode is read and the time the break is executed. Because the original code did not pin the inode before acting on the stale marker, an attacker can cause the stale-break logic to evict a live lock, allowing two processes to hold the same lock simultaneously and corrupting the integrity guarantee that filelock provides.

Note: This is only exploitable when another local user has write access to the lock file's directory or any of its ancestor directories.

Upgrade filelock to version 4.2.1 or higher.

Affected versions of this package are vulnerable to Symlink Attack via ReadWriteLock in src/filelock/_read_write.py, which resolves the lock file path using Path.resolve() before passing it to sqlite3.connect(). An attacker who can plant a symlink in a shared lock directory can cause the victim process to open, lock, or create the symlink's target instead of the intended lock file. By repointing the symlink between two lock constructions, two writers can simultaneously hold the lock, breaking mutual exclusion and allowing unauthorized file writes.

Upgrade filelock to version 4.0.9 or higher.

Affected versions of this package are vulnerable to Race Condition Enabling Link Following via the read-write lock implementation in src/filelock/_read_write.py, where the SQLite lock database is opened using a shared, predictable name in a directory where another user can manipulate names. An attacker who controls names in the lock database's directory can redirect the lock file path to an arbitrary location, allowing them to corrupt or overwrite files with the victim's privileges.

Note: This is only exploitable when another user has write access to the directory containing the lock database.

Upgrade filelock to version 4.2.1 or higher.