ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112911

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

, , and keep their whole ownership state as files in a directory derived from the lock path ( , ). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In , or another sticky shared directory any user can do that; the sticky bit is a directory flag that lets only a file's owner remove or rename it. The other user then owns the tree. They can unlink the lock user's claims while the lock user holds the lock, so a second process of the lock user, root included, enters the same critical section and neither process sees an error. Against the same position also admits two writers with silent. It redirects the lock user's own creates and renames into a directory the other user picks (the scanner replaced a repository's with a filelock record written with the lock user's privileges). It also keeps the lock user's acquire or release running past any . Affected versions are filelock 3.30.0 through 4.2.0 (finding ). ## Severity **CVSS 3.1 scores 6.3 (Medium).** (local): the other user needs an account on the same host. (low privileges): an ordinary account is enough. (no user interaction). (high attack complexity): the other user must create the protocol directory before the lock user's first acquire on that path. That depends on the path being new, or on a reboot, a tmp cleaner or the documented recovery having removed its tree; once planted, the rest needs no race. (high integrity impact): two holders write whatever the lock protects, and for the lock user's process creates, replaces or deletes files named , and in any directory the lock user can write. (high availability impact): the owner of can make the lock user's spin at full CPU without end, cost 22 s per acquire, or pin 1 MiB of memory per planted file until a heartbeat thread dies of

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

How to fix CVE-2026-112911

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

What should an analyst verify?

CWE-283. EPSS 0.15%. 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.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. 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 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. 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 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.

  4. Oct 28, 2026 · GitHub Advisory Database

    Updated

    , , and keep their whole ownership state as files in a directory derived from the lock path ( , ). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can create the tree before the first acquire on that path by the user running the lock (below: the lock user). In , or ano

Sources

  • CVE.orgVulnerability recordCVE-2026-112911

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112911

    30-day exploitation probability 0.15%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-9c4x-gm8v-wgc4

    filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing mutual exclusion

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

    StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock and AsyncSoftReadWriteLock keep their whole ownership state as files in a directory derived from the lock path ( .filelock/claims, .rw/{gen,holders}). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can cre

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

    filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user

    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
  • NIST NVDOct 22, 2026
  • CVE.orgOct 21, 2026