mlx-lm · filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing
Affects mlx-lmSource GCVE Database
Not known to be exploited · CVSS 6.3 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.3 |
|---|
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 3% 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:H/PR:L/UI:N/S:U/C:N/I:H/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 fix is available in mlx-lm version 0.32.2_1. Users should upgrade to this version to remediate the vulnerability. Until patched, avoid using new lock paths in shared sticky directories such as /tmp where other untrusted local users can pre-create directories. Existing lock paths with established protocol directories are not vulnerable as the directory ownership is stable. No other mitigations are documented or recommended.
Description
The vulnerability affects the StrictSoftFileLock and SoftReadWriteLock classes in the mlx-lm product, versions >=0.31.3_3 and <0.32.2_1. These locking mechanisms adopt a protocol directory if it already exists without verifying ownership, allowing a local attacker to pre-create this directory in shared sticky-bit directories like /tmp. This can lead to multiple processes entering the same critical section simultaneously, causing integrity and availability issues such as concurrent writes and denial of service via spinning or memory exhaustion. The flaw requires the attacker to have local user access and to create the directory before the legitimate user’s first lock acquisition. The CVSS 3.1 score is 6.3 (Medium). A fix is available in version 0.32.2_1.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-9c4x-gm8v-wgc4 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112911 (opens in a new tab)
- github.com/tox-dev/filelock/pull/839 (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)