ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-112907

filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break

Published Oct 23, 2026 · catalog updated Oct 23, 2026 · Red Hat Red Hat Enterprise Linux

Last checked Nov 7, 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-112907. EPSS is 0.10%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.

Same product and reporting

Severity
Low2.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.10%
Remediation
Version ranges on file
Affected products
PyPI filelock · pip filelock · pypi filelock

On Windows the soft locks ( , , , their async forms, and a that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each attempt that finds a marker opens it with to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock (opportunistic lock) is a request by a process that holds a handle on a file to be told before another process opens, renames or deletes that file; the other process waits until the holder answers the break or closes its handle. Another local account that can open the marker for reading can take a Level 1 oplock on it while no process holds it open, and leave the break unanswered. Every by the user running the lock (below: the lock user) then waits inside the open, past its , and , and a stale marker under that oplock is not broken. Mutual exclusion holds and the lock touches no other file. Affected versions are filelock 3.22.0 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the report Anthropic's OSS Scanner sent on 15 October 2026 (review round 4, finding F4); it is not among the scanner's findings. ## Severity **CVSS 3.1 scores 2.5 (Low).** (local): the other account needs a logon on the same host. (high attack complexity): Windows grants a Level 1 or batch oplock only to the sole open handle on a file, so the marker must have no holder handle when the other account asks. That account cannot bring this about; it waits for a holder that died, closed its descriptor, or left a marker past its . (low privileges): an ordinary account with read access to the marker through the directory's inherited ACL (access control list). (no user interaction). (scope unchanged). and : that account can read the marker's content (process id and host name) anyway, and mutual exclusion holds. (partial availability impact): one thread, or the event loop with ,

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 filelock3.22.0 → 4.2.1
  • pip filelock>= 3.22.0, <= 4.2.0
  • pypi filelock>=3.22.0,<4.2.1

How to fix CVE-2026-112907

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-112907. EPSS is 0.10%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Which versions are affected?

Compare what you have installed with 3.22.0 → 4.2.1, >= 3.22.0, <= 4.2.0, >=3.22.0,<4.2.1. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-412; CWE-667. EPSS 0.10%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Technology hubs

Windows security

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 23, 2026 · GitHub Advisory Database

    Detected

    On Windows the soft locks ( , , , their async forms, and a that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each attempt that finds a marker opens it with to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock

  2. Oct 23, 2026 · GitHub Advisory Database

    Updated

    On Windows the soft locks ( , , , their async forms, and a that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each attempt that finds a marker opens it with to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock

  3. Oct 23, 2026 · PyPA Advisory Database

    Fix available

    filelock fixed in 4.2.1

  4. Oct 23, 2026 · PyPA Advisory Database

    Fix available

    filelock fixed in 4.2.1

  5. Oct 23, 2026 · PyPA Advisory Database

    Updated

    On Windows the soft locks ( , , , their async forms, and a that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each attempt that finds a marker opens it with to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock

Sources

  • CVE.orgVulnerability recordCVE-2026-112907

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-112907

    30-day exploitation probability 0.10%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-567q-5qvw-pf92

    filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break

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

    On Windows the soft locks (SoftFileLock, MarkerSoftFileLock, SoftFileLease, their async forms, and a FileLock that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each acquire() attempt that finds a marker opens it with os.open to read the holder's process id, and the lock renames and deletes a marker it judges stale, b

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

    On Windows the soft locks ( , , , + their async forms, and a that fell back to a soft lock) read their marker + by path. The marker is the lock file whose presence says a process holds the lock. + Each attempt that finds a marker opens it with to read the + holder's process id, and the lock renames and deletes a marker it judges stale, + by path. On Windows each of these calls waits for an oplock.

    gitlab.com
  • PyPA Advisory DatabasePackage advisoryGHSA-567q-5qvw-pf92

    filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break

    osv.dev
  • Red Hat Security DataVendor advisoryCVE-2026-112907

    filelock: filelock: Denial of Service via Windows opportunistic lock on lock markers

    access.redhat.com

References

Freshness

Last verified in this catalog Nov 6, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • Red Hat Security DataNov 7, 2026
  • FIRST EPSSNov 6, 2026
  • GitLab Advisory DatabaseOct 27, 2026
  • PyPA Advisory DatabaseOct 26, 2026
  • GitLab Advisory DatabaseOct 26, 2026
  • CVE.orgOct 24, 2026
  • GitHub Advisory DatabaseOct 24, 2026