CVE-2026-112936: 
Python vulnerability analysis and mitigation

CVE-2026-112936 is a symlink-following vulnerability in the filelock Python library affecting ReadWriteLock and AsyncReadWriteLock classes. Introduced in version 3.20.4, these classes resolve the lock path using pathlib.Path.resolve() and pass it to sqlite3.connect() without rejecting a final symbolic link, enabling a local attacker to redirect database creation and locking operations or break mutual exclusion between victim processes. All versions from 3.20.4 through 4.0.8 are affected; the issue is fixed in version 4.0.9. It carries a CVSS v3.1 base score of 6.1 (Medium) (GitHub Advisory, Red Hat).

The root cause is improper link resolution before file access (CWE-59) combined with exposure of a resource to the wrong sphere (CWE-668). ReadWriteLock.__init__ stores pathlib.Path(lock_file).resolve(), which follows a final symbolic link, and every subsequent connection opens that resolved path via sqlite3.connect() with no O_NOFOLLOW flag or regular-file check. SQLite's own VFS also resolves the final symlink in user space, meaning kernel-level protections such as fs.protected_symlinks and the sticky bit are bypassed entirely — the kernel never sees a symlink to refuse. By contrast, FileLock opens with O_NOFOLLOW and SoftReadWriteLock coordinates through a .rw/ directory, so only the ReadWriteLock/AsyncReadWriteLock classes are vulnerable. The fix (commit 4d45e83) resolves only the parent directory, opens the database file descriptor with O_NOFOLLOW | O_NONBLOCK, performs a regular-file check via fstat, and connects SQLite through /proc/self/fd or /dev/fd to keep the validated inode pinned for the connection's lifetime (GitHub Advisory, Fix Commit).

A local attacker with write access to the lock directory can cause the victim process to create empty files it owns at arbitrary paths the attacker cannot directly write to, hold a SQLite lock on another application's database (causing "database is locked" errors for that application), and allow two victim processes to simultaneously acquire the write lock — potentially corrupting the shared resource the lock is meant to protect. There is no confidentiality impact, but integrity is rated High and availability Low, reflecting the ability to tamper with file system state and disrupt locking semantics (GitHub Advisory).

A proof-of-concept with step-by-step reproduction instructions is publicly available in the GitHub Security Advisory (GitHub Advisory). Exploitation requires a local foothold with write access to the lock directory (e.g., /tmp or a shared cache) and is not automatable, as it depends on timing and the victim constructing a ReadWriteLock on the planted path. The EPSS score is 0.0, and there is no evidence of in-the-wild exploitation or inclusion in the CISA KEV catalog at this time. No threat actor attribution has been reported (Feedly).

1. Reconnaissance: Identify a target system running a Python application that uses filelock versions 3.20.4–4.0.8 with ReadWriteLock or AsyncReadWriteLock, and confirm the lock directory (e.g., /tmp, /shared, or a shared cache path) is world-writable or writable by the attacker's local account.
2. Plant the symlink: As the attacker, create a symbolic link at the expected lock path pointing to a target file the attacker wants to create or corrupt: ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db.
3. Trigger victim lock construction: Wait for (or induce) the victim process to construct ReadWriteLock("/shared/app.rwlock.db"). The library calls pathlib.Path.resolve(), follows the symlink, and passes the resolved target path to sqlite3.connect(), causing the victim process to create /home/victim/private/pwned.flag owned by the victim.
4. Break mutual exclusion (optional): With /shared/cache.rwlock.db -> /shared/a.db, wait until one victim process holds the write lock, then atomically repoint the symlink to /shared/b.db (ln -sfn /shared/b.db /shared/cache.rwlock.db). A second victim process now acquires the write lock on a different database, allowing both to hold the write lock simultaneously and potentially corrupt the protected resource.
5. Cause cross-application lock contention (optional): Point the symlink at another application's SQLite database so the victim process holds a SQLite lock on it, causing that application to receive "database is locked" errors (GitHub Advisory).

• File System: Unexpected empty files appearing in directories that the victim process's user account owns but the attacker's account cannot directly write to (e.g., /home/victim/private/); symbolic links appearing in shared lock directories (e.g., /tmp, /var/cache) pointing to unrelated files or databases.
• Logs: Application logs from other software reporting "database is locked" SQLite errors without a clear cause; Python application logs showing OSError or PermissionError referencing symlink or non-regular file messages after upgrading to filelock 4.0.9 (indicating prior exploitation attempts).
• Process: Multiple victim processes simultaneously holding write locks on the same logical resource, observable via SQLite lock inspection tools or application-level corruption reports.
• File System: Symlinks in world-writable directories (sticky-bit directories like /tmp) whose targets are outside the expected lock directory, detectable via find /tmp -type l -ls or equivalent (GitHub Advisory).

Upgrade filelock to version 4.0.9 or later, which refuses symlinks at the database path using O_NOFOLLOW and a regular-file check, and connects SQLite through a pinned file descriptor to prevent mid-connection symlink swapping (filelock Release, Fix Commit). As a workaround where immediate patching is not possible, restrict ReadWriteLock paths to directories where only trusted users can create names — avoid world-writable directories such as /tmp or shared caches for lock files (GitHub Advisory).

The vulnerability was reported by researcher Kwstubbs and the advisory was published by maintainer gaborbernat on October 17, 2026. Red Hat tracked the issue via Bugzilla (Bug #2556225) and published a CVE advisory, indicating downstream distribution awareness. No significant broader media coverage or notable social media discussion has been identified beyond the standard vulnerability database entries.