mlx-lm · filelock: SoftReadWriteLock holder refresh writes through a hard link and hangs on a named pipe that another local
Affects mlx-lmSource GCVE Database
Not known to be exploited · CVSS 6.1 Medium : upgrade to 0.32.2_1 when convenient.
Data as of 30 Oct 2026, 06:59 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 6.1 |
|---|
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 14% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.32.2_1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:HExploitation 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 29 Oct 2026.
What to do
Upgrade mlx-lm to 0.32.2_1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewmlx-lmpkg:brew/mlx-lmOther 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
A patch is available in filelock version 0.32.2_1 that addresses this vulnerability. Users should upgrade to this fixed version to remediate the issue. No other mitigation or workaround is indicated by the vendor advisory. The vulnerability requires local user access and ownership of the lock's .rw directory, so restricting directory permissions and avoiding placing lock directories in world-writable sticky directories may reduce exposure but is not a substitute for patching.
Description
CVE-2026-112934 is a medium severity local vulnerability in filelock versions >=0.32.0 and <0.32.2_1. It involves the SoftReadWriteLock mechanism refreshing its holder record by reopening and writing to a file without verifying the file type, allowing a local attacker who owns the lock's .rw directory to cause the lock user's process to hang by replacing the holder record with a named pipe (FIFO). Additionally, on systems where the kernel permits hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock user to overwrite part of one of its own private files. The vulnerability leads to denial of service by stalling lock acquisition and heartbeat threads, potentially allowing multiple processes to believe they hold the write lock simultaneously. A fix is available in version 0.32.2_1.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-fj95-fr6c-h845 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112934 (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)