CVE-2026-112940
7.1HighPublished 20 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- Local
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
- Impact
- High impact on integrity, availability
- Weakness
- CWE-363
Impact
A local attacker can overwrite or delete arbitrary files, and potentially inject chosen content into files if an adjacent hot journal is writable. To exploit this, the attacker needs local system access with rename permissions in a non-sticky directory containing the lock files.
Root cause
ReadWriteLock allows SQLite to reopen database and side files by name instead of file descriptor, exposing them to symlink or rename race conditions on POSIX systems.
Affected systems
filelock 3.20.4 through versions prior to 4.2.1 on POSIX systems
CVSS v3.1 · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Fix & remediation
Upgrade filelock to version 4.2.1 or newer. If you cannot patch immediately, ensure lock files reside strictly in protected directories with the sticky bit enabled or where untrusted local users lack write/rename permissions.
$ pip install --upgrade 'filelock>=4.2.1'AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
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.