CVE-2026-112937Medium· 6.1▾ Sunlitfilelock 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…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 33.6 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
filelock >= 4.1.0, < 4.2.1Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-112915Medium· 5.5filelock ReadWriteLock: a crafted lock database makes every acquire stall or hang regardless of timeout
CVE-2026-112940High· 7.1filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user's process overwrite or unlink its own files
CVE-2026-112935Medium· 4.7filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders
CVE-2026-112941Low· 3.3filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock
CVE-2026-112906Medium· 4.7filelock: SoftFileLock evicts a fresh lock file whose watched age another local user's pre-dated file passed on through inode reuse
CVE-2026-112909Medium· 6.1filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path