scrapy · filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path
Affects scrapySource GCVE Database
Not known to be exploited · CVSS 6.1 Medium : upgrade to 2.19.0_2 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 12% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.19.0_2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/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 scrapy to 2.19.0_2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewscrapypkg:brew/scrapyOther 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 2.19.0_2. Users should upgrade to this version or later to remediate the vulnerability. The vulnerability depends on directory permissions and kernel settings; ensuring directories containing lock files have the sticky bit set and that the Linux kernel setting fs.protected_hardlinks is enabled (set to 1) can reduce risk. No other specific mitigations are indicated.
Description
The UnixFileLock component in the FileLock and AsyncFileLock implementations on Unix truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path before the lock user's next acquire. This can lead to unintended file truncation and permission changes, allowing the other user to read and modify the file contents thereafter. The vulnerability affects all filelock releases up to and including 4.2.0, with the chmod behavior introduced since version 3.10.2. Exploitation requires local access and specific directory permissions or kernel settings. The issue is fixed in filelock version 2.19.0_2.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112909 (opens in a new tab)
- github.com/tox-dev/filelock/pull/835 (opens in a new tab)
- github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a (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)