Skip to main content

filelock EUVDEUVD-2026-105015

| CVE-2026-112906 MEDIUM
Use of Multiple Resources with Duplicate Identifier (CWE-694)
2026-10-20 GitHub_M
4.7
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

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

  1. Access
    Run local process contending on shared SoftFileLock
  2. Delivery
    Pre-date and remove own marker
  3. Exploit
    Preserve stale observation via coarse mtime on reused inode
  4. Execution
    Win race during honest contender's exchange
  5. Impact
    Live holder's marker removed, mutual exclusion broken

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V6 - Authentication Use of multiple resources in auth
Exploitation Conditions

Exploitation is confined to filelock's SoftFileLock/MarkerSoftFileLock/SoftFileLease classes (versions 4.1.0 through 4.2.0); the default FileLock using OS-level flock is not affected, so a deployment is only at risk when the soft/marker lock implementation is explicitly used or fallen back to. The attacker must already run a local process contending on the same lock path, and ALL of the following must coincide: the attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the stale observation, and an honest contender creates a fresh marker on the reused inode (ext4's freed-inode reuse is the enabling filesystem behavior). These conjunctive race conditions - plus the lack of any remote vector and no user interaction by the victim beyond normal lock contention - sharply limit realistic exploitation to co-located, timing-controlled scenarios.

Impact

This is a genuinely low-priority issue despite the HIGH integrity impact, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N) describes a local, high-complexity attack requiring an already-present low-privilege process - not a remotely reachable flaw - which caps the base score at 4.7 (Medium). No EPSS score, no CISA KEV listing, and no public exploit code were provided, so by the precision rules this is 'no public exploit identified at time of analysis.' The AC:H rating is strongly justified by the description: successful exploitation requires a narrow race window plus four simultaneous preconditions (attacker pre-dates and removes its own marker, at least two lock-user processes waiting, coarse/matching modification times, and an honest contender landing a fresh marker on the reused inode). The absence of EPSS/KEV/POC combined with AC:H indicates this is a reliability/correctness defect in a concurrency primitive rather than a weaponizable security bug; real-world abuse would require an attacker to already have local code execution contending on the same lock path. One metadata conflict to flag: the input Tags include 'Information Disclosure', but the CVSS vector sets C:N and I:H - the impact is loss of mutual-exclusion integrity (a live holder's lock marker is removed), not disclosure of information; treat the 'Information Disclosure' categorization as incorrect.

Exploit ScenarioDerived

On a shared host, an attacker-controlled process participates in filelock's SoftFileLock contention on the same lock path as a victim process. By pre-dating and then removing its own marker so a stale observation survives on a reused inode, the attacker causes an honest contender's exchange to delete the live holder's marker, so two processes simultaneously believe they hold the lock and corrupt the resource the lock was meant to protect. No public exploit code was provided, and the required race plus multiple preconditions make reliable triggering difficult.

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

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

Alert me

AnalysisAIv1 – Oct 20, 2026

Python's filelock library, versions 4.1.0 through 4.2.0, allows a local attacker who is already contending on the same lock path to trick the SoftFileLock, MarkerSoftFileLock, and SoftFileLease implementations into deleting a legitimate holder's live marker file, silently breaking the mutual exclusion the lock is supposed to guarantee and letting concurrent processes enter a protected critical section together. Exploitation is not trivial: it requires a pre-dated attacker marker that is removed on cue, at least two waiting contenders, coarse or matching modification times that preserve the stale observation, and inode reuse on the filesystem (ext4 is the named enabler) so that an honest contender's fresh marker lands on the recycled inode. The impact is integrity-only with no confidentiality or availability component, the vector is strictly local and high-complexity (CVSS 4.7), no public exploit code was identified at time of analysis, and the flaw is fixed in 4.2.1.

RemediationAI

Upgrade the filelock package to 4.2.1 or later; that release, described in the changelog entry 843.bugfix.rst and shipped under the 4.2.1 tag, adds ctime-based marker identity and atomic marker exchange on Linux and macOS and refuses to displace a live marker elsewhere. Confirm the resolved version in your environment with pip show filelock or a lockfile pin, and note that transitively vendored copies inside application wheels will not be fixed by upgrading the top-level dependency. Where an immediate upgrade is not possible, the highest-value compensating control is to stop using the soft lock path: construct FileLock instead of SoftFileLock/MarkerSoftFileLock/SoftFileLease, and set fallback_to_soft=False so the library fails loudly rather than silently degrading to marker files on filesystems without OS-level locking; the trade-off is that workloads on NFS or SMB mounts that genuinely cannot use flock will now error out instead of proceeding. Second, restrict write access to the directory holding lock files so that only mutually trusted processes can create or remove markers there, since the attack requires an attacker able to pre-create, back-date, and delete a marker on the same path; this does not help in multi-tenant or shared-temp-directory layouts, where per-service lock directories with restrictive permissions are required. Third, on platforms without an atomic exchange the fixed version deliberately blocks on a live marker until timeout or break_lock() rather than evicting it, so raising the timeout and avoiding aggressive break_lock() calls reduces the residual contention window; the side effect is longer stalls when a holder genuinely dies.

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 offers two families of locking. The default FileLock relies on OS-level primitives such as flock, and is explicitly unaffected. The soft variants (SoftFileLock, MarkerSoftFileLock, SoftFileLease) emulate locking in userspace by creating a marker file at the lock path and writing an ownership record into it; contenders decide whether a marker is stale by reading its modification time, inode number, and in earlier releases change-adjacent metadata, then break the lock by renaming or removing the marker. That design is a CWE-694 (Use of Incorrectly-Resolved Name or Reference) problem: the library identifies a marker by a name-and-metadata tuple that an unprivileged owner can influence, so a stale observation can be replayed against a different file that now occupies the same name or inode. The reported scenario chains this: the attacker pre-dates its own marker and removes it, ext4 hands the freed inode number to the next marker, coarse timestamp granularity means the reused inode still matches the cached observation, and the contender therefore removes a marker that a live honest holder just created. The upstream fix in commit 740ff666 reworks marker identity to include change time (ctime, which no process can forge with utime), writes a complete private <lock>.break.<pid>.<token> marker and swaps it with the lock path in a single atomic exchange via renameat2 on Linux and renamex_np on macOS, restores rather than deletes a live marker discovered on the wrong side of an exchange, and on platforms without an atomic exchange keeps the marker in place and waits for timeout or break_lock(). It also hardens marker restore against following symlinks left under the break name.

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 4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
vuln.today AI 4.7 MEDIUM

Local co-resident process needed (AV:L, PR:L), a multi-precondition race makes it AC:H, and removal of a live holder's marker breaks mutual exclusion for an integrity-only impact (I:H, C:N/A:N).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/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
None
Integrity
High
Availability
None

Lifecycle Timeline

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

DescriptionCVE.org

filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
High
filelock is a heavily-used Python library, transitive dependency of virtualenv/tox/huggingface
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.2%
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
Defer
Exploitation
Poc
System Exposure· derived
Small
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

24
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +24
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0
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-112914 MEDIUM
5.3 Oct 20

A local, low-privileged user (PR:L) who can rename files in a shared, non-sticky-bit lock directory can abuse the Python

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-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