ZDF
Sign inSign up

Vulnerabilities

Security fix · CVE-2026-112939

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

, , , their async variants and a that has fallen back to a soft lock on decide from the record inside the marker file whether its owner is gone. The marker is the file whose presence says a process holds the lock. They do not check who could have written that record. A local user who can write the marker but cannot remove it rewrites the holder's record to name a dead PID (process id). That position arises with an explicit with group or other write bits, or the default mode under a lax umask (the process setting that strips permission bits from new files), in a sticky or otherwise non-removable directory. The sticky bit is a directory flag that lets only a file's owner remove or rename it. The next contender running as the holder's account, or root, judges the lock stale, removes the live marker on that user's behalf and acquires it. Two processes then run the critical section together and neither gets an error. Affected versions are filelock 3.22.0 through 4.2.0 (finding ). ## Severity **CVSS 3.1 scores 4.7 (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 marker must carry group or other write bits (an explicit permissive , or umask / with a shared group), and a contender of the holder's account must ask for the lock while the forged record is in place. (high integrity impact): two holders then write whatever the lock protects, and the holder is not told. and (no confidentiality or availability impact). (scope unchanged). Classification from the review: **security, conditional** on another user being able to write the live marker. The scanner rated it high (CWE-345). The default mode under umask is not affected. ## Scope and preconditions - The other user can write the marker. The application passes a with group or other write bits, which applies as given since 4.1.0. is a common choice for a lock shared between accounts, although a soft-lock

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

How to fix CVE-2026-112939

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

What should an analyst verify?

CWE-345: Insufficient Verification of Data Authenticity. EPSS 0.14%. 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.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. 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.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.

  3. Oct 20, 2026 · NIST NVD

    Updated

    filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. 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 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.

  5. Oct 28, 2026 · GitHub Advisory Database

    Updated

    , , , their async variants and a that has fallen back to a soft lock on decide from the record inside the marker file whether its owner is gone. The marker is the file whose presence says a process holds the lock. They do not check who could have written that record. A local user who can write the marker but cannot remove it rewrites the holder's record to name a dead PID (process id). That positi

Sources

  • CVE.orgVulnerability recordCVE-2026-112939

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112939

    30-day exploitation probability 0.14%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-rfpc-qcw5-3pc4

    filelock: SoftFileLock removes a live holder's marker when another user forges the PID in a writable marker

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

    SoftFileLock, MarkerSoftFileLock, SoftFileLease, their async variants and a FileLock that has fallen back to a soft lock on ENOSYS decide from the record inside the marker file whether its owner is gone. The marker is the file whose presence says a process holds the lock. They do not check who could have written that record. A local user who can write the marker but cannot remove it rewrites the h

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

    filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root

    nvd.nist.gov

References

Freshness

Last verified in this catalog Nov 1, 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
  • CVE.orgOct 21, 2026
  • NIST NVDOct 21, 2026