poetry · filelock: StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing
Affects poetrySource GCVE Database
Not known to be exploited · CVSS 6.3 Medium : upgrade to 2.5.1_1 when convenient.
Data as of 30 Oct 2026, 08:30 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 6.3 |
|---|
- Patch
- Available – fixed in 2.5.1_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 poetry to 2.5.1_1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewpoetrypkg:brew/poetryOther 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 poetry version 2.5.1_1 that fixes this vulnerability. Users should upgrade to this version or later. Until patched, avoid using new lock paths in shared sticky directories where other local users can create files before the lock user. The vulnerability depends on the protocol directory not existing at first acquire, so reusing existing lock paths with intact protocol directories is not vulnerable. No other mitigations are documented or recommended by the vendor.
Description
A vulnerability in the filelock library versions 3.30.0 through 4.2.0 allows a local unprivileged user to pre-create a protocol directory used by StrictSoftFileLock and SoftReadWriteLock. This causes the lock to adopt a directory owned by the attacker, enabling them to interfere with lock claims, potentially allowing concurrent writers and denial of service conditions. The flaw requires the attacker to create the directory before the lock user's first acquire on that path, typically in shared sticky directories like /tmp. The vulnerability has a medium CVSS score of 6.3 and impacts integrity and availability but not confidentiality. A fix is available in version 2.5.1_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)