Fuite de mot de passe proxy via le client HTTP : CVE dans curl, libsoup et requests

Le mot de passe du proxy est généralement gardé secret : il n'est pas affiché dans les captures d'écran, n'est pas commité dans git, et est conservé dans des variables d'environnement. Mais en 2026, il a été découvert qu'il pouvait être divulgué par le client HTTP lui-même. Entre avril et juillet, plusieurs vulnérabilités ont été découvertes dans curl, libcurl et libsoup, où l'en-tête Proxy-Authorization est envoyé non pas au bon proxy, mais parfois directement au site cible. Ci-dessous, une analyse des conditions dans lesquelles cela se produit, ainsi qu'un guide étape par étape pour vérifier votre stack.

Ce qui s'est passé : quatre fuites en quatre mois

Tous ces bugs fonctionnent de la même manière : le client mémorise le nom d'utilisateur et le mot de passe d'un proxy et les envoie par erreur plus loin dans la chaîne.

• CVE-2026-6253 (curl et libcurl 7.14.1–8.19.0). Si des proxies différents sont configurés pour http:// et https://, le premier exige un mot de passe, tandis que le second non, alors lors d'une redirection avec changement de schéma, curl enverra les informations d'identification du premier proxy au second. Les données sont envoyées en base64, c'est-à-dire en texte clair. Corrigé dans curl 8.20.0, publié le 29 avril 2026. Le curl en ligne de commande est également vulnérable, pas seulement la bibliothèque.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). L'application réutilise un handle pour plusieurs requêtes, les proxies sont pris dans les variables d'environnement, et l'autorisation se fait par Digest. Dans ce cas, l'en-tête Proxy-Authorization pour le proxy A est envoyé au proxy B, qui peut le répéter pour se faire passer pour vous. Corrigé dans curl 8.21.0 du 24 juin 2026. Le curl en ligne de commande n'est pas affecté. Un bug presque identique est décrit dans CVE-2026-7168, la différence réside uniquement dans la manière dont le proxy est sélectionné.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup met en cache les informations d'identification du proxy sans les lier à l'adresse host:port. Lorsque les paramètres du proxy changent (paramètres système, WPAD), l'ancien en-tête est envoyé au nouveau proxy. Publié le 21 juillet 2026, évaluation faible.
• CVE-2026-66339 (libsoup, tunnels CONNECT). Après l'établissement d'un tunnel CONNECT via un proxy HTTP, libsoup attache Proxy-Authorization aux prochaines requêtes HTTPS à l'intérieur du tunnel. L'en-tête est déjà visible par le serveur cible. CVSS 6.5, publié le 24 juillet 2026.

L'histoire n'est pas nouvelle. Dans la bibliothèque Python requests, de la version 2.3.0 à 2.31.0 (CVE-2023-32681), l'en-tête Proxy-Authorization lors d'une redirection vers HTTPS était envoyé au serveur cible si le nom d'utilisateur et le mot de passe étaient inscrits directement dans l'URL du proxy. Dans urllib3, jusqu'à 1.26.19 et 2.2.2 (CVE-2024-37891), l'en-tête défini manuellement, et non par le support intégré du proxy, n'était pas supprimé lors d'une redirection vers un domaine étranger.

Pourquoi est-ce important pour le travail avec des proxies

Avec un proxy payant, le mot de passe équivaut à de l'argent. Celui qui l'obtient utilise votre trafic tant que vous ne changez pas d'accès. Lorsqu'il s'agit de payer pour des gigaoctets, c'est une facture directe, et avec un accès partagé pour toute l'équipe, cela implique également les actions d'autres personnes depuis votre IP.

Les scénarios les plus vulnérables se présentent comme suit :

• Parseurs et surveillances, qui suivent automatiquement les redirections. Le site cible ou une redirection intermédiaire peut détourner la requête vers un domaine qui collecte les en-têtes.
• Scripts avec plusieurs proxies : différents proxies pour différents schémas, changement de proxy entre les requêtes sur une même connexion, mélange de « proxies avec mot de passe » et « proxies sans mot de passe ».
• Processus de longue durée sur des serveurs Linux, où libcurl et libsoup sont livrés avec des paquets système et sont mis à jour avec la distribution, et non avec votre code.
• Réseaux d'entreprise avec WPAD et fichiers PAC : le proxy change sans l'intervention de l'application, et c'est précisément ce cas qui est décrit dans CVE-2026-12547.

Comment vérifier votre stack : étape par étape

1. Découvrez la véritable version de libcurl, et pas seulement celle de curl en ligne de commande. La commande curl -V affiche les deux, mais l'application peut être construite avec sa propre copie de la bibliothèque. Pour Python avec pycurl, exécutez python -c "import pycurl; print(pycurl.version)", pour PHP, appelez curl_version(). Limite de sécurité : 8.21.0 et plus récent ou branches corrigées 8.20.1+, 8.16.1+ et 8.14.2+.
2. Vérifiez les dépendances Python. Exécutez pip show requests urllib3. Vous avez besoin de requests d'au moins 2.31.0 et urllib3 d'au moins 1.26.19 (branche 1.x) ou 2.2.2 (branche 2.x). Si la dépendance arrive de manière transitive, regardez pip list à l'intérieur du même environnement où le parseur fonctionne.
3. Vérifiez libsoup sur Linux. Cela concerne les applications GNOME, WebKitGTK et tout ce qui est construit sur cette stack. Mettez à jour le paquet via le gestionnaire de distribution et vérifiez le bulletin de sécurité de votre distribution : dans les fiches de ces CVE, Red Hat indique que RHEL 6–10 sont concernés.
4. Trouvez dans le code l'installation manuelle de l'en-tête. Recherchez Proxy-Authorization dans tout le dépôt. Si l'en-tête est défini manuellement, et non par le mécanisme standard du client proxy (proxies= dans requests, ProxyManager dans urllib3, CURLOPT_PROXYUSERPWD dans libcurl), cela est un candidat à la fuite lors de la redirection.
5. Trouvez la réutilisation des connexions lors du changement de proxy. Un handle libcurl, une session requests ou un agent HTTP, à travers lesquels des requêtes avec différents proxies passent tour à tour. La solution la plus simple : une session séparée pour chaque proxy.
6. Désactivez les redirections automatiques là où elles ne sont pas nécessaires. Dans requests, c'est allow_redirects=False, dans urllib3 redirect=False, dans curl, ne mettez pas -L et CURLOPT_FOLLOWLOCATION. Ainsi, les 3xx sont traités manuellement, et vous décidez vous-même où aller ensuite. C'est précisément cette solution de contournement que proposent les auteurs de requests et urllib3.
7. Effectuez un test en direct pour détecter les fuites. Mettez en place un simple serveur HTTP qui imprime tous les en-têtes reçus, et faites-y une redirection vers un second serveur identique. Faites passer votre parseur avec proxy à travers un scénario réel, y compris le changement de schéma de http à https. Si l'un des serveurs a vu Proxy-Authorization, la fuite est confirmée dans votre code, et non en théorie.

Les pièges

• Les images Docker vivent leur propre vie. Vous avez mis à jour curl sur l'hôte, mais le parseur fonctionne dans un conteneur avec une ancienne image de base. Il faut vérifier à l'intérieur du conteneur : docker exec <conteneur> curl -V.
• Le curl en ligne de commande et libcurl se mettent à jour différemment. CVE-2026-8927 n'affecte pas le curl en ligne de commande, tandis que CVE-2026-6253 l'affecte. Un curl -V récent dans le terminal ne dit rien sur la bibliothèque avec laquelle votre PHP ou Python est construit.
• Digest ne sauve pas. Oui, avec Digest, le mot de passe n'est pas envoyé en texte clair. Mais dans CVE-2026-8927, l'attaquant n'a même pas besoin du mot de passe : l'en-tête intercepté est répété tant que le nonce est valide.
• Le mot de passe dans l'URL est pratique, mais dangereux. La fuite dans requests se produisait précisément lorsque les informations d'identification étaient inscrites dans l'adresse du proxy sous la forme user:pass@host:port. Ce n'est pas une raison pour abandonner ce format, mais une raison de garder les bibliothèques à jour.
• La redirection peut venir d'une source non ciblée. Les pages de captcha, les bannières de consentement, les raccourcisseurs de liens et les CDN répondent également par des 3xx. Plus il y a de « suivis de liens » dans le crawler, plus la surface d'attaque est large.

Comment limiter les dommages si le mot de passe s'échappe

Il est impossible d'éliminer complètement la fuite : demain, une nouvelle CVE sera publiée. Il est donc important de savoir combien coûte une fuite.

• Un projet, un accès. Ne gardez pas un identifiant commun pour tous les parseurs. Dans ProxyCove, chaque proxy acheté reçoit une paire unique de nom d'utilisateur et de mot de passe, donc l'accès compromis d'un script n'ouvre pas le trafic des autres.
• Ne gardez pas plus de trafic que nécessaire sur un seul accès. Alimentez progressivement selon les besoins, et non pour six mois à l'avance.
• Surveillez la consommation. Une augmentation soudaine du trafic sans augmentation du nombre de tâches est le premier signe que quelqu'un d'autre utilise votre accès.
• Changez le mot de passe immédiatement en cas de soupçon et selon un calendrier. Comment organiser cela sans temps d'arrêt est expliqué dans le guide sur la rotation des mots de passe du proxy.

Quel type de proxy choisir et quel est son rapport

La fuite ne dépend pas du type de proxy : le bug réside dans le client. En revanche, le coût de la fuite dépend. Les proxies de datacenter sont moins chers par gigaoctet, et pour le parsing de sites simples avec des redirections fréquentes, il est raisonnable de les garder séparés du trafic coûteux. Les proxies résidentiels doivent être attribués aux tâches où ils sont réellement nécessaires, et pour eux, il faut créer des accès séparés avec les redirections automatiques désactivées. Les proxies mobiles, les plus chers par gigaoctet, doivent être conservés dans le code avec un minimum de dépendances externes et obligatoirement avec une vérification des versions des bibliothèques à chaque compilation.

Conclusion

Le mot de passe du proxy peut fuiter sans piratage, sans virus et sans erreur humaine : il suffit d'un libcurl obsolète, d'une redirection vers un domaine étranger et d'une connexion réutilisée. La liste de contrôle est courte : curl et libcurl à partir de 8.21.0, requests à partir de 2.31.0, urllib3 à partir de 1.26.19 ou 2.2.2, libsoup à jour, une session séparée pour chaque proxy, redirections sous contrôle et un test en direct pour détecter les fuites. De plus, un accès séparé pour chaque projet, afin qu'une fuite ne coûte qu'un script, et non tout le solde.