Skip to main content

filelock CVE-2026-112914

| EUVDEUVD-2026-105020 MEDIUM
Race Condition Enabling Link Following (CWE-363)
2026-10-20 GitHub_M
5.3
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain local account on host sharing lock directory
  2. Delivery
    Gain rename access in non-sticky lock directory
  3. Exploit
    Win race during stale-marker restore
  4. Execution
    Swap marker name for attacker symlink
  5. Persist
    Victim hard-links its file into lock directory
  6. Impact
    Read victim file and break lock exclusivity

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Race condition in multi-threaded env
Exploitation Conditions

Requires all of the following to coincide: the application uses SoftFileLock, MarkerSoftFileLock, or SoftFileLease from filelock 4.1.0-4.2.0; the lock directory resides on a directory WITHOUT the sticky bit and is shared with other local users; the attacker holds rename/write access within that directory; the target OS/runtime follows symbolic links during marker restore and the hard-link target is on the same filesystem; and the attacker wins the brief TOCTOU window while a stale marker is moved aside and restored by name. Limiting factors that reduce realistic risk: local access and a second unprivileged account are mandatory (not remotely reachable), the race is high-complexity and timing-dependent, and the shared non-sticky-bit lock directory is a non-default/hardening-dependent deployment - sticky-bit directories (e.g. default /tmp) and platforms without symlink-following behavior are not exploitable.

Impact

All signals point to a genuinely low operational priority despite the MEDIUM 5.3 CVSS. The vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N is local-only (AV:L) - there is no remote exploitation path - and carries High attack complexity (AC:H) because success depends on winning a narrow TOCTOU race during a stale-marker break plus several environmental preconditions. PR:L means an authenticated local user is required. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so this is 'no public exploit identified at time of analysis' rather than active exploitation. One notable conflict: the input Tags label this 'Information Disclosure' while the CVSS vector rates integrity as the dominant impact (C:L/I:H/A:N) - the described effect (coercing the lock holder into hard-linking one of its own files into an attacker-accessible lock directory) blends a limited confidentiality exposure with a lock-mutual-exclusion/integrity break, so treat the single 'Information Disclosure' label as incomplete, not authoritative. Net: a real but low-urgency local hardening issue, not a widespread-exploitation emergency.

Exploit ScenarioDerived

On a multi-user host where filelock's SoftFileLock places its lock in a shared directory without the sticky bit, a local attacker with rename access watches for a stale-marker break and, in the gap between the holder moving its marker aside and restoring it by name, swaps in a symbolic link. On a runtime that follows the link to a same-filesystem target, the legitimate lock process is tricked into hard-linking one of its own files into the lock directory, exposing it to the attacker and corrupting lock state. No public proof-of-concept was identified at time of analysis.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 20, 2026

A local, low-privileged user (PR:L) who can rename files in a shared, non-sticky-bit lock directory can abuse the Python filelock package's SoftFileLock, MarkerSoftFileLock, or SoftFileLease marker-restore path in versions 4.1.0 through 4.2.0 to make the lock owner hard-link one of its own files into the lock directory, exposing file contents and causing limited integrity impact. The race is high-complexity and timing-dependent, requires a second local account plus a non-default shared-directory configuration, and no public exploit code has been identified at the time of analysis. All signals point to a genuinely low operational priority despite the MEDIUM 5.3 CVSS.

RemediationAI

Vendor-released patch: filelock 4.2.1 (GitHub release tag 4.2.1, commit 740ff666b62a88496c8d7394e4e6230605e4d62b, PR 843; advisory GHSA-crv4-6mhj-j5jh). If upgrading is not immediately possible, avoid SoftFileLock, MarkerSoftFileLock, and SoftFileLease in shared lock directories and use an OS-level lock such as FileLock instead, accepting that flock semantics may be unreliable on some NFS/SMB mounts. Harden the lock directory so it is not shared with untrusted local users or is sticky-bit protected, which removes the attacker's rename ability; note that sticky-bit directories such as the default /tmp are not exploitable per the advisory. Patching is the primary fix; directory hardening is a compensating control, not a substitute.

Affected VersionsENISA

filelock 4.1.0, < 4.2.1

Affected Packages

euvd filelock fix: 4.2.1

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 implements cross-platform advisory locking; SoftFileLock uses a marker file rather than an OS-level flock, and its stale-lock recovery renames an apparently stale marker to a private <lock>.break.<pid>.<token> name, verifies it, and restores it by name. Because restore resolves the path instead of operating only on a verified file descriptor, a second local user with rename access in a non-sticky lock directory can replace the break name with a symbolic link; if the runtime follows that link and the target is on the same filesystem, the lock-owning process hard-links a file it can access into the lock directory. The assigned CWE-363 weakness class fits this dangerous name-based file operation in a race-prone path, and the assessed vector requires local access (AV:L), high attack complexity (AC:H), and low privileges (PR:L). The impacted package is tox-dev/filelock on PyPI, represented by the wildcard-version CPE cpe:2.3:a:tox-dev:filelock:*:*:*:*:*:*:*:*; the 4.2.1 fix reduces the window using atomic name exchange (renameat2 on Linux, renamex_np on macOS) and changes fallback behavior on platforms without such an exchange, confirming that non-atomic, name-based restore of a moved-aside marker is the root cause.

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

Vendor (GitHub_M) PRIMARY 5.3 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N
vuln.today AI 3.6 LOW

Local user needs only rename access (PR:L) and must win a narrow symlink-following race under non-default shared-directory conditions (AC:H); impact is limited file exposure plus lock-integrity loss, so C:L/I:L.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch available
Oct 20, 2026 - 16:02 EUVD
CVE Published
Oct 20, 2026 - 14:26 cve.org
MEDIUM 5.3

DescriptionCVE.org

filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.

Threat Intelligence Overview

EPSS Score
0.1%
Top 100% exploitable
Prevalence
High
popular Python file-locking library, transitive dependency of virtualenv and tox
Data Quality
5 sources
Confidence: Medium

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.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
High

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

CVE-2026-112940 HIGH
7.1 Oct 20

filelock's SQLite-backed ReadWriteLock (versions 3.20.4 through 4.2.0) can be tricked into overwriting or unlinking the

CVE-2026-112911 MEDIUM
6.3 Oct 20

The Python `filelock` package's opt-in `StrictSoftFileLock` (3.30.0 through <4.2.1) and `SoftReadWriteLock` (4.0.0 throu

CVE-2026-112936 MEDIUM
6.1 Oct 20

Symlink redirection in filelock's ReadWriteLock and AsyncReadWriteLock (versions 3.20.4 through 4.0.8) allows a local us

CVE-2026-112934 MEDIUM
6.1 Oct 20

SoftReadWriteLock in the Python filelock package (4.0.0 through 4.2.0) refreshes holder records by pathname without veri

CVE-2026-112909 MEDIUM
6.1 Oct 20

Python filelock's UnixFileLock truncates a regular file that a second local user has renamed onto the lock path (or hard

CVE-2026-112937 MEDIUM
6.1 Oct 20

A time-of-check-to-time-of-use (TOCTOU) flaw in the Python filelock library's ReadWriteLock, present from 4.1.0 through

CVE-2026-112915 MEDIUM
5.5 Oct 20

Local denial of service in the Python `filelock` package (versions 3.20.4 through 4.2.0) allows a second local account t

CVE-2026-22701 MEDIUM
5.3 Jan 10

Python's filelock SoftFileLock implementation prior to version 3.20.3 contains a TOCTOU race condition that allows local

CVE-2026-112939 MEDIUM
4.7 Oct 20

SoftFileLock, MarkerSoftFileLock, and SoftFileLease in the Python filelock package from 3.22.0 through 4.2.0 can be tric

CVE-2026-112935 MEDIUM
4.7 Oct 20

The Python filelock library (versions 3.22.0 through 4.2.0) can admit two simultaneous lock holders because its SoftFile

CVE-2026-112906 MEDIUM
4.7 Oct 20

Python's filelock library, versions 4.1.0 through 4.2.0, allows a local attacker who is already contending on the same l

CVE-2026-112941 LOW
3.3 Oct 20

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-

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy