CVE-2026-112941Low· 3.3▾ Sunlitfilelock 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,…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 18.2 · 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, 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.
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-112934Medium· 6.1filelock: SoftReadWriteLock holder refresh writes through a hard link and hangs on a named pipe that another local user renames over its record
CVE-2026-112911Medium· 6.3filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing mutual exclusion
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-112937Medium· 6.1filelock: ReadWriteLock on the hard-link route deletes any directory another user renames onto its .filelock-* link directory name
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