ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112937

filelock is a platform-independent file lock for Python.

Published Oct 20, 2026 · catalog updated Oct 23, 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-112937. EPSS is 0.16%. 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
Medium6.1
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.16%
Remediation
Version ranges on file
Affected products
PyPI filelock · cpe tox-dev/filelock · pip filelock · pypi filelock

and (the SQLite-backed reader/writer lock) remove their private link directories with (a recursive delete) on a remembered path. They do not check that the path still names the directory they created. This happens on the hard-link route (a hard link is a second name for the same file). That route is every connection on macOS since 4.1.1 and any POSIX process without a usable (a Linux path that names the process's own open files), such as a chroot or container that does not mount . Another local user who can rename entries in the directory that holds the lock database can rename one of the directories of the user running the lock (below: the lock user) onto the link directory's name, or onto a forged dead-holder name. Such a lock 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). The lock user's process then deletes that tree and everything in it with the lock user's permissions, and reports no error. Stock Linux with mounted is not affected. Affected versions are filelock 4.1.0 through 4.2.0. Anthropic's OSS Scanner reported this in private as [high, CWE-367]: ReadWriteLock deletes any directory another user renames to .filelock-*. ## Severity **CVSS 3.1 scores 6.1 (Medium).** (local): the other user needs an account on the same host. (low privileges): an ordinary account is enough. (no user interaction). (low attack complexity): two calls and no race against filelock's own code. (high integrity impact): the other user destroys a directory tree owned by the lock user, and the lock user's program reports no error. (partial availability loss): the Python 3.11 variant makes the lock user's first lock construction fail. (no confidentiality impact): the other user learns nothing. (scope unchanged): the effect stays within the lock user's own privileges. Classification from the external review: **conditional security**, a cross-user rename in a non-sticky shared pa

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.

  • PyPI filelock4.1.0 → 4.2.1
  • cpe tox-dev/filelock< 4.2.1
  • pip filelock>= 4.1.0, <= 4.2.0
  • pypi filelock>=4.1.0,<4.2.1

How to fix CVE-2026-112937

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-112937. EPSS is 0.16%. 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.1.0 → 4.2.1, < 4.2.1, >= 4.1.0, <= 4.2.0, >=4.1.0,<4.2.1. 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.16%. 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.

Related records

Linked stories and findings that share CVE identifiers or explicit correlation edges.

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, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.

  2. Oct 20, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.

  3. Oct 21, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.

  4. Oct 21, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.

  5. Oct 23, 2026 · GitHub Advisory Database

    Updated

    and (the SQLite-backed reader/writer lock) remove their private link directories with (a recursive delete) on a remembered path. They do not check that the path still names the directory they created. This happens on the hard-link route (a hard link is a second name for the same file). That route is every connection on macOS since 4.1.1 and any POSIX process without a usable (a Linux path that nam

  6. Oct 23, 2026 · PyPA Advisory Database

    Fix available

    filelock fixed in 4.2.1

  7. Oct 23, 2026 · PyPA Advisory Database

    Fix available

    filelock fixed in 4.2.1

  8. Oct 23, 2026 · PyPA Advisory Database

    Updated

    and (the SQLite-backed reader/writer lock) remove their private link directories with (a recursive delete) on a remembered path. They do not check that the path still names the directory they created. This happens on the hard-link route (a hard link is a second name for the same file). That route is every connection on macOS since 4.1.1 and any POSIX process without a usable (a Linux path that nam

Sources

  • CVE.orgVulnerability recordCVE-2026-112937

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112937

    30-day exploitation probability 0.16%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-jqc4-5cvw-7w85

    filelock: ReadWriteLock on the hard-link route deletes any directory another user renames onto its .filelock-* link directory name

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

    ReadWriteLock and AsyncReadWriteLock (the SQLite-backed reader/writer lock) remove their private .filelock-* link directories with shutil.rmtree (a recursive delete) on a remembered path. They do not check that the path still names the directory they created. This happens on the hard-link route (a hard link is a second name for the same file). That route is every connection on macOS since 4.1.1 an

    advisories.gitlab.com
  • GitLab Advisory DatabasePackage advisorypypi/filelock/CVE-2026-112937.yml

    and (the SQLite-backed reader/writer + lock) remove their private link directories with (a + recursive delete) on a remembered path. They do not check that the path still names + the directory they created. This happens on the hard-link route (a hard link is + a second name for the same file). That route is every connection on macOS since + 4.1.1 and any POSIX process without a usable (a Linux pat

    gitlab.com
  • NIST NVDVulnerability recordCVE-2026-112937

    filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a d

    nvd.nist.gov
  • PyPA Advisory DatabasePackage advisoryGHSA-jqc4-5cvw-7w85

    filelock: ReadWriteLock on the hard-link route deletes any directory another user renames onto its .filelock-* link directory name

    osv.dev

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 27, 2026
  • GitLab Advisory DatabaseOct 26, 2026
  • PyPA Advisory DatabaseOct 25, 2026
  • GitHub Advisory DatabaseOct 24, 2026
  • NIST NVDOct 21, 2026
  • CVE.orgOct 21, 2026