scrapy · filelock: StrictSoftFileLock follows a symbolic link swapped in at <path>.filelock and creates claim files in a
Affects scrapySource GCVE Database
Not known to be exploited · CVSS 5.8 Medium : upgrade to 2.19.0_2 when convenient.
Data as of 30 Oct 2026, 05:45 UTC
- Patch
- Available – fixed in 2.19.0_2
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:HExploitation evidence
Disclosed: evidence found.
CVE published 29 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 patch is available in filelock version 2.19.0_2 that fixes this issue. Users should upgrade to this version or later. The vulnerability depends on the ability to rename the .filelock directory in a shared directory without the sticky bit; using sticky bits on shared directories (e.g., /tmp) can reduce the attack surface by restricting who can rename the directory. No other specific mitigations are indicated. Since a fix exists, upgrading is the recommended action.
Description
A vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local user with write access to a shared directory to exploit a race condition involving symbolic links in the lock coordination directory. By swapping the .filelock directory with a symbolic link between an lstat check and subsequent operations, the attacker can cause the lock user to create claim files in a directory chosen by the attacker. This can lead to denial of service by causing stranded claims that block other processes from acquiring the lock until manually force-broken.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-m462-7rxw-wvpg (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)