filelock EUVD-2026-105021

Requires the application to use filelock's ReadWriteLock backed by its SQLite lock database, and a local attacker with a separate account who can replace that database file at the lock's database path - realistic when the database sits in a directory writable by other accounts (the patch's whole purpose is to open SQLite by name only in directories no other account can write, or via a private hard link). The attacker plants a crafted SQLite database whose schema exceeds a few kilobytes to load. Exploitation is limited to local attackers (AV:L) holding a valid account (PR:L); it is not remotely reachable, needs no victim interaction (UI:N), and yields only denial of service (A:H). Versions 3.20.4-4.2.0 are exposed on the initial per-instance open; from 3.30.0 the exposure recurs on every acquisition, making the stall more reliably triggerable.

This is a moderate, locally-scoped availability issue (CWE-400 resource exhaustion), not an urgent priority. The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (5.5, Medium) is internally consistent with the description: exploitation requires a local user (PR:L, AV:L) who can replace the lock database, and the only impact is availability (A:H) - no confidentiality or integrity loss. No EPSS score, KEV listing, or POC was provided, so exploitation status is: no public exploit identified at time of analysis. The signals do not conflict - all point to a low-to-moderate, local DoS rather than a widely-exploitable flaw. The practical blast radius is a hung or stalled lock acquisition in the victim process, which is a nuisance/denial-of-service rather than a route to code execution or data exposure. Note the attack precondition (an attacker who can already replace another account's lock database) implies the attacker often already has significant filesystem position, which further tempers real-world severity.

A local attacker with write access to the directory holding a ReadWriteLock's SQLite database replaces it with a crafted database whose schema is expensive to load. When the victim application next acquires the lock, SQLite parses the oversized schema without any bound tied to the acquire timeout, causing the acquisition to stall or hang and denying the victim the lock. No public exploit code was identified at time of analysis.