CVE-2026-112940: 
Python vulnerability analysis and mitigation

CVE-2026-112940 is a TOCTOU race condition and symlink-following vulnerability in the filelock Python library's ReadWriteLock (SQLite-backed) implementation. Affecting versions 3.20.4 through 4.2.0, the flaw allows a local attacker with rename access in a non-sticky parent directory to redirect SQLite file operations — causing arbitrary file overwrites, unlinks, or denial of service — against the lock user's own files. The vulnerability was reported by Anthropic's OSS Scanner on October 15, 2026, and publicly disclosed on October 17–20, 2026. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-363 (Race Condition Enabling Link Following) and CWE-367 (TOCTOU Race Condition). ReadWriteLock opens its SQLite database via a file descriptor and then passes /proc/self/fd/<n> to sqlite3.connect(). SQLite does not reopen the validated inode — instead it calls readlink() on the /proc path, resolves it to a plain filesystem path (which reads as <path> (deleted) after an unlink), and opens that string by name, following symlinks. A local attacker who can create or rename entries in the non-sticky, world-writable or group-writable directory holding the lock database can: (1) plant a symlink at the (deleted) path to redirect SQLite to an arbitrary target file; (2) place a crafted hot rollback journal (-journal) beside a swapped-in database to replay attacker-controlled content into the victim's files; or (3) plant a -wal file to cause denial of service or corrupt locking semantics. The side-file variants (journal, WAL, SHM) require no race condition and succeed deterministically; the redirect variant succeeded in 77 of 77 inotify-triggered attempts in testing (GitHub Advisory, Fix PR #834).

A low-privileged local attacker can overwrite the first page (4096 bytes) of any regular file the lock user can write with attacker-chosen content, unlink arbitrary files the lock user can delete (via crafted super-journal entries), or cause every read_lock()/write_lock() call to raise sqlite3.OperationalError: disk I/O error (denial of service). Additionally, the attacker can corrupt locking semantics by admitting a reader alongside an exclusive writer, or kill the lock holder with a SIGBUS signal by truncating a memory-mapped -shm file. There is no confidentiality impact, but integrity and availability are both rated High. The attack is limited to the lock user's own privilege level and does not escalate beyond it (GitHub Advisory).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at this time. However, Anthropic's OSS Scanner provided a working reproducer that demonstrated reliable exploitation (77/77 redirect attempts, 20/20 WAL re-plant attempts, and deterministic journal-unlink variants requiring no race). The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires a local account on the same host and write/rename access to a non-sticky shared directory containing the lock database (GitHub Advisory, Red Hat CVE).

1. Reconnaissance: Identify a target system running filelock 3.20.4–4.2.0 with a ReadWriteLock database stored in a world-writable or group-writable directory lacking the sticky bit (e.g., a shared cache or build directory with mode 0777).
2. Prepare the redirect: As the attacker, create the lock database file (e.g., cache.lock.db, mode 0666) and a hard link cache.lock.db.keep pointing to the same inode. Create a symlink named cache.lock.db (deleted) pointing to the victim's target file (e.g., /tmp/victim-notes.txt).
3. Plant the hot journal: Write a crafted SQLite rollback journal at <target>-journal (e.g., /tmp/victim-notes.txt-journal) containing a valid journal header and a page record with attacker-chosen content and correct checksum. Set permissions to 0666 so the victim's SQLite can open it.
4. Monitor with inotify: Use inotify_add_watch on cache.lock.db for IN_OPEN events to detect when the victim's ReadWriteLock opens the database.
5. Execute the swap: Upon receiving the IN_OPEN event (victim has opened the file descriptor but not yet called sqlite3.connect()), unlink cache.lock.db and re-link cache.lock.db.keep back to the same name. The victim's /proc/self/fd/<n> now resolves to cache.lock.db (deleted), which follows the planted symlink.
6. Trigger journal replay: The victim's process calls sqlite3.connect('/proc/self/fd/<n>'), SQLite follows the symlink to the target file, finds the hot journal, and replays the attacker's page content into the victim's file — overwriting it with attacker-controlled data at offset 0.
7. Verify: The victim's file (e.g., 0600, owned by victim) now contains the attacker's content despite the attacker having no direct write permission to it. The victim's lock call raises sqlite3.OperationalError: disk I/O error (GitHub Advisory).

• File System: Unexpected -journal, -wal, or -shm files appearing beside a ReadWriteLock database in a shared directory; symlinks named <lockdb> (deleted) in the lock database directory; files owned by a different user than the lock database owner in the same directory; lock database files with mode 0666 (attacker-created) rather than 0600 (filelock default).
• Logs: Repeated sqlite3.OperationalError: disk I/O error exceptions in application logs from read_lock() or write_lock() calls; unexpected SIGBUS crashes in processes using ReadWriteLock; Python tracebacks referencing _do_acquire_inner or _open_lock_database with I/O errors.
• Process: Unexpected inotify_add_watch syscalls on lock database files by a process belonging to a different user; readlink calls on /proc/<pid>/fd/<n> returning paths ending in (deleted); openat calls on symlink targets not matching the expected lock database path (visible in strace output).
• Network: No network indicators — this is a local privilege abuse vulnerability with no network component.

Upgrade filelock to version 4.2.1, which fixes the vulnerability by connecting SQLite only through names no other process can change: in owner-only directories, SQLite uses the database path directly; in shared directories, it uses a hard link inside a randomly named private .filelock-* subdirectory inaccessible to other accounts (filelock 4.2.1 Release, Fix PR #834).

If immediate upgrade is not possible, apply these workarounds:

• Store the ReadWriteLock database in a directory owned exclusively by the locking account (or root) with no group or other write bits (e.g., mode 0700).
• Ensure all ancestor directories of the lock database belong to the locking account or root and are either not world/group-writable or have the sticky bit set (mode 1777).
• On Linux, ensure fs.protected_regular is set to 1 or 2 and fs.protected_hardlinks=1 (distribution defaults on most systems) to limit exploitation in sticky directories.
• Treat any sudden sqlite3.OperationalError: disk I/O error on every lock acquire as a potential indicator of a planted -wal file requiring manual removal by the file owner or root.

The vulnerability was reported privately by Anthropic's OSS Scanner (automated analysis) on October 15, 2026, and the maintainer (gaborbernat) opened a fix PR within hours and published the advisory on October 17, 2026. The advisory notes the finding was classified as "conditional security" — a cross-user effect requiring a specific directory configuration — and the maintainer accepted the mechanism while narrowing the scope to the non-sticky shared directory precondition. Red Hat tracked the issue via Bugzilla (bug #2556219) and published a CVE advisory. No broader media coverage or notable community controversy has been identified at this time (GitHub Advisory, Red Hat CVE).