Cloudanix VulnDB

CVE-2026-112940

High · 7.1

CVSS

7.1

EPSS

0.2%

Published

Oct 20, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A Python library used to safely lock files could let a nearby user on the same computer trick it into deleting or overwriting important data files.

Exploit Available
Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Tampering
Component
Library
Class
Path Traversal
Remediation
Upgrade
Effort
Low
Patch risk
Low

What it actually does

ReadWriteLock reopens SQLite database and side files by name, enabling a local POSIX attacker with rename rights in a non-sticky directory to substitute names and trigger overwrite or unlink operations when a writable adjacent hot journal is present.

Why it matters to the business

Applications relying on filelock for safe concurrent SQLite access can suffer data corruption, file loss, or unexpected unlinks, leading to application failures or integrity issues; urgency is moderate given recent publication and rising EPSS but no KEV listing.

How an attack unfolds

An attacker with local rename access in a non-sticky parent directory renames the SQLite database and journal files while a hot journal exists, causing the library to operate on attacker-controlled paths and perform overwrite or unlink actions on the substituted names.

How to fix it

Upgrade tox-dev filelock to version 4.2.1 or later; verify the installed version with pip show filelock and replace any pinned older releases in requirements or lockfiles.

How to confirm the fix worked

Confirm the running package version is 4.2.1 or newer; test that ReadWriteLock operations no longer follow renamed files by simulating the rename attack in a controlled POSIX environment.

Typical attack path

  1. Identify a process using filelock ReadWriteLock on SQLite files
  2. Obtain rename permissions in the non-sticky parent directory
  3. Prepare a writable adjacent hot journal with chosen content
  4. Atomically rename the database and side files to redirect operations
  5. Trigger the library to reopen files by name, resulting in overwrite or unlink

How to detect it

Review application logs for unexpected file unlinks or overwrites involving SQLite databases; inspect process activity for filelock usage combined with rename syscalls in the same directory; correlate with recent file timestamp anomalies on journal files.

What your security team should do

  • Prioritize upgrade of filelock to 4.2.1 across all Python environments within the next 30 days
  • Scan dependency graphs for indirect usage via tox or other consumers
  • Monitor EPSS trend and any new exploit releases given the ExploitAvailable maturity
  • Restrict local rename permissions on directories containing SQLite lock files where feasible

The record

filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities