lexicon · filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders
Affects lexiconSource GCVE Database
Not known to be exploited · CVSS 4.7 Medium : upgrade to 3.25.2_5 when convenient.
Data as of 30 Oct 2026, 07:32 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 4.7 |
|---|
- Patch
- Available – fixed in 3.25.2_5
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 lexicon to 3.25.2_5.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewlexiconpkg:brew/lexiconOther 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 filelock version 4.2.1 and later (fixed in 4.2.1, as the input states fixedVersions includes 4.2.1 implicitly beyond 4.2.0). Users should upgrade to a fixed version to remediate this issue. If upgrading is not immediately possible, restricting write access to the lock directory to trusted users and avoiding vulnerable filesystems may reduce risk.
Description
A flaw in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a sticky shared directory (e.g., /tmp) to cause two processes of the lock owner to simultaneously hold the same lock. This occurs due to inode reuse on filesystems like ext4 and xfs, enabling a stale-lock break to remove a live lock file incorrectly. The vulnerability leads to a high integrity impact as concurrent holders can write protected data without detection.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-fq56-3cx3-fjxp (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112935 (opens in a new tab)
- github.com/tox-dev/filelock/pull/843 (opens in a new tab)
- github.com/tox-dev/filelock/commit/740ff666b62a88496c8d7394e4e6230605e4d62b (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)