mlx-lm · filelock: SoftFileLock removes a live holder's marker when another user forges the PID in a writable marker
Affects mlx-lmSource GCVE Database
Not known to be exploited · CVSS 4.7 Medium : upgrade to 0.32.2_1 when convenient.
Data as of 30 Oct 2026, 06:59 UTC
- 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: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 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. Until patched, avoid creating lock marker files with group or other write permissions in sticky or non-removable directories. Using the default umask 022 or ensuring marker files are not writable by other users mitigates the risk. No other actions are required if the patch is applied.
Description
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but not removal rights) to forge the process ID in the marker. This causes another process running as the lock owner or root to mistakenly consider the lock stale and remove the live marker, resulting in two processes simultaneously holding the lock and potentially corrupting the protected resource. The issue arises when the marker file is created with group or other write permissions, typically due to an explicit mode or permissive umask settings in a sticky or non-removable directory.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-rfpc-qcw5-3pc4 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112939 (opens in a new tab)
- github.com/tox-dev/filelock/pull/836 (opens in a new tab)
- github.com/tox-dev/filelock/commit/eeceaa846cbe4df72718d94c8371ca1ab8f5b3cc (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)