Hi,
The following vulnerabilities were published for python-filelock.
CVE-2026-112906[0]:
| filelock is a platform-independent file lock for Python. From 4.1.0
| until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale
| observation when an attacker pre-dates and removes its own marker,
| at least two lock-user processes are waiting, coarse or matching
| modification times preserve the observation, and an honest contender
| creates a fresh marker on the reused inode, causing that live marker
| to be removed as stale. This issue is fixed in version 4.2.1.
CVE-2026-112909[1]:
| filelock is a platform-independent file lock for Python. Prior to
| 4.2.1, UnixFileLock can truncate a regular file renamed onto the
| lock path when another local user has actual rename permission, or
| hard-linked there under a permissive hard-link policy; when an
| explicit mode is requested, affected versions from 3.10.2 can also
| change that file's mode. This issue is fixed in version 4.2.1.
CVE-2026-112911[2]:
| filelock is a platform-independent file lock for Python. From 3.30.0
| until 4.2.1, StrictSoftFileLock versions from 3.30.0 and
| SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory
| created first by another local user in a shared parent directory,
| allowing that user to alter protocol state and admit concurrent
| holders. This issue is fixed in version 4.2.1.
CVE-2026-112912[3]:
| filelock is a platform-independent file lock for Python. From 3.32.6
| until 4.2.1, SoftFileLock can follow a swapped symbolic link during
| the conditional os.access writability check for a node without its
| owner-write bit, allowing another local user on a platform and
| directory configuration that follows the link to infer whether a
| chosen path exists and is writable from the observable acquisition
| result. This issue is fixed in version 4.2.1.
CVE-2026-112914[4]:
| filelock is a platform-independent file lock for Python. From 4.1.0
| until 4.2.1, SoftFileLock can restore a stale marker by name after
| moving it aside, allowing another local user with rename access in a
| non-sticky lock directory to swap in a symbolic link and, on a
| runtime that follows the link and a same-filesystem target, make the
| lock user hard-link one of its files into the lock directory. This
| issue is fixed in version 4.2.1.
CVE-2026-112915[5]:
| filelock is a platform-independent file lock for Python. From 3.20.4
| until 4.2.1, ReadWriteLock can open a crafted SQLite lock database
| without bounding schema and query work, allowing another local user
| who can replace the database to make acquisition stall or hang;
| versions from 3.20.4 expose this on initial per-instance opening,
| and versions from 3.30.0 repeat the exposure on every acquisition.
| This issue is fixed in version 4.2.1.
CVE-2026-112934[6]:
| 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.
CVE-2026-112935[7]:
| filelock is a platform-independent file lock for Python. From 3.22.0
| until 4.2.1, SoftFileLock can break a stale marker after an attacker
| frees its own marker following the stale read, an honest contender
| creates a live successor on the reused inode, and the successor's
| modification time is not newer than the saved observation, causing
| the live marker to be removed and two holders to be admitted. This
| issue is fixed in version 4.2.1.
CVE-2026-112937[8]:
| filelock is a platform-independent file lock for Python. From 4.1.0
| until 4.2.1, ReadWriteLock can remove a randomized .filelock-*
| private-hard-link directory during cleanup, allowing another local
| user with rename access in a non-sticky parent to observe a live
| name or forge a dead-owner sweep name and rename a sibling directory
| onto it for deletion. This issue is fixed in version 4.2.1.
CVE-2026-112939[9]:
| filelock is a platform-independent file lock for Python. From 3.22.0
| until 4.2.1, SoftFileLock can trust a forged process identifier in a
| marker that an attacker can modify but cannot remove, allowing an
| authorized contender such as another process of the holder's account
| or root to act as a confused deputy, remove the live marker, and
| admit another holder. This issue is fixed in version 4.2.1.
CVE-2026-112940[10]:
| filelock is a platform-independent file lock for Python. From 3.20.4
| until 4.2.1, ReadWriteLock let SQLite reopen the database and side
| files by name; on POSIX systems an attacker with rename access in a
| non-sticky parent can swap those names to cause overwrite or unlink
| operations, while a writable adjacent hot journal is additionally
| required for attacker-chosen content overwrites. This issue is fixed
| in version 4.2.1.
CVE-2026-112941[11]:
| filelock is a platform-independent file lock for Python. From 4.1.0
| until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a
| successful check of the <path>.rw lock tree and resolve its names
| again during later record operations, allowing another local user
| who can replace that tree after the first acquisition to redirect
| lock-record writes into directories writable by the lock user. This
| issue is fixed in version 4.2.1.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-112906
https://www.cve.org/CVERecord?id=CVE-2026-112906
[1] https://security-tracker.debian.org/tracker/CVE-2026-112909
https://www.cve.org/CVERecord?id=CVE-2026-112909
[2] https://security-tracker.debian.org/tracker/CVE-2026-112911
https://www.cve.org/CVERecord?id=CVE-2026-112911
[3] https://security-tracker.debian.org/tracker/CVE-2026-112912
https://www.cve.org/CVERecord?id=CVE-2026-112912
[4] https://security-tracker.debian.org/tracker/CVE-2026-112914
https://www.cve.org/CVERecord?id=CVE-2026-112914
[5] https://security-tracker.debian.org/tracker/CVE-2026-112915
https://www.cve.org/CVERecord?id=CVE-2026-112915
[6] https://security-tracker.debian.org/tracker/CVE-2026-112934
https://www.cve.org/CVERecord?id=CVE-2026-112934
[7] https://security-tracker.debian.org/tracker/CVE-2026-112935
https://www.cve.org/CVERecord?id=CVE-2026-112935
[8] https://security-tracker.debian.org/tracker/CVE-2026-112937
https://www.cve.org/CVERecord?id=CVE-2026-112937
[9] https://security-tracker.debian.org/tracker/CVE-2026-112939
https://www.cve.org/CVERecord?id=CVE-2026-112939
[10] https://security-tracker.debian.org/tracker/CVE-2026-112940
https://www.cve.org/CVERecord?id=CVE-2026-112940
[11] https://security-tracker.debian.org/tracker/CVE-2026-112941
https://www.cve.org/CVERecord?id=CVE-2026-112941
Regards,
Salvatore