gam · filelock: WindowsFileLock ignores mode: a 0o600 lock file and the ReadWriteLock database inherit the directory ACL
Affects gamSource GCVE Database
Not known to be exploited · CVSS 5.3 Medium.
Data as of 9 Nov 2026, 20:05 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 5.3 |
|---|
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/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
Users should ensure that directories used for lock files do not have inheritable ACL entries granting read or modify access to other local accounts. Restrict directory permissions to exclude other accounts to prevent unauthorized access to lock files. Monitor vendor advisories for any future patches or updates addressing this issue.
Description
The filelock library on Windows ignores the specified file mode (e.g., 0o600) when creating lock files and the ReadWriteLock database. Instead of applying restrictive permissions, the created files inherit the directory's ACL, potentially allowing other local accounts with inherited access to read or modify these lock files. This can lead to partial confidentiality, integrity, and availability impacts, such as unauthorized reading of lock metadata, corruption of lock state, and denial of lock acquisition by the legitimate owner. The issue affects filelock versions 3.10.0 through 4.2.0 on Windows.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-8mx5-7m5m-r77g (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)