Python Requests & urllib3 Security in 2026: CVE-2025-66471, CVE-2026-21441 & The Decompression Bomb ChainSécurité Python Requests & urllib3 en 2026 : CVE-2025-66471, CVE-2026-21441 & La Chaîne des Bombes de Décompression

The Python requests library — with nearly 200 million downloads per week — powers HTTP communication in a vast majority of Python applications, from web scrapers and API clients to CI/CD pipelines and microservices. Underneath, it relies on urllib3 as its HTTP engine, which itself receives 196 million downloads per week. In 2025 and 2026, this foundational stack received a series of security patches addressing denial-of-service vulnerabilities, credential leakage, and SSRF risks. Two of these — CVE-2025-66471 (CVSS 8.9) and CVE-2026-21441 (CVSS 7.5) — form a decompression bomb chain that can crash Python applications processing responses from untrusted servers.

La bibliothèque Python requests — avec près de 200 millions de téléchargements par semaine — alimente la communication HTTP dans une grande majorité des applications Python, des scrapers aux clients API en passant par les pipelines CI/CD et les microservices. Dessous, elle s’appuie sur urllib3 comme moteur HTTP, lui-même téléchargé 196 millions de fois par semaine. En 2025 et 2026, cette pile fondamentale a reçu une série de correctifs de sécurité couvrant des vulnérabilités de déni de service, de fuite de credentials et de SSRF. Deux d’entre elles — CVE-2025-66471 (CVSS 8.9) et CVE-2026-21441 (CVSS 7.5) — forment une chaîne de bombes de décompression pouvant crasher les applications Python qui traitent des réponses de serveurs non fiables.

Why urllib3 and requests are everywhere in Python projects

Pourquoi urllib3 et requests sont partout dans les projets Python

The requests library is Python’s de facto HTTP client, present in virtually every Python project that communicates over HTTP. It wraps urllib3, which provides connection pooling, TLS handling, retry logic, and streaming decompression. The critical security implication: a vulnerability in urllib3 is a vulnerability in requests, and in every library that builds on top of either of them — including boto3/botocore (AWS SDK), pip itself, and hundreds of popular packages.

La bibliothèque requests est le client HTTP de facto de Python, présent dans pratiquement tout projet Python communiquant en HTTP. Elle encapsule urllib3, qui fournit le pooling de connexions, la gestion TLS, la logique de retry et la décompression en streaming. L’implication sécurité critique : une vulnérabilité dans urllib3 est une vulnérabilité dans requests, et dans toutes les bibliothèques qui s’appuient dessus — boto3/botocore (AWS SDK), pip lui-même, et des centaines de packages populaires.

This dependency chain means that even if you don’t use requests directly, you may be running a vulnerable version of urllib3 as a transitive dependency. Both packages ship with most Python distributions and are bundled in cloud functions, Docker images, and enterprise software like IBM Maximo, IBM Watson, and Red Hat OpenShift — which have all published security advisories for the 2025–2026 urllib3 CVEs.

Cette chaîne de dépendances signifie que même si vous n’utilisez pas requests directement, vous exécutez peut-être une version vulnérable de urllib3 comme dépendance transitive. Les deux packages sont livrés avec la plupart des distributions Python et sont embarqués dans les fonctions cloud, les images Docker et les logiciels d’entreprise comme IBM Maximo, IBM Watson et Red Hat OpenShift — qui ont tous publié des avis de sécurité pour les CVE urllib3 2025–2026.

The 2025–2026 urllib3 Decompression Bomb Chain: CVE-2025-66471 & CVE-2026-21441

La chaîne de bombes de décompression urllib3 2025–2026 : CVE-2025-66471 & CVE-2026-21441

Both CVEs target the same root weakness: urllib3’s failure to limit the amount of data produced when decompressing HTTP responses. The attack pattern — a "decompression bomb" — involves sending a tiny compressed payload (a few kilobytes) that expands to gigabytes of data when decompressed, exhausting the client’s memory and CPU. What makes these two CVEs particularly dangerous together is that the first fix was incomplete, and the second CVE exploits the remaining gap specifically in redirect scenarios.

Les deux CVE ciblent la même faiblesse fondamentale : l’échec de urllib3 à limiter la quantité de données produite lors de la décompression des réponses HTTP. Le modèle d’attaque — une « bombe de décompression » — consiste à envoyer une petite charge compressée (quelques kilo-octets) qui se développe en gigaoctets lors de la décompression, épuisant la mémoire et le CPU du client. Ce qui rend ces deux CVE particulièrement dangereuses ensemble, c’est que le premier correctif était incomplet, et la deuxième CVE exploite le reste de la faille spécifiquement dans les scénarios de redirection.

The patch timeline shows how the incomplete fix created a second vulnerability window. Organizations running urllib3 versions between 2.6.0 and 2.6.2 believed they were protected from decompression bombs after patching for CVE-2025-66471, but remained vulnerable to CVE-2026-21441 via the redirect path.

La chronologie des correctifs montre comment le correctif incomplet a créé une deuxième fenêtre de vulnérabilité. Les organisations exécutant des versions urllib3 entre 2.6.0 et 2.6.2 croyaient être protégées contre les bombes de décompression après avoir appliqué le correctif de CVE-2025-66471, mais restaient vulnérables à CVE-2026-21441 via le chemin de redirection.

CVE-2023-32681: The Proxy-Authorization Header Leak Still Lurking in Your Dependencies

CVE-2023-32681 : La Fuite du Header Proxy-Authorization Toujours Présente dans Vos Dépendances

While the decompression bomb chain is the most active concern in 2026, a credential leakage vulnerability from 2023 continues to affect Python projects that haven’t fully updated. CVE-2023-32681 (CVSS 6.1) causes the requests library to leak Proxy-Authorization headers to destination servers during HTTPS redirects. This means any credentials embedded in the proxy URL — such as https://username:password@proxy:8080 — are forwarded to the final destination server where they could be logged, stolen, or exploited.

Alors que la chaîne de bombes de décompression est la préoccupation la plus active en 2026, une vulnérabilité de fuite de credentials de 2023 continue d’affecter les projets Python qui ne se sont pas entièrement mis à jour. CVE-2023-32681 (CVSS 6.1) provoque la fuite par la bibliothèque requests des headers Proxy-Authorization vers les serveurs de destination lors des redirections HTTPS. Cela signifie que les credentials embarqués dans l’URL proxy — comme https://username:password@proxy:8080 — sont transmis au serveur de destination finale où ils pourraient être loggés, volés ou exploités.

CVE-2024-37891 is the urllib3 counterpart: the library similarly failed to strip the Proxy-Authorization header on cross-origin redirects, affecting versions below 2.2.2. Together, CVE-2023-32681 and CVE-2024-37891 mean that both layers of the stack — requests and urllib3 — were independently leaking proxy credentials for over a decade before the fixes landed.

CVE-2024-37891 est la contrepartie urllib3 : la bibliothèque échouait également à supprimer le header Proxy-Authorization lors des redirections cross-origin, affectant les versions inférieures à 2.2.2. Ensemble, CVE-2023-32681 et CVE-2024-37891 signifient que les deux couches de la pile — requests et urllib3 — faisaient indépendamment fuiter les credentials proxy pendant plus d’une décennie avant que les correctifs n’arrivent.

Safe Versions: What You Need to Upgrade To

Versions Sûres : Ce Vers Quoi Vous Devez Migrer

Here is the minimum safe version matrix for the full urllib3/requests stack as of April 2026, based on active Red Hat, IBM, and Fedora security advisories:

Voici la matrice de versions minimales sûres pour la pile urllib3/requests complète en avril 2026, basée sur les avis de sécurité actifs de Red Hat, IBM et Fedora :

To check your current versions and update:

Pour vérifier vos versions actuelles et mettre à jour :

# Check current versions
pip show urllib3 requests certifi

# Upgrade to safe versions
pip install "urllib3>=2.6.3" "requests>=2.32.5" "certifi>=2026.1.4"

# Or upgrade all at once
pip install --upgrade urllib3 requests certifi

# Check for known vulnerabilities in your full dependency tree
pip-audit  # pip install pip-audit

Vulnerable Code Patterns & How to Fix Them

Patterns de Code Vulnérables & Comment les Corriger

Beyond upgrading, certain coding patterns expose your application to decompression bomb attacks even on patched versions, especially when dealing with untrusted remote servers. Here are the three most common risky patterns and their safe alternatives:

Au-delà de la mise à niveau, certains patterns de code exposent votre application aux attaques par bombe de décompression même sur des versions patchées, en particulier lors de communications avec des serveurs distants non fiables. Voici les trois patterns risqués les plus courants et leurs alternatives sûres :

import urllib3

http = urllib3.PoolManager()
# Streaming from untrusted URL — CVE-2026-21441 triggers on redirect
resp = http.request("GET", untrusted_url, preload_content=False)
for chunk in resp.stream(512):  # bomb decompressed before this loop
    process(chunk)

import urllib3

http = urllib3.PoolManager()
# Option A: upgrade to urllib3 >= 2.6.3 (fix applied)
# Option B: disable redirects for untrusted sources
resp = http.request(
    "GET", untrusted_url,
    preload_content=False,
    redirect=False,   # disables redirect decompression path
)
for chunk in resp.stream(512):
    process(chunk)

import requests

proxies = {
    "https": "https://user:secret@proxy.corp.example:8080"
}
# On HTTPS redirect, "user:secret" leaks to the destination server
r = requests.get("https://api.example.com/data", proxies=proxies)

import requests
from requests.auth import HTTPProxyAuth

# Safe: use auth object, NOT credentials in URL
proxies = {"https": "http://proxy.corp.example:8080"}
auth = HTTPProxyAuth("user", "secret")
r = requests.get("https://api.example.com/data", proxies=proxies, auth=auth)
# Credentials stay in the CONNECT request, not forwarded on redirect

import requests

# verify=False disables ALL certificate validation
# Makes MITM attacks trivial — attacker can intercept all traffic
r = requests.get("https://api.example.com/", verify=False)

import requests

# For internal PKI: provide your custom CA bundle
r = requests.get("https://internal.example.com/", verify="/etc/ssl/certs/ca-bundle.crt")

# For public APIs: always use default (True)
r = requests.get("https://api.example.com/")  # verify=True by default

Detecting Vulnerable urllib3 & requests in Your CI/CD Pipeline

Détecter urllib3 & requests Vulnérables dans Votre Pipeline CI/CD

The real challenge with urllib3 and requests vulnerabilities is that they are frequently installed as transitive dependencies — your project doesn’t directly list them in requirements.txt, but another dependency pulls them in at a version that has known CVEs. Standard pip install doesn’t warn you. Standard pip audit helps, but only catches what’s in your current environment.

Le vrai défi avec les vulnérabilités urllib3 et requests est qu’elles sont fréquemment installées comme dépendances transitives — votre projet ne les liste pas directement dans requirements.txt, mais une autre dépendance les tire dans une version ayant des CVE connues. Le pip install standard ne vous avertit pas. Le pip audit standard aide, mais ne capture que ce qui est dans votre environnement actuel.

# Install pip-audit
pip install pip-audit

# Audit current environment
pip-audit

# Output format for CI/CD (JSON)
pip-audit --format json --output audit-report.json

# Audit from requirements.txt (without installing)
pip-audit -r requirements.txt

# Check transitive deps — what version of urllib3 is actually installed?
pip show urllib3 | grep -E "Name|Version|Required-by"

# .github/workflows/security.yml
name: Security Audit
on: [push, pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install pip-audit
      - run: pip-audit -r requirements.txt --strict
        # --strict exits non-zero if any CVE found

For projects using Poetry or pip-tools, pin urllib3 explicitly to a safe version in your lock file to prevent automatic resolution to a vulnerable version when a dependency is updated:

Pour les projets utilisant Poetry ou pip-tools, épinglez explicitement urllib3 à une version sûre dans votre fichier de verrouillage pour éviter la résolution automatique vers une version vulnérable lors de la mise à jour d’une dépendance :

[tool.poetry.dependencies]
python = "^3.10"
urllib3 = ">=2.6.3"     # pin minimum safe version
requests = ">=2.32.5"   # pin minimum safe version
certifi = ">=2026.1.4"  # updated CA bundle

Enterprise Impact: Red Hat, IBM, and Fedora Patches

Impact Enterprise : Correctifs Red Hat, IBM et Fedora

The depth of the enterprise patching activity for the 2025–2026 urllib3 CVEs illustrates how widely deployed these libraries are across critical infrastructure. Red Hat alone issued at least six separate security advisories (RHSA) covering different product lines affected by CVE-2026-21441:

L’ampleur de l’activité de patching enterprise pour les CVE urllib3 2025–2026 illustre à quel point ces bibliothèques sont déployées dans les infrastructures critiques. Red Hat seul a émis au moins six avis de sécurité (RHSA) distincts couvrant différentes lignes de produits affectées par CVE-2026-21441 :

IBM published specific security bulletins for: IBM Maximo Application Suite (Monitor Component), IBM Maximo Manage, and IBM watsonx.data — confirming that CVE-2026-21441 was present in production enterprise deployments of urllib3-2.6.2 and earlier. The Fedora Project released advisory 2026-724d1b1044 covering the same CVE for Fedora 43 users of python-urllib3.

IBM a publié des bulletins de sécurité spécifiques pour : IBM Maximo Application Suite (composant Monitor), IBM Maximo Manage, et IBM watsonx.data — confirmant que CVE-2026-21441 était présente dans des déploiements enterprise de urllib3-2.6.2 et antérieurs. Le projet Fedora a publié l’avis 2026-724d1b1044 couvrant la même CVE pour les utilisateurs Fedora 43 de python-urllib3.

SSRF Risks When Using requests with User-Supplied URLs

Risques SSRF lors de l’Utilisation de requests avec des URLs Fournies par les Utilisateurs

Beyond the CVEs, a class of vulnerabilities that frequently affects Python applications using requests is Server-Side Request Forgery (SSRF). When your application accepts a URL from a user or external API and passes it directly to requests.get(), an attacker can supply internal network addresses — such as http://169.254.169.254/latest/meta-data/ (AWS instance metadata) or http://localhost:6379 (Redis) — to probe your internal infrastructure.

Au-delà des CVE, une classe de vulnérabilités qui affecte fréquemment les applications Python utilisant requests est la Server-Side Request Forgery (SSRF). Quand votre application accepte une URL d’un utilisateur ou d’une API externe et la passe directement à requests.get(), un attaquant peut fournir des adresses de réseau interne — comme http://169.254.169.254/latest/meta-data/ (métadonnées d’instance AWS) ou http://localhost:6379 (Redis) — pour sonder votre infrastructure interne.

import requests
from flask import request, jsonify

# API endpoint that fetches a URL provided by the user
def fetch_url():
    url = request.args.get("url")  # attacker sends: http://169.254.169.254/latest/meta-data/iam/
    r = requests.get(url, timeout=5)  # SSRF — leaks cloud credentials
    return jsonify({"content": r.text})

import ipaddress
import socket
from urllib.parse import urlparse
import requests

ALLOWED_SCHEMES = {"http", "https"}
BLOCKED_HOSTS = {"localhost", "127.0.0.1", "0.0.0.0", "::1"}
BLOCKED_IP_RANGES = [
    ipaddress.ip_network("169.254.0.0/16"),  # link-local (AWS metadata)
    ipaddress.ip_network("10.0.0.0/8"),       # private RFC 1918
    ipaddress.ip_network("172.16.0.0/12"),    # private RFC 1918
    ipaddress.ip_network("192.168.0.0/16"),   # private RFC 1918
]

def is_safe_url(url: str) -> bool:
    parsed = urlparse(url)
    if parsed.scheme not in ALLOWED_SCHEMES:
        return False
    hostname = parsed.hostname
    if not hostname or hostname in BLOCKED_HOSTS:
        return False
    try:
        ip = ipaddress.ip_address(socket.gethostbyname(hostname))
        if ip.is_private or ip.is_loopback or ip.is_link_local:
            return False
        if any(ip in net for net in BLOCKED_IP_RANGES):
            return False
    except (socket.gaierror, ValueError):
        return False
    return True

def fetch_url():
    url = request.args.get("url", "")
    if not is_safe_url(url):
        return jsonify({"error": "URL not allowed"}), 400
    r = requests.get(url, timeout=5, allow_redirects=False)  # disable redirects for safety
    return jsonify({"content": r.text})

Full Security Hardening Checklist for Python HTTP Clients

Liste de Contrôle Complète de Durcissement pour les Clients HTTP Python

• ✓ Upgrade urllib3 to 2.6.3+ — fixes CVE-2025-66471 (CVSS 8.9) and CVE-2026-21441 (CVSS 7.5). The minimum you must do. Mettre à niveau urllib3 vers 2.6.3+ — corrige CVE-2025-66471 (CVSS 8.9) et CVE-2026-21441 (CVSS 7.5). Le minimum à faire.
• ✓ Upgrade requests to 2.32.5+ — fixes CVE-2023-32681 (proxy header leak), CVE-2024-35195 (verify=False persistence bug). Mettre à niveau requests vers 2.32.5+ — corrige CVE-2023-32681 (fuite header proxy), CVE-2024-35195 (bug persistance verify=False).
• ✓ Update certifi to 2026.1.4+ — ensures TLS validation uses the current CA bundle. Old certifi = outdated trust store. Mettre à jour certifi vers 2026.1.4+ — garantit que la validation TLS utilise le bundle CA actuel. Vieux certifi = magasin de confiance obsolète.
• ✓ Set redirect=False for requests to untrusted sources in streaming mode, even on patched versions — defense in depth. Configurer redirect=False pour les requêtes vers des sources non fiables en mode streaming, même sur les versions patchées — défense en profondeur.
• ⚠ Never use verify=False in production — disables all TLS certificate validation and enables MITM attacks. Use custom CA bundles for internal PKI instead. Ne jamais utiliser verify=False en production — désactive toute validation de certificat TLS et permet les attaques MITM. Utilisez des bundles CA personnalisés pour la PKI interne.
• ⚠ Validate user-supplied URLs before passing them to requests.get() — block private IPs, link-local ranges (169.254.x.x), and localhost to prevent SSRF. Valider les URLs fournies par l’utilisateur avant de les passer à requests.get() — bloquer les IP privées, les plages link-local (169.254.x.x) et localhost pour prévenir les SSRF.
• ✓ Pin urllib3 as a direct dependency in pyproject.toml or requirements.txt — prevents resolution to a vulnerable version via transitive dependency updates. Épingler urllib3 comme dépendance directe dans pyproject.toml ou requirements.txt — empêche la résolution vers une version vulnérable lors des mises à jour de dépendances transitives.
• ✓ Run pip-audit in CI — automated check on every commit. Add --strict to block merges when CVEs are found in the dependency tree. Exécuter pip-audit en CI — vérification automatisée à chaque commit. Ajoutez --strict pour bloquer les merges quand des CVE sont trouvées dans l’arbre de dépendances.
• ✓ Set explicit timeouts — always use requests.get(url, timeout=10). Without a timeout, a slow server can hold connections open indefinitely, enabling resource exhaustion independently of decompression bombs. Définir des timeouts explicites — toujours utiliser requests.get(url, timeout=10). Sans timeout, un serveur lent peut maintenir les connexions ouvertes indéfiniment, permettant l’épuisement des ressources indépendamment des bombes de décompression.

Frequently Asked Questions

Questions fréquentes