scrapy · filelock: SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into
Affects scrapySource GCVE Database
Not known to be exploited · CVSS 3.3 Low : 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 | 3.3 |
|---|
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% 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:N/I:L/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 patch is available in filelock version 2.19.0_2 that fixes this vulnerability. Users should upgrade to this version or later to remediate the issue. No additional mitigation is required if the patch is applied. The vulnerability requires local write access to the lock's parent directory or creation of the lock directory in a sticky directory by the attacker, so restricting such access also reduces risk.
Description
CVE-2026-112941 is a local integrity vulnerability in filelock's SoftReadWriteLock and AsyncSoftReadWriteLock implementations. A local user with write access to the lock's parent directory can replace the lock directory tree with symbolic links after the lock's initial acquire, causing the lock user process to write lock records through the symlinked paths. This results in the lock user's process deleting or replacing files in directories it can write, such as a private git repository, disrupting its operation. The vulnerability requires specific conditions involving sticky directories or writable parent directories and affects filelock versions 4.1.0 through 4.2.0. The CVSS score is low (3.3) due to local attack vector, low integrity impact, and no confidentiality or availability impact. A fix is available in version 2.19.0_2.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-wfhq-q4j2-c37m (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112941 (opens in a new tab)
- github.com/tox-dev/filelock/pull/842 (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)