{"id":"CVE-2026-112936","aliases":["GHSA-j8f7-rjxc-mr56"],"url":"https://o3.security/vulnerability/CVE-2026-112936","summary":"filelock: ReadWriteLock follows a symlink at the lock path into SQLite","details":"### Summary\n\n`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.\n\n### Details\n\n`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/`.\n\n### Proof of concept\n\nOn Linux, with the victim and attacker as different users and `/shared` mode 1777 with `fs.protected_symlinks=1`:\n\n1. The attacker runs `ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db`.\n2. The victim constructs `ReadWriteLock(\"/shared/app.rwlock.db\")`. A plain `os.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.\n3. 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.\n\nThe same behavior reproduces on macOS, on Windows 11, and through `AsyncReadWriteLock`.\n\n### Impact\n\nA 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.\n\n### Workarounds\n\nKeep `ReadWriteLock` paths in directories that only trusted users can write.","published":"2026-10-20T14:34:47.210Z","modified":"2026-10-28T02:59:25.893328148Z","cvss":{"score":6.1,"severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L"},"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"PyPI","name":"filelock","fixedVersion":"4.0.9"}],"fix":{"url":"https://github.com/tox-dev/filelock/commit/4d45e83caf7e31f9a12fb44526bdc07f70114f04","label":"tox-dev/filelock@4d45e83"},"references":[{"type":"WEB","url":"https://github.com/tox-dev/filelock/releases/tag/4.0.9"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/112xxx/CVE-2026-112936.json"},{"type":"ADVISORY","url":"https://github.com/tox-dev/filelock/security/advisories/GHSA-j8f7-rjxc-mr56"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-112936"},{"type":"FIX","url":"https://github.com/tox-dev/filelock/commit/4d45e83caf7e31f9a12fb44526bdc07f70114f04"},{"type":"PACKAGE","url":"https://github.com/tox-dev/filelock"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-10-28T02:59:25.893328148Z"}}