gam · filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path
Affects gamSource GCVE Database
Not known to be exploited · CVSS 6.1 Medium.
Data as of 9 Nov 2026, 20:05 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 6.1 |
|---|
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 20 Oct 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
No explicit patch or fix is stated in the provided data. Mitigation involves ensuring that directories used for lock files have the sticky bit set to prevent unauthorized renames, and that the Linux kernel setting fs.protected_hardlinks is enabled (set to 1) to prevent unauthorized hard links. Avoid sharing lock directories with other users who have write permissions. Review and restrict directory permissions to prevent local users from renaming or linking files onto lock paths.
Description
The UnixFileLock component in the FileLock and AsyncFileLock libraries on Unix truncates and changes permissions (chmod) of any regular file that another local user renames or hard-links onto the lock path. This occurs when the lock user acquires the lock, potentially allowing the other user to read and modify the file contents if a permissive mode is set. The vulnerability requires local user access and specific filesystem conditions such as writable non-sticky directories or disabled kernel hardlink protection. It affects all filelock releases up to and including 4.2.0.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112909 (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)