virtualenvwrapper · filelock: SoftFileLock stale-break restore follows a swapped-in symbolic link and hard-links a file of the user
Affects virtualenvwrapperSource GCVE Database
Not known to be exploited · CVSS 5.3 Medium : upgrade to 6.1.1_4 when convenient.
Data as of 30 Oct 2026, 06:59 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 6.1.1_4
CVSS:3.1/AV:L/AC:H/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 virtualenvwrapper to 6.1.1_4.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewvirtualenvwrapperpkg:brew/virtualenvwrapperOther 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 4.2.1 (fixed in 6.1.1_4 for virtualenvwrapper). Users should upgrade to this fixed version to remediate the vulnerability. The issue arises only if the lock directory is writable by another user and lacks the sticky bit; ensuring the lock directory and its ancestors are owned by the lock user or root and are not writable by others or have the sticky bit set can mitigate the risk. Additionally, Linux kernel settings fs.protected_hardlinks and fs.protected_symlinks provide some protection in sticky directories. No other actions are required once patched.
Description
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user who can write to a shared lock directory without the sticky bit to exploit a race condition involving symbolic links and hard links. This can lead to the creation of a hard link to a file owned by the lock user, exposing file metadata and enabling the attacker to manipulate the file's name. On version 4.2.0, this can result in truncation of the lock user's file. The issue arises due to the restore branch of the stale-lock break process following symbolic links when creating hard links, which is affected by changes in CPython 3.12 and later on Linux and macOS. The vulnerability requires specific conditions including a writable non-sticky directory and repeated lock acquisition by the lock user.
References
- github.com/tox-dev/filelock/security/advisories/GHSA-crv4-6mhj-j5jh (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-112914 (opens in a new tab)
- github.com/tox-dev/filelock/pull/843 (opens in a new tab)
- github.com/tox-dev/filelock/commit/740ff666b62a88496c8d7394e4e6230605e4d62b (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)