gam · filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into
Affects gamSource GCVE Database
Not known to be exploited · CVSS 3.3 Low.
Data as of 9 Nov 2026, 20:03 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 3.3 |
|---|
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/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
Mitigation requires preventing untrusted local users from having write access to the lock's parent directory, especially in sticky directories like /tmp. Ensuring that only trusted users can create or replace the .rw directory tree before the lock user's first acquire prevents exploitation. Monitoring and restricting directory permissions to avoid writable shared directories for untrusted users is recommended.
Description
CVE-2026-112941 describes a local integrity vulnerability in the SoftReadWriteLock implementation used by filelock versions 4.1.0 through 4.2.0. A local unprivileged user with write access to the lock's parent directory can replace the lock directory tree with symbolic links after the lock's initial acquisition, causing the lock user process to write lock records into attacker-controlled paths. This results in the lock user's files being replaced or deleted, breaking functionality such as a git repository's operation. The vulnerability requires specific conditions including directory write access and the presence of sticky bits in parent directories like /tmp. The impact is limited to integrity loss with no confidentiality or availability impact. The CVSS 3.1 base score is 3.3 (Low).
References
- github.com/tox-dev/filelock/security/advisories/GHSA-wfhq-q4j2-c37m (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112941 (opens in a new tab)
- github.com/tox-dev/filelock/pull/842 (opens in a new tab)
- github.com/tox-dev/filelock/commit/bfa066d65a1ba9106f86ee9d027f7588b9c77e03 (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)