CVE-2026-113724
published 2026-10-20CVE-2026-113724: virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the safe_delete() deletion error handler responds to a failed removal…
PriorityP424medium4.5CVSS 3.1
AVLACHPRLUINSUCLILAL
EPSS
0.14%
3.6th percentile
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the safe_delete() deletion error handler responds to a failed removal by reading mode bits with os.lstat(path) and applying owner-write permission with os.chmod(path, ...), which follows a symlink. A planted link inside a read-only directory can therefore cause a victim-owned target outside the destination that is initially not writable by the invoking user to become broadly writable before the retry fails, provided that user owns the target and can change its mode. Another account can use the widened mode only if it can traverse the target's parent directories; root does not reach the demonstrated failure path, and the operation does not itself read the target. This issue is fixed in version 21.14.9.
Affected
25 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| ansible-automation-platform-26 | controller-rhel9 | — | — |
| ansible-automation-platform-26 | eda-controller-rhel9 | — | — |
| ansible-automation-platform-26 | lightspeed-chatbot-rhel9 | — | — |
| ansible-automation-platform-27 | controller-rhel9 | — | — |
| ansible-automation-platform-27 | eda-controller-rhel9 | — | — |
| debian | python-virtualenv | — | — |
| devspaces | udi-rhel9 | — | — |
| openshift-lightspeed | lightspeed-service-api-rhel9 | — | — |
| pypa | virtualenv | < 21.14.9 | 21.14.9 |
| rhai-early-access | docling-serve-cuda-rhel9 | — | — |
| rhoai | odh-feature-server-rhel9 | — | — |
| rhoai | odh-kserve-agent-rhel9 | — | — |
| rhoai | odh-kserve-controller-rhel9 | — | — |
| rhoai | odh-kserve-router-rhel9 | — | — |
| rhoai | odh-kserve-storage-initializer-rhel9 | — | — |
| rhoai | odh-ta-lmes-job-rhel9 | — | — |
| rhoai | odh-training-rocm64-torch28-py312-rhel9 | — | — |
| rhoai | odh-trustyai-nemo-guardrails-server-rhel9 | — | — |
| rhoai | odh-workbench-codeserver-datascience-cpu-py312-rhel9 | — | — |
| rhoai | odh-workbench-jupyter-datascience-cpu-py312-rhel9 | — | — |
| rhoai | odh-workbench-jupyter-pytorch-llmcompressor-cuda-py312-rhel9 | — | — |
| satellite | iop-advisor-backend-rhel9 | — | — |
| satellite | iop-host-inventory-rhel9 | — | — |
| satellite | iop-yuptoo-rhel9 | — | — |
| virtualenv | virtualenv | >= 0 < 21.14.9 | 21.14.9 |
CVSS provenance
nvdv3.14.5MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
vendor_redhat4.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
virtualenv: Deletion recovery can change a symlink target's mode
ghsa·2026-10-21
CVE-2026-113724 [MEDIUM] CWE-59 virtualenv: Deletion recovery can change a symlink target's mode
virtualenv: Deletion recovery can change a symlink target's mode
## Summary
The deletion error handler obtains permission bits with lstat() but applies them through chmod(), which follows
symlinks. On an eligible unlink failure this can change permissions outside the destination.
Anthropic's OSS Scanner reported this as `ANT-2026-UK90QC27` in `virtualenv-20261015-005`, received on 15 October 2026.
## Affected area
Permission recovery after a filesystem deletion error.
## Attacker-controlled input
A deletion must fail on a symbolic-link entry and enter the permission-recovery branch. The invoking user must have
permission to change the target mode. This is conditional error handling, not the normal successful unlink path.
## Affected code
The relevant 21.14.8 source is in
[safe_del
Red Hat
virtualenv: virtualenv: Insecure file permission modification via symlink following
vendor_redhat·2026-10-20·CVSS 4.5
CVE-2026-113724 [MEDIUM] CWE-59 virtualenv: virtualenv: Insecure file permission modification via symlink following
virtualenv: virtualenv: Insecure file permission modification via symlink following
A flaw was found in virtualenv. When cleaning up files, the deletion error-handling routine follows symbolic links when attempting to restore write permissions for removal. A local attacker can exploit this issue by planting a symbolic link pointing to a file owned by the executing user, causing the cleanup operation to unintentionally grant write access to the targeted file. This could allow unauthorized modification of sensitive files.
Mitigation: --- CME Mitigation Guidance (2026-10-20) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonom
No detection rules found.
No public exploits indexed.
2026-10-20
Published