Read the docs
TI-2026-85681 Aliases CVE-2026-112907

Oplock on lock marker makes filelock wait past timeout on Windows

Priority LOW 12CWE-667Published · Updated

Key facts

Attack vector
Local
Privileges required
Low
User interaction
None
Attack complexity
High
Impact type
—
Confidentiality · integrity · availability
None · None · Low
Fix status
Partial Red Hat: 1 without a fix

Attack profile from CVSS 3.1 · CNA. Fix status from CNA, GitHub and Red Hat.

Summary

filelock from 3.22.0 before 4.2.1 has a locking flaw on Windows (CWE-667). Its soft lock classes use pathname operations that wait for an oplock break on the lock marker. A local user with read access to an unheld marker can keep an oplock unanswered, so SoftFileLock.acquire waits beyond its timeout. Mutual exclusion stays intact and no file other than the marker is accessed.

Written with Claude Haiku 5.5 from the sources below · 2026-11-07

Description from the CNA

filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, soft lock classes on Windows read an existing marker with _read_lock_file and remove a stale marker through break_lock_file using pathname operations that wait for an oplock break. Another local account with read access to an unheld marker can keep a Level 1 or batch oplock unanswered, causing SoftFileLock.acquire and related async or fallback locks to wait beyond timeout, blocking=False, and cancel_check. A stale marker under the oplock cannot be broken, but mutual exclusion remains intact and no file other than the marker is accessed. This issue is fixed in version 4.2.1.

Why it matters now

EPSS 0.00104 1st percentileScored 2026-11-07
Fix Partial filelock (tox-dev): 4.2.1filelock (PyPI): 4.2.1Red Hat: 1 without a fix

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
tox-devfilelock3.22.0 to before 4.2.14.2.1Patch availableCNA
—filelock (PyPI)3.22.0 to before 4.2.14.2.1Patch availableGHSA-567q-5qvw-pf92
  • filelock Vendortox-dev Affected 3.22.0 to before 4.2.1 Fixed in 4.2.1 Patch available CNA
  • filelock (PyPI) Vendor— Affected 3.22.0 to before 4.2.1 Fixed in 4.2.1 Patch available GHSA-567q-5qvw-pf92

CPE names Threatist (inferred) · 1

Inferred from how NVD named this product before; not given by a source.

CPEVersionsRoleVendor
cpe:2.3:a:tox-dev:filelock:*:*:*:*:*:*:*:*——tox-dev
  • cpe:2.3:a:tox-dev:filelock:*:*:*:*:*:*:*:* Versions — — ·tox-dev

Remediation

Upgrade filelock to version 4.2.1, which fixes the flaw in the PyPI and tox-dev packages. Red Hat lists Red Hat OpenShift AI (RHOAI) as affected, with no plan available.

Written with Claude Haiku 5.5 from the sources below · 2026-11-07

  • Fix · CNA filelock (tox-dev) Fixed in 4.2.1
  • Fix · GHSA-567q-5qvw-pf92 filelock (PyPI) Fixed in 4.2.1 Advisory →

Vendor assessments

Red Hat

Red Hat rating: Low. Red Hat's page for this CVE →

ProductStatusPlan or fix
Red Hat OpenShift AI (RHOAI)AffectedNo fix yet: Fix deferred

Timeline

  1. 2026-11-05 Threatist record created from CVE-2026-112907
  2. 2026-11-07 Affected versions changed · Red Hat
  3. 2026-11-07 CVSS score added · Red Hat

References

Other 6

  • TI-2026-76862 Symlink race in filelock ReadWriteLock lets attackers overwrite files CVSS 3.1HIGH 7.1
  • TI-2026-76853 filelock soft locks adopt directories created by other local users CVSS 3.1MEDIUM 6.3
  • TI-2026-76859 Symlink following in filelock ReadWriteLock redirects SQLite database CVSS 3.1MEDIUM 6.1
  • TI-2026-76857 Unsafe holder record refresh in filelock SoftReadWriteLock CVSS 3.1MEDIUM 6.1
  • TI-2026-76852 filelock UnixFileLock truncates files placed on the lock path CVSS 3.1MEDIUM 6.1
  • TI-2026-76856 Crafted lock database makes filelock ReadWriteLock acquisitions hang CVSS 3.1MEDIUM 5.5
See all 19 →

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences