Cloudanix VulnDB

CVE-2026-112915

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Oct 20, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Python library used to safely share files between programs can be tricked by a nearby user into freezing those programs with a specially made database file.

Exploit Available
Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Low
Patch risk
Low

What it actually does

ReadWriteLock in filelock opens a SQLite lock database without schema or query bounding, enabling resource exhaustion that stalls or hangs lock acquisition when a local attacker supplies a crafted database file.

Why it matters to the business

Applications using filelock for concurrency control may experience process hangs and denial of service, disrupting builds, tests, deployments, and other workflows that depend on reliable locking in shared environments.

How an attack unfolds

A local attacker identifies an application using ReadWriteLock, replaces its SQLite lock database with a maliciously crafted file, and triggers lock acquisition; the library performs unbounded work on the crafted schema or queries, causing the operation to stall or hang.

How to fix it

Upgrade filelock to version 4.2.1 or later; after upgrade, restart affected processes and verify that lock acquisition completes normally even when the database file is present.

How to confirm the fix worked

Confirm the installed filelock version is 4.2.1 or higher via package metadata; test lock creation and acquisition against both normal and malformed SQLite files to ensure operations complete without indefinite stalls.

Typical attack path

  1. Locate a target process or script that instantiates ReadWriteLock from filelock
  2. Replace the expected SQLite lock database file with a crafted malicious version
  3. Trigger lock acquisition via normal application behavior or direct API call
  4. Observe the resulting stall or hang in the affected process

How to detect it

Review application and system logs for unexpected long-running SQLite operations or filelock acquisition timeouts; correlate with file modification events on lock database paths; no network or remote indicators apply.

What your security team should do

  • Immediately upgrade all instances of filelock to 4.2.1 or newer
  • Scan dependency trees to identify every package that pulls in filelock
  • Add version pinning and automated dependency updates to prevent regression
  • Monitor process logs for prolonged lock-wait times or SQLite-related stalls

The record

filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities