Summary
filelock: ReadWriteLock follows a symlink at the lock path into SQLite
ReadWriteLock and AsyncReadWriteLock resolve the lock path with pathlib.Path.resolve() and pass it to sqlite3.connect() without refusing a symlink. A local user who can create names in the lock's directory, such as /tmp or a shared cache, can plant a symlink at the lock path and make the victim's process create, lock, or write the file it points to, or break mutual exclusion between the victim's own processes.
Details
ReadWriteLock.__init__ stores pathlib.Path(lock_file).resolve(), which follows a final symlink, and every connection opens that path through sqlite3.connect() with no O_NOFOLLOW or regular-file check. SQLite's own VFS also resolves the final symlink in user space, so fs.protected_symlinks and the sticky bit do not help: the kernel never sees a symlink to refuse. The other lock classes do not follow a final symlink: FileLock opens with O_NOFOLLOW, and SoftReadWriteLock coordinates through <path>.rw/.
Proof of concept
On Linux, with the victim and attacker as different users and /shared mode 1777 with fs.protected_symlinks=1:
- The attacker runs
ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db. - The victim constructs
ReadWriteLock("/shared/app.rwlock.db"). A plainos.open(..., O_NOFOLLOW)on the same path fails, but the lock creates/home/victim/private/pwned.flag, owned by the victim, inside a directory the attacker cannot write. - With
/shared/cache.rwlock.db -> /shared/a.db, one victim process holds the write lock. The attacker repoints the link to/shared/b.db, and a second victim process acquires the write lock while the first still holds it.
The same behavior reproduces on macOS, on Windows 11, and through AsyncReadWriteLock.
Workarounds
Keep ReadWriteLock paths in directories that only trusted users can write.
Impact
A local attacker with write access to the lock directory can make the victim create empty files it owns at paths the attacker cannot write, make the victim hold a SQLite lock on another application's database so that application gets database is locked, and give two victim processes the write lock at once, letting them corrupt the resource the lock protects.
CVE-2026-112936 has a CVSS score of 6.1 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.9); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-112936? CVE-2026-112936 is a medium-severity security vulnerability in filelock (pip), affecting versions >= 3.20.4, <= 4.0.8. It is fixed in 4.0.9.
- How severe is CVE-2026-112936? CVE-2026-112936 has a CVSS score of 6.1 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of filelock are affected by CVE-2026-112936? filelock (pip) versions >= 3.20.4, <= 4.0.8 is affected.
- Is there a fix for CVE-2026-112936? Yes. CVE-2026-112936 is fixed in 4.0.9. Upgrade to this version or later.
- Is CVE-2026-112936 exploitable, and should I be worried? Whether CVE-2026-112936 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-112936 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-112936? Upgrade
filelockto 4.0.9 or later.