GHSA-j8f7-rjxc-mr56: SQL Injection
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(lockfile).resolve(), which follows a final symlink, and every connection opens that path through sqlite3.connect() with no ONOFOLLOW or regular-file check. SQLite's own VFS also resolves the final symlink in user space, so fs.protectedsymlinks 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 ONOFOLLOW, 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.protectedsymlinks=1:
1. The attacker runs ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db. 2. The victim constructs ReadWriteLock("/shared/app.rwlock.db"). A plain os.open(..., ONOFOLLOW) 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. 3. 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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/filelockto a version that resolves this vulnerability.Fixed in 4.0.9 - Compensating control
Keep ReadWriteLock paths in directories that only trusted users can write, rather than in shared or attacker-writable directories such as /tmp.
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Applications using ReadWriteLock or AsyncReadWriteLock are exposed when their lock file is placed in a directory where another local user can create filenames, such as /tmp or a shared cache directory. FileLock and SoftReadWriteLock do not follow a final symlink in the same way.
What does an attacker need to exploit this?
A local attacker needs the ability to create a symlink at the expected lock-file path before the victim process opens it. The symlink can point to a file the victim can create, lock, or write.
Do sticky directories or fs.protected_symlinks prevent exploitation?
No. The lock path is resolved in user space before SQLite opens it, so the kernel does not receive a symlink to reject; the sticky bit and fs.protected_symlinks do not help.
What can be done if updating is not immediately possible?
Avoid using ReadWriteLock and AsyncReadWriteLock with lock paths in directories writable by untrusted local users. Where suitable, use FileLock, which opens with O_NOFOLLOW, or SoftReadWriteLock, which coordinates through a <path>.rw directory.
How can I assess whether a running configuration is at risk?
Identify uses of ReadWriteLock or AsyncReadWriteLock and check whether their lock-file directories permit another local user to create entries. A symlink already present at the lock-file path can redirect SQLite operations to its target and may also disrupt mutual exclusion between the victim's processes.