ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112915

filelock is a platform-independent file lock for Python.

Published Oct 20, 2026 · catalog updated Oct 28, 2026 · filelock is a platform-independent

Last checked Nov 7, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-112915. EPSS is 0.22%. Act only if a listed version of filelock is a platform-independent is installed.

Gaps on this record

  • The stored product name is a package slug. The name on this page is taken from the title (filelock is a platform-independent).
  • No vendor fix or required action is stored. Compare the linked advisory before you change production.

Same product and reporting

Severity
Medium5.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.22%
Remediation
Version ranges on file
Affected products
cpe tox-dev/filelock · pip filelock · pypi filelock

and (the SQLite-backed reader/writer lock) run on a fresh connection for every acquire. That statement makes SQLite load the whole schema (the table, which lists every table and index with its text) of whatever file sits at the lock path. The caller's reaches SQLite only as , which bounds waits for another connection's lock, not schema loading. The only content checks reject non-regular files and WAL mode (write-ahead log, an SQLite mode that keeps changes in a side file). A local user who can place or overwrite the file at a 's database path can therefore make every / of every process using that lock ignore its and . That position needs a non-sticky shared directory, or a database owned by the user running the lock (below: the lock user) that other users may write. One 37 KB crafted file stalls each acquire for as long as its author chooses while the process allocates about 1 GB. A second 28 KB layout makes the acquire of a free lock run without end, spinning at 100% CPU and ignoring Ctrl-C. The effect is availability only: the other user reads nothing and corrupts nothing. Affected versions are filelock 3.20.4 through 4.2.0. Anthropic's OSS Scanner reported this in private as [medium, CWE-400]: ReadWriteLock: crafted lock database hangs acquire regardless of timeout. ## Severity **CVSS 3.1 scores 5.5 (Medium).** (local): the other user needs an account on the same host. (low privileges): an ordinary account is enough. (low attack complexity): the other user plants one file; no race. (no user interaction). (high availability impact): every acquire of every process using the lock runs for as long as that user chose, or does not return, with and ignored and not delivered, so only killing the process ends it. and (no confidentiality or integrity impact): the other user reads nothing and corrupts nothing. (scope unchanged). Classification from the external review: **conditional security**, an availability concern only when an untrusted actor can supply the database fil

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • cpe tox-dev/filelock< 4.2.1
  • pip filelock>= 3.20.4, <= 4.2.0
  • pypi filelockversion unspecified

How to fix CVE-2026-112915

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-112915. EPSS is 0.22%. Act only if a listed version of filelock is a platform-independent is installed.

Which versions are affected?

Compare what you have installed with < 4.2.1, >= 3.20.4, <= 4.2.0. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-400: Uncontrolled Resource Consumption. EPSS 0.22%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 20, 2026 · NIST NVD

    Detected

    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.

  2. Oct 20, 2026 · NIST NVD

    Updated

    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.

  3. Oct 20, 2026 · NIST NVD

    Updated

    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.

  4. Oct 21, 2026 · NIST NVD

    Updated

    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.

  5. Oct 28, 2026 · GitHub Advisory Database

    Updated

    and (the SQLite-backed reader/writer lock) run on a fresh connection for every acquire. That statement makes SQLite load the whole schema (the table, which lists every table and index with its text) of whatever file sits at the lock path. The caller's reaches SQLite only as , which bounds waits for another connection's lock, not schema loading. The only content checks reject non-regular files and

Sources

  • CVE.orgVulnerability recordCVE-2026-112915

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112915

    30-day exploitation probability 0.22%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-cwqr-hh33-gh44

    filelock ReadWriteLock: a crafted lock database makes every acquire stall or hang regardless of timeout

    github.com
  • GitLab Advisory DatabasePackage advisoryCVE-2026-112915

    ReadWriteLock and AsyncReadWriteLock (the SQLite-backed reader/writer lock) run PRAGMA journal_mode=MEMORY on a fresh connection for every acquire. That statement makes SQLite load the whole schema (the sqlite_master table, which lists every table and index with its CREATE text) of whatever file sits at the lock path. The caller's timeout reaches SQLite only as busy_timeout, which bounds waits for

    advisories.gitlab.com
  • NIST NVDVulnerability recordCVE-2026-112915

    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 fro

    nvd.nist.gov

References

Freshness

Last verified in this catalog Nov 7, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • GitLab Advisory DatabaseOct 30, 2026
  • GitHub Advisory DatabaseOct 29, 2026
  • FIRST EPSSOct 23, 2026
  • NIST NVDOct 22, 2026
  • CVE.orgOct 21, 2026