EUVD-2026-105026Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local account with write access to shared lock directory
-
DeliveryPlant symlink at expected lock-database path
-
ExploitVictim ReadWriteLock resolves path and passes to SQLite
-
ExecutionSQLite follows link, opens/locks attacker-chosen target
-
ImpactMutual exclusion split, locked resource corrupted
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
|
| Exploitation Conditions | Requires: (1) a local account on the same host as the victim - there is no network vector; (2) the ability to create names (symlink) in a lock directory that is shared with and writable before the victim creates its lock database; (3) the victim must use the newer filelock ReadWriteLock or AsyncReadWriteLock classes (introduced in 3.20.4) on versions 3.20.4 through 4.0.8 - the classic FileLock is not implicated; and (4) the attacker must plant the symlink at the database path before SQLite opens/creates it. Limiting factors: local-only access, dependence on a world-writable or shared lock directory (non-default for many deployments), and reliance on a recently added feature, all of which narrow realistic exposure well below the raw score. |
| Impact | This is a genuine but moderate, locally-scoped privilege/integrity issue rather than a top-priority remote threat. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, base 6.1 MEDIUM) is internally consistent with the description: exploitation requires a local, low-privileged account that can create names in a shared lock directory, with high integrity impact (lock redirection / broken mutual exclusion) and low availability impact, and no confidentiality impact. No EPSS score, CISA KEV entry, POC, or SSVC decision data was supplied; KEV=NO and POC=NO, so this is 'no public exploit identified at time of analysis.' There is one signal conflict to flag: the input Tags include 'Information Disclosure,' but the CVSS vector sets C:N and the description describes integrity/availability effects (redirecting SQLite database creation/locking and splitting mutual exclusion), not data disclosure - verify tag against actual impact; it appears mislabeled. The local-only attack vector and the requirement of a shared writable lock directory meaningfully limit real-world exploitability despite the HIGH integrity sub-score. |
| Exploit ScenarioDerived | On a multi-user host where applications share a common lock directory, a local low-privileged user pre-creates a symlink at the expected lock-database name pointing to another file. When a victim process using filelock's ReadWriteLock/AsyncReadWriteLock (3.20.4-4.0.8) initializes, the resolved path is passed to SQLite, which follows the link and creates/locks the attacker-chosen target, redirecting locking and letting two processes believe they hold exclusive access. No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 20, 2026
Symlink redirection in filelock's ReadWriteLock and AsyncReadWriteLock (versions 3.20.4 through 4.0.8) allows a local user with write access to a shared lock directory to plant a symbolic link at the lock database path, causing SQLite to create, open, or lock a different file than the one the victim intended. The practical effect is integrity loss - mutual exclusion can be split between two targets so two processes believe they hold the same lock, and a lock database can be forced into an attacker-chosen location - with a modest availability impact from the resulting SQLite errors. The attacker must already hold a local account (PR:L, AV:L, unauthenticated network access is not a factor), must be able to create names in the lock directory before the victim initialises its lock, and the victim must actually use the newer ReadWriteLock classes rather than the classic FileLock. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the issue is fixed in filelock 4.0.9.
RemediationAI
Upgrade to filelock 4.0.9 or later - the upstream fix commit 4d45e83caf7e31f9a12fb44526bdc07f70114f04 adds O_NOFOLLOW plus a regular-file check and descriptor-based SQLite connection, and the release is published at https://github.com/tox-dev/filelock/releases/tag/4.0.9; review the advisory at https://github.com/tox-dev/filelock/security/advisories/GHSA-j8f7-rjxc-mr56 and pin/depend on >=4.0.9 in your dependency manifest. Where an immediate upgrade is not possible, the effective compensating control is to remove the attacker's prerequisite rather than to patch the code: ensure the directory holding the ReadWriteLock database is owned by the victim user with mode 0700 (or otherwise not writable by any other principal, including on shared NFS/CI mounts), which eliminates the ability to plant a symlink at all - the trade-off is that lock paths must then be per-user rather than genuinely shared, so cross-user coordination via one lock database is lost. If cross-user locking is genuinely required, avoid ReadWriteLock/AsyncReadWriteLock on 3.20.4-4.0.8 and fall back to the classic FileLock class, which is not implicated by this advisory, or broker the lock through a service that owns the path - both options reduce the rich reader/writer semantics or add an operational dependency. Pre-creating the database file as the victim with restrictive permissions before untrusted users can act narrows the window but is not a reliable substitute for the patch, since the vulnerable code still resolves and reopens the path.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
filelock is a cross-platform advisory/inter-process lock library used across the Python packaging and tooling ecosystem. The ReadWriteLock and AsyncReadWriteLock classes added in 3.20.4 implement reader/writer semantics by storing lock state in a SQLite database file at a caller-supplied path. The root cause is CWE-59 (Improper Link Resolution Before File Access, i.e. link following): the library canonicalised the lock path with Path.resolve(), which follows a final symlink, and then handed that resolved path to sqlite3.connect(). SQLite therefore opened, created, or locked whatever the symlink pointed at, and because resolution happened before the connection, a link planted in a directory where another local user can create entries redirected the lock to an arbitrary file. A second consequence is key aliasing: a symlink path and its target resolve to the same canonical key, so distinct locks can collapse onto one database or, conversely, mutual exclusion can be split between the link and its target. The upstream fix (commit 4d45e83caf7e31f9a12fb44526bdc07f70114f04, released in 4.0.9) stops resolving the final component - only the parent is canonicalised - and opens the database itself with O_RDWR|O_CREAT|O_NOFOLLOW|O_NONBLOCK at mode 0600, rejecting non-regular files (blocking FIFO and device tricks) and then passing the already-validated descriptor to SQLite via /proc/self/fd (Linux) or /dev/fd (macOS/BSD) with journal_mode=MEMORY so no journal name is derived from the synthetic path. On Windows the fix uses a handle opened without delete sharing and rejecting reparse points. The CVSS:3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L reflects a local, low-complexity, low-privilege attack with high integrity and low availability impact and no confidentiality impact.
Know when Filelock gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Attacker needs a local low-privileged account able to create names in a shared lock dir (AV:L, PR:L); symlink planting is reliable (AC:L); impact is lock redirection (I:H, A:L) with no data disclosure (C:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
filelock's SQLite-backed ReadWriteLock (versions 3.20.4 through 4.2.0) can be tricked into overwriting or unlinking the
The Python `filelock` package's opt-in `StrictSoftFileLock` (3.30.0 through <4.2.1) and `SoftReadWriteLock` (4.0.0 throu
SoftReadWriteLock in the Python filelock package (4.0.0 through 4.2.0) refreshes holder records by pathname without veri
Python filelock's UnixFileLock truncates a regular file that a second local user has renamed onto the lock path (or hard
A time-of-check-to-time-of-use (TOCTOU) flaw in the Python filelock library's ReadWriteLock, present from 4.1.0 through
Local denial of service in the Python `filelock` package (versions 3.20.4 through 4.2.0) allows a second local account t
A local, low-privileged user (PR:L) who can rename files in a shared, non-sticky-bit lock directory can abuse the Python
Python's filelock SoftFileLock implementation prior to version 3.20.3 contains a TOCTOU race condition that allows local
SoftFileLock, MarkerSoftFileLock, and SoftFileLease in the Python filelock package from 3.22.0 through 4.2.0 can be tric
The Python filelock library (versions 3.22.0 through 4.2.0) can admit two simultaneous lock holders because its SoftFile
Python's filelock library, versions 4.1.0 through 4.2.0, allows a local attacker who is already contending on the same l
Symlink or junction replacement of the `<path>.rw` lock tree in Python's filelock 4.1.0 through 4.2.0 lets a second, co-
Exploit-DB