filelock 是一个跨平台的 Python 文件锁工具。在 4.1.0 至 4.2.1 版本中,SoftFileLock 存在一个漏洞:当攻击者预先创建并删除自己的标记文件,且至少有两个锁使用者进程处于等待状态,同时文件的修改时间(无论是粗略匹配还是精确匹配)保留了旧观测结果时,若一个诚实的竞争者在被复用的 inode 上创建新的标记,该新标记可能被误判为陈旧标记而被删除。此问题已在 4.2.1 版本中修复。
Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.
| # | POC Description | Source Link | Shenlong Link |
|---|
No public POC found.
Login to generate AI POC| CVE-2026-112940 | 7.1 HIGH | filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or |
| CVE-2026-112911 | 6.3 MEDIUM | filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user |
| CVE-2026-112909 | 6.1 MEDIUM | filelock: UnixFileLock truncates and chmods any regular file another user renames or hard- |
| CVE-2026-112934 | 6.1 MEDIUM | filelock: SoftReadWriteLock holder refresh writes through a hard link and hangs on a named |
| CVE-2026-112936 | 6.1 MEDIUM | filelock: ReadWriteLock follows a symlink at the lock path into SQLite |
| CVE-2026-112937 | 6.1 MEDIUM | filelock: ReadWriteLock on the hard-link route deletes any directory another user renames |
| CVE-2026-112915 | 5.5 MEDIUM | filelock ReadWriteLock: a crafted lock database makes every acquire stall or hang regardle |
| CVE-2026-112914 | 5.3 MEDIUM | filelock: SoftFileLock stale-break restore follows a swapped-in symbolic link and hard-lin |
| CVE-2026-112935 | 4.7 MEDIUM | filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number |
| CVE-2026-112939 | 4.7 MEDIUM | filelock: SoftFileLock removes a live holder's marker when another user forges the PID in |
| CVE-2026-112941 | 3.3 LOW | filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and wri |
| CVE-2026-112912 | 2.5 LOW | filelock: Symlink swap during SoftFileLock's writability check leaks whether a path exists |
No comments yet