Skip to main content
CVE-2026-112938VulnerabilityPublished

scrapy · filelock: StrictSoftFileLock follows a symbolic link swapped in at <path>.filelock and creates claim files in a

Affects scrapySource GCVE Database

0
Compare

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

CVSS 3.1 base score
5.8Medium
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
Homebrewscrapypkg:brew/scrapyOther threatsAffected
  • >=2.18.0 <2.19.0_2
Fixed in
  • 2.19.0_2

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

Community reviews

Loading reviews…