Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local account on shared host
-
DeliverySwap symlink at SoftFileLock path
-
ExploitRace os.access writability check
-
ExecutionObserve lock acquisition result
-
ImpactInfer target path existence/writability
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
|
| Exploitation Conditions | Exploitation requires all of the following: a local account on the same host as the victim (AV:L, PR:L); the victim using filelock's SoftFileLock between 3.32.6 and 4.2.1; a lock-path node whose owner-write bit is unset, triggering the conditional os.access() writability check; a platform and directory configuration in which os.access follows symbolic links; and the attacker's ability to swap a symlink in at the lock path and win the TOCTOU race (AC:H). Limiting factors: it is local-only (not remotely reachable), yields only an existence/writability inference about an attacker-chosen path rather than content disclosure or write access, and is neutralized on platforms/configurations that do not follow the swapped link. |
| Impact | This is a genuinely low-priority issue, and the available signals agree rather than conflict. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, base 2.5) describes a local, high-complexity, authenticated flaw with only limited confidentiality impact and no integrity or availability effect - consistent with the description, which frames the outcome as an information-inference primitive (learning whether a chosen path exists and is writable), not code execution or data theft. No EPSS score, KEV listing, or POC was provided in the intelligence; by rule this is 'no public exploit identified at time of analysis,' and the symlink TOCTOU nature plus AC:H means reliable exploitation requires winning a race on a specific platform/directory configuration. There is no conflict among signals here: low CVSS, no exploitation evidence, and a narrow local info-leak primitive all point the same direction. The main caveat is reach: filelock is an extremely common transitive Python dependency, so while per-instance risk is low, the affected code is present in a very large number of environments - patch during routine dependency maintenance rather than as an emergency. |
| Exploit ScenarioDerived | A local attacker with their own account on a shared multi-user host swaps a symbolic link in at a SoftFileLock lock path for a file whose owner-write bit is unset, timing it against a victim process's os.access() writability check. By observing whether the victim's lock acquisition succeeds, the attacker infers whether an attacker-chosen target path exists and is writable by the victim. No public exploit code was identified, and the AC:H race plus required local account make opportunistic exploitation unlikely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 20, 2026
Local information disclosure in the Python filelock library allows a low-privileged local user to infer whether an attacker-chosen path exists and is writable by racing a symbolic link into SoftFileLock's writability check. SoftFileLock versions 3.32.6 through 4.2.0 follow a symlink swapped in at the lock path when the lock node lacks its owner-write bit, so the observable acquisition result leaks the target path's existence and write status (CWE-59, CVSS 2.5). Exploitation requires local access, a specific permission and symlink-following configuration, and winning a TOCTOU race; no public exploit has been identified at time of analysis, and the issue is fixed in 4.2.1.
RemediationAI
Vendor-released patch: 4.2.1 - upgrade with pip install --upgrade 'filelock>=4.2.1' (or pin filelock==4.2.1) and rebuild any bundled/vendored copies, then confirm the installed version via importlib.metadata. If upgrading immediately is not possible, switch lock users from SoftFileLock to UnixFileLock/WindowsFileLock (the hard locks open with O_NOFOLLOW and do not follow a swapped symlink, though they cannot defend against hard links or files renamed onto the lock path), or ensure the lock-path node retains its owner-write bit so the conditional os.access() probe is never taken; note that this second workaround only removes the vulnerable code path for that node and depends on directory permissions the victim may not control. Restricting the directory containing lock files to trusted accounts removes the attacker's ability to swap the symlink in the first place, at the cost of preventing legitimate multi-user sharing of that directory. Upstream details and confirmation are in GHSA-9j6q-wvj5-jgjg, PR 835, and the 4.2.1 release notes; there is no evidence of active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, so prioritization can follow routine dependency-update cadence.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
filelock is a platform-independent Python file locking library used by packaging tools, test runners, and applications to serialize access to shared files. SoftFileLock implements locking with marker files and, in the affected range, performs a conditional os.access() writability probe on a lock-path node whose owner-write bit is unset; on platforms and directory configurations where os.access follows symbolic links, an attacker who swaps a symlink into that path causes the probe to resolve to an arbitrary attacker-chosen target. The resulting acquire success or failure is observable, turning the check into a one-bit oracle for whether the target path exists and is writable - a classic link-following (CWE-59) TOCTOU weakness, complicated by the race required (AC:H). The upstream fix in PR 835 and commit e1e825b changes SoftFileLock so its writability check no longer follows a symlink swapped in at the lock path; the same changeset also fixes several unrelated lock-file opening behaviors, including UnixFileLock no longer truncating or chmod'ing a file it did not create, since O_NOFOLLOW alone cannot distinguish a hard link or a renamed file from a genuine lock file.
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:H/PR:L/UI:N/S:U/C:L/I:N/A:N
Local shared-host race (AV:L, AC:H) by an authenticated local user (PR:L) leaking only path existence/writability inference (C:L), with no integrity or availability impact.
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.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
Threat Intelligence Overview
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
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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
Symlink redirection in filelock's ReadWriteLock and AsyncReadWriteLock (versions 3.20.4 through 4.0.8) allows a local us
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
Python's filelock library, versions 4.1.0 through 4.2.0, allows a local attacker who is already contending on the same l
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
EUVD-2026-105019
GHSA-9j6q-wvj5-jgjg
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB