gam · filelock: ReadWriteLock on Windows acts on SQLite side files another local user places beside its database
Affects gamSource GCVE Database
Not known to be exploited · CVSS 3.3 Low.
Data as of 9 Nov 2026, 20:05 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: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
Until a fix is available, avoid placing lock databases in directories where untrusted local users can create files but cannot delete others' files (e.g., C:\Windows\Temp, C:\Users\Public). Use directories writable only by the lock user, such as per-user temporary directories or %LOCALAPPDATA%.
Description
On Windows, the filelock library's ReadWriteLock and AsyncReadWriteLock use SQLite side files for locking. A local user who can create files in the lock directory but cannot delete others' files can place a specially crafted SQLite side file (such as a -wal or -journal file) beside the database. This causes the lock user’s attempts to acquire read or write locks to fail with disk I/O errors or unexpected file deletions until the side file is removed. This affects filelock versions 3.20.4 through 4.2.0 on Windows in directories where untrusted users can create but not delete files, such as C:\Windows\Temp and C:\Users\Public. The vulnerability has a low CVSS score (3.3) due to its local attack vector and limited impact on availability only.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-9vhv-jxww-xfm5 (opens in a new tab)
- github.com/tox-dev/filelock/pull/834 (opens in a new tab)
- github.com/tox-dev/filelock/commit/5e3f2ec0c5fb17cb2635b60b2b68bc63ab81ca2d (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)