CVE-2026-112936 is a medium-severity (CVSS 6.1) CWE-59 vulnerability in filelock. A fix is available for filelock — see the affected versions and patch details below.
filelock: ReadWriteLock follows a symlink at the lock path into SQLite
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-112936.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-112936 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
filelockReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
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.
Workarounds
Keep ReadWriteLock paths in directories that only trusted users can write.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | filelock | ≥ 3.20.4&&< 4.0.9 | 4.0.9pip install --upgrade 'filelock==4.0.9' |
Affected Products
filelocktox-devDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for filelock, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update filelock to 4.0.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-112936 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is CVE-2026-112936 in your dependencies?
Find it across PyPI, including transitive dependencies.