gam · filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the
Affects gamSource GCVE Database
Not known to be exploited · CVSS 2.5 Low.
Data as of 9 Nov 2026, 20:05 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 2.5 |
|---|
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 5 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewgampkg:brew/gamOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Mitigation involves ensuring that marker files are not left stale and inaccessible to other local users, or restricting read access to the lock directory's inherited ACL to prevent other accounts from opening the marker file. Users should monitor for updates from the filelock maintainers for an official fix. Until then, avoid scenarios where stale marker files remain accessible by other local accounts on Windows systems.
Description
On Windows, certain soft lock implementations in the filelock library (versions 3.22.0 through 4.2.0) can be blocked indefinitely by another local user exploiting Windows opportunistic locks (oplocks) on the lock marker file. This happens when a stale lock marker file is present and another local account with read access takes a Level 1 oplock on it without releasing it. As a result, attempts to acquire the lock by the original user hang past their timeout, causing partial availability impact without compromising confidentiality or integrity.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-567q-5qvw-pf92 (opens in a new tab)
- github.com/tox-dev/filelock/pull/835 (opens in a new tab)
- github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a (opens in a new tab)
- github.com/tox-dev/filelock (opens in a new tab)
- github.com/tox-dev/filelock/releases/tag/4.2.1 (opens in a new tab)