GHSA-J8F7-RJXC-MR56
Vulnerability from github – Published: 2026-10-28 21:08 – Updated: 2026-10-28 21:08Summary
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.8"
},
"package": {
"ecosystem": "PyPI",
"name": "filelock"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.4"
},
{
"fixed": "4.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-112936"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-28T21:08:30Z",
"nvd_published_at": "2026-10-20T15:17:16Z",
"severity": "MODERATE"
},
"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\u0027s directory, such as `/tmp` or a shared cache, can plant a symlink at the lock path and make the victim\u0027s process create, lock, or write the file it points to, or break mutual exclusion between the victim\u0027s 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\u0027s 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 `\u003cpath\u003e.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 -\u003e /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\u0027s 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.",
"id": "GHSA-j8f7-rjxc-mr56",
"modified": "2026-10-28T21:08:30Z",
"published": "2026-10-28T21:08:30Z",
"references": [
{
"type": "WEB",
"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": "WEB",
"url": "https://github.com/tox-dev/filelock/commit/4d45e83caf7e31f9a12fb44526bdc07f70114f04"
},
{
"type": "PACKAGE",
"url": "https://github.com/tox-dev/filelock"
},
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/releases/tag/4.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "filelock: ReadWriteLock follows a symlink at the lock path into SQLite"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.