ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112940

filelock is a platform-independent file lock for Python.

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

Check if you run it

No confirmed exploitation is on record for CVE-2026-112940. EPSS is 0.12%. 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.
Severity
High7.1
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.12%
Remediation
Version ranges on file
Affected products
cpe tox-dev/filelock · pip filelock · pypi filelock

and (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to , a Linux path that names the process's own open file . SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that points at another path). On every POSIX route SQLite also acts on , and files it finds beside that name. Those are SQLite's side files: the rollback journal (pages saved to undo an interrupted write), the write-ahead log or WAL (changes kept outside the main file), and the shared-memory index for the WAL. Another local user who can create or rename entries in the directory that holds the lock database can turn this against the user running the lock (below: the lock user). Such a directory is a or group-writable cache, build or project directory without the sticky bit (a directory flag that lets only a file's owner remove or rename it). That other user can make the lock user's ordinary or write bytes of the other user's choosing into the lock user's own files. The same position lets the other user make that call create or unlink files of the lock user, admit a reader beside a writer, or kill the holder. All of this runs with the lock user's privileges. In a sticky directory such as a planted file makes every acquire fail. Affected versions are filelock 3.20.4 through 4.2.0 (the redirect since 4.0.9, the side-file variants since 3.20.4). Anthropic's OSS Scanner reported this in private as [high, CWE-363]: ReadWriteLock: SQLite still follows planted symlinks, overwriting files. ## Severity **CVSS 3.1 scores 7.1 (High).** (local): the other user needs an account on the same host. (low privileges): an ordinary account is enough. (no user interaction). (low attack complexity): the planted-journal variant needs no race, and the redirect won 77 of 77 attempts. (high integrity impa

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

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-112940. EPSS is 0.12%. 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-363; CWE-59: Link Following. EPSS 0.12%. 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 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

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

  3. Oct 21, 2026 · NIST NVD

    Updated

    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

  4. Oct 23, 2026 · GitHub Advisory Database

    Updated

    and (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to , a Linux path that names the process's own open file . SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that

Sources

  • CVE.orgVulnerability recordCVE-2026-112940

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112940

    30-day exploitation probability 0.12%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-v4x8-3wr5-3wq8

    filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user's process overwrite or unlink its own files

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

    ReadWriteLock and AsyncReadWriteLock (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to /proc/self/fd/ , a Linux path that names the process's own open file n. SQLite turns that path back into a plain path and reopens it by n

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

    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 operatio

    nvd.nist.gov

References

Freshness

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