Skip to main content
CVE-2026-112914VulnerabilityPublished

virtualenvwrapper · filelock: SoftFileLock stale-break restore follows a swapped-in symbolic link and hard-links a file of the user

Affects virtualenvwrapperSource GCVE Database

0
Compare
Authoritative record:CVE-2026-112914· Medium 5.3

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

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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 20 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 virtualenvwrapper to 6.1.1_4.

Affected software

ProductAffectedFixed in
Homebrewvirtualenvwrapperpkg:brew/virtualenvwrapperOther threatsAffected
  • >=6.1.1_3 <6.1.1_4
Fixed in
  • 6.1.1_4

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

Community reviews

Loading reviews…