virtualenv EUVD-2026-105303

Requires a SECOND, separate local user account on the same host (per the description: 'another local account that prepares final entries inside the destination'). That account must pre-create a dangling symbolic link or extra hard link at specific generated paths inside the virtualenv destination - e.g. pyvenv.cfg, activation scripts produced by ViaTemplateActivator, .gitignore, the CACHEDIR.TAG, import-hook .pth files, or bin/ interpreter files - before the legitimate user triggers environment creation. LIMITING FACTORS: the destination parent directory must remain controlled by the environment owner during creation (an attacker who can replace the parent is explicitly out of scope); exploitation is local-only with no network vector; it depends on timing against the victim's virtualenv run (hence AC:H); and the written content is constrained to virtualenv-generated text under the invoking user's permissions, so it is not arbitrary attacker-controlled data. It does NOT apply to ordinary single-user developer machines where no untrusted local account can write into the destination.

This is a genuinely low-to-moderate-priority local privilege/integrity issue, not an internet-facing emergency. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L = 4.5 MEDIUM) is internally consistent with the description: exploitation requires an attacker who already holds a separate local account on the same host (PR:L), and high attack complexity (AC:H) because the attacker must pre-position a dangling symbolic or hard link inside the victim's destination and have the victim then run environment creation, all while the destination parent remains owned by the victim. No EPSS score, KEV entry, SSVC decision, or POC was provided in the input; per the data this is 'no public exploit identified at time of analysis.' All three impact sub-scores are only Low, and the attack is confined to a multi-user host where an untrusted local account can write into the target tree - an uncommon deployment for virtualenv. CONFLICT TO VERIFY: the input Tags label this 'Information Disclosure,' but the description and the CWE-59 (link following) fix describe creating/overwriting files OUTSIDE the requested tree with attacker-chosen paths - an integrity/file-write problem, not confidentiality loss; the 'Information Disclosure' categorization appears mislabeled. Net: real but niche, prioritize on shared/multi-tenant build hosts and CI runners, deprioritize on single-user developer machines.

On a shared Linux build host, a low-privileged local attacker pre-creates a dangling symlink (or hard link) at a path such as pyvenv.cfg or an activation script name inside a directory where a higher-value user is about to create a virtualenv. When that user runs virtualenv, ViaTemplateActivator._generate() and PyEnvCfg.write() follow the planted link instead of replacing it, so virtualenv-generated content is written to an attacker-chosen location outside the intended environment using the victim's permissions. No public exploit code was identified in the provided intelligence.