CVE-2026-112910: filelock WindowsFileLock mode parameter permission enforcement failure

CVE-2026-112910 · Severity: medium · CVSS 5.3 · Published 2026-11-05

The filelock library on Windows does not enforce the file permissions requested via the `mode` parameter when creating lock files. A lock file created with `mode=0o600` (intended to prevent other accounts from accessing it) instead inherits permissions from its parent directory, allowing other local users to read and potentially modify the lock file. This enables denial-of-service attacks and unauthorized access to lock metadata on shared systems with inherited directory permissions.

Technologies: filelock (PyPI), Tox-Dev Filelock. Vendors: PyPI, Tox-Dev.

Quick answers

Is CVE-2026-112910 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-112910 being exploited in the wild.
How severe is CVE-2026-112910?
Medium severity, with a CVSS score of 5.3, published 5 November 2026.
Which products and versions are affected?
filelock (PyPI) >= 3.10.0, <= 4.2.0, ECOSYSTEM:introduced=3.10.0,fixed=4.2.1; Tox-Dev Filelock 3.10.0 through 4.2.0 on Windows.
Is there a fix for CVE-2026-112910?
Yes. filelock (PyPI): upgrade to 4.2.1 or later. Until then: Store lock files and ReadWriteLock databases in directories with ACLs that exclude other accounts (such as inside user profiles or directories with inheritance disabled), or manually restrict file ACLs after creation using system tools like `icacls`. Do not store confidential data in lock files via `on_acquired` hooks on Windows. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-112910 attacked?
It is attacked with local access, in a software library.
Am I affected by CVE-2026-112910?
Check whether you run filelock (PyPI) or Tox-Dev Filelock at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • filelock (PyPI): upgrade to 4.2.1 or later
    pip install "filelock>=4.2.1"

Store lock files and ReadWriteLock databases in directories with ACLs that exclude other accounts (such as inside user profiles or directories with inheritance disabled), or manually restrict file ACLs after creation using system tools like `icacls`. Do not store confidential data in lock files via `on_acquired` hooks on Windows.

Technical details

The WindowsFileLock class ignores the `mode` parameter by reducing it to a read-only file attribute in `_open_non_reparse_fd()` and leaving the `SecurityDescriptor` field NULL in `OBJECT_ATTRIBUTES` during file creation via `NtCreateFile()`. This results in files inheriting the parent directory's inheritable ACL entries. An attacker with local access can open lock files marked `0o600`, acquire byte-range locks to deny the legitimate owner, and read or modify lock file contents where directory permissions permit.

Affected products

  • tox-dev filelock 3.10.0 through 4.2.0 on Windows

Identifiers

  • CVE-2026-112910
  • GHSA-8mx5-7m5m-r77g

Timeline

  • 2026-10-15: disclosed: Report received from Anthropic OSS Scanner
  • 2026-10-16: advisory: Advisory drafted; two-account verification completed on Windows
  • 2026-10-16: patched: Fix PR #835 opened
  • 2026-10-28: other: Advisory published

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.