ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112941

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 3, 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-112941. EPSS is 0.13%. 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
Low3.3
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.13%
Remediation
Version ranges on file
Affected products
cpe tox-dev/filelock · pip filelock · pypi filelock

(and , which wraps one) checks once per lock object, by name, that , and are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and (a flag that makes an open fail when the final name is a symbolic link) protects the last component only. Another local user (the other user below) who can write the directory holding the lock, or who created first in a sticky directory such as (the sticky bit is a directory flag that lets only a file's owner rename or remove it), can put a tree under that name whose or is a symbolic link into a directory of the user running the lock (the lock user below). A long-running process of the lock user that has already passed the check then creates, renames over and deletes files there with the lock user's privileges, including in directories the other user cannot open. The names and bytes are filelock's own lock records, not chosen by the other user. The scanner's reproducer replaces in the lock user's private repository so that fails. There is no race. Affected versions: filelock >= 4.1.0 and <= 4.2.0. Anthropic's OSS Scanner reported it in private as [high, CWE-367], titled "SoftReadWriteLock follows gen dir swapped for a symlink after first acquire". ## Severity **CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 3.3 (Low).** (local): the other user needs an account on the same host. (low attack complexity): the swap happens between two acquisitions, with no race to win. (low privileges): a local user with ordinary privileges is enough. (no user interaction): the lock user's process acts on its own. (no confidentiality impact): the other user learns nothing. (low integrity impact): the lock user's process replaces a file named , creates and generation records, and deletes files whose names match the protocol's patterns, in any directory the lock user can write, with the lock user's privileges. The other user does not choose the

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>= 4.1.0, <= 4.2.0
  • pypi filelockversion unspecified

How to fix CVE-2026-112941

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-112941. EPSS is 0.13%. 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, >= 4.1.0, <= 4.2.0. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. EPSS 0.13%. 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 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the .rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue

  2. Oct 20, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the .rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue

  3. Oct 21, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the .rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue

  4. Oct 28, 2026 · GitHub Advisory Database

    Updated

    (and , which wraps one) checks once per lock object, by name, that , and are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and (a flag that makes an open fail when the final name is a symbolic link) protects the last component only. Another local user (the other user below) who

Sources

  • CVE.orgVulnerability recordCVE-2026-112941

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112941

    30-day exploitation probability 0.13%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-wfhq-q4j2-c37m

    filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock

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

    SoftReadWriteLock (and AsyncSoftReadWriteLock, which wraps one) checks once per lock object, by name, that .rw, .rw/gen and .rw/holders are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and O_NOFOLLOW (a flag that makes an open fail when the final name is a symbolic link) prote

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

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the .rw lock tree and resolve its names again during later record operations, allowing another local user who can replac

    nvd.nist.gov

References

Freshness

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

  • FIRST EPSSNov 3, 2026
  • GitLab Advisory DatabaseOct 30, 2026
  • GitHub Advisory DatabaseOct 29, 2026
  • CVE.orgOct 21, 2026
  • NIST NVDOct 21, 2026