filelock: local attacker can plant symlinks/journal files to overwrite or unlink lock user's files via SQLite-backed ReadWriteLock (CVE-2026-112940)
Severity: high · Patch status: patched · Since 2026-10-17 · CVE-2026-112940
The filelock library's SQLite-backed ReadWriteLock and AsyncReadWriteLock pass SQLite a path they do not control: on Linux the lock validates its database via a descriptor and connects through /proc/self/fd/<n, which SQLite reopens by name, following symlinks, and on POSIX it also acts on -journal, -wal and -shm side files. A different local user who can create or rename entries in the lock database's directory (a 0777 or group-writable directory without the sticky bit) can make the lock user's readlock()/writelock() write attacker-chosen bytes into the lock user's files, create or unlink files, admit a reader beside a writer, or kill the holder; in sticky directories a planted -wal file makes every acquire fail. Affected versions 3.20.4–4.2.0; fixed in 4.2.1. No in-the-wild exploitation reported.
What to do
- Upgrade filelock to 4.2.1 or later wherever ReadWriteLock/AsyncReadWriteLock is used
- Audit where lock databases are placed; avoid 0777 or group-writable directories without the sticky bit
- Verify kernel hardening: fs.protected_regular=1/2 and fs.protected_hardlinks=1 on hosts running multi-user workloads
- Check downstream dependencies (filelock has ~58K dependent repos, e.g. tox, virtualenv tooling) for updated requirements
Fixed versions
Sources
All live incidents on Threat Watch
