Answer in brief
CVE-2026-112940 records a High severity (CVSS 7.1) vulnerability in filelock 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. The current sources do not mark it as known exploited. The current feed maps tox-dev/filelock (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps tox-dev/filelock (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| tox-dev/filelockgeneric | >=3.20.4 <4.2.1 | 4.2.1 |
Published upstream
Oct 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 20, 2026
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.
Quoted source text, attributed separately from HOL analysis.