La filtración de contraseñas de proxy a través del cliente HTTP: CVE en curl, libsoup y requests

La contraseña del proxy generalmente se protege de las personas: no se muestra en capturas de pantalla, no se comitea en git, se mantiene en variables de entorno. Pero en 2026, se descubrió que el propio cliente HTTP puede revelarla. Entre abril y julio, surgieron varias vulnerabilidades en curl, libcurl y libsoup, donde el encabezado Proxy-Authorization se envía al proxy incorrecto, o incluso directamente al sitio objetivo. A continuación, se analiza en qué condiciones ocurre esto y se proporciona una verificación paso a paso de su stack.

Qué sucedió: cuatro filtraciones en cuatro meses

Todos estos errores funcionan de la misma manera: el cliente recuerda el nombre de usuario y la contraseña de un proxy y, por error, los envía más adelante en la cadena.

• CVE-2026-6253 (curl y libcurl 7.14.1–8.19.0). Si se configuran diferentes proxies para http:// y https://, el primero requiere contraseña y el segundo no, al redirigir con un cambio de esquema, curl enviará las credenciales del primer proxy al segundo. Los datos se envían en base64, es decir, en texto claro. Se corrigió en curl 8.20.0, lanzado el 29 de abril de 2026. También es vulnerable el curl de consola, no solo la biblioteca.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). La aplicación reutiliza un handle para varias solicitudes, los proxies se toman de las variables de entorno, y la autorización se realiza mediante Digest. Entonces, el encabezado Proxy-Authorization para el proxy A se envía al proxy B, y este puede repetirlo para hacerse pasar por usted. Se corrigió en curl 8.21.0 del 24 de junio de 2026. El curl de consola no se ve afectado. Un error casi idéntico se describe en CVE-2026-7168, la única diferencia es cómo se elige el proxy.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup almacena en caché las credenciales del proxy sin vincularlas a la dirección host:port. Cuando se cambian las configuraciones del proxy (parámetros del sistema, WPAD), el antiguo encabezado se envía al nuevo proxy. Publicado el 21 de julio de 2026, con una evaluación baja.
• CVE-2026-66339 (libsoup, túneles CONNECT). Después de establecer un túnel CONNECT a través de un proxy HTTP, libsoup adjunta Proxy-Authorization a las siguientes solicitudes HTTPS dentro del túnel. El encabezado ya lo ve el servidor objetivo. CVSS 6.5, publicado el 24 de julio de 2026.

La historia no es nueva. En la biblioteca de Python requests, desde la versión 2.3.0 hasta la 2.31.0 (CVE-2023-32681), el encabezado Proxy-Authorization al redirigir a HTTPS se enviaba al servidor objetivo si el nombre de usuario y la contraseña estaban escritos directamente en la URL del proxy. En urllib3, hasta la 1.26.19 y 2.2.2 (CVE-2024-37891), el encabezado establecido manualmente, y no a través del soporte integrado del proxy, no se eliminaba al redirigir a un dominio ajeno.

Por qué es importante específicamente para trabajar con proxies

En un proxy de pago, la contraseña equivale a dinero. Quien la obtiene, consume su tráfico hasta que cambie el acceso. Al pagar por gigabytes, esto es una cuenta directa, y al tener acceso compartido para todo el equipo, también se suman las acciones ajenas desde su IP.

Los escenarios más vulnerables son los siguientes:

• Parseadores y monitoreos, que siguen redirecciones automáticamente. El sitio objetivo o una redirección intermedia puede desviar la solicitud a un dominio que recopila encabezados.
• Scripts con varios proxies: diferentes proxies para diferentes esquemas, cambio de proxies entre solicitudes en una misma conexión, mezcla de "proxies con contraseña" y "proxies sin contraseña".
• Procesos de larga duración en servidores Linux, donde libcurl y libsoup vienen con paquetes del sistema y se actualizan junto con la distribución, y no con su código.
• Redes corporativas con WPAD y archivos PAC: el proxy cambia sin la participación de la aplicación, y este caso se describe en CVE-2026-12547.

Cómo verificar su stack: paso a paso

1. Descubra la versión real de libcurl, no solo la de curl de consola. El comando curl -V muestra ambas, pero la aplicación puede estar compilada con su propia copia de la biblioteca. Para Python con pycurl, ejecute python -c "import pycurl; print(pycurl.version)", para PHP llame a curl_version(). Límite seguro: 8.21.0 y versiones posteriores o ramas corregidas 8.20.1+, 8.16.1+ y 8.14.2+.
2. Verifique las dependencias de Python. Ejecute pip show requests urllib3. Se necesitan requests no inferiores a 2.31.0 y urllib3 no inferior a 1.26.19 (rama 1.x) o 2.2.2 (rama 2.x). Si la dependencia llega de forma transitiva, consulte pip list dentro del mismo entorno donde funciona el parseador.
3. Verifique libsoup en Linux. Esto se refiere a aplicaciones GNOME, WebKitGTK y todo lo que se compila en este stack. Actualice el paquete a través del gestor de distribución y consulte el boletín de seguridad de su distribución: en las tarjetas de estos CVE, Red Hat indica que RHEL 6–10 están afectados.
4. Busque en el código la instalación manual del encabezado. Busque Proxy-Authorization en todo el repositorio. Si el encabezado se establece manualmente y no a través del mecanismo estándar del cliente proxy (proxies= en requests, ProxyManager en urllib3, CURLOPT_PROXYUSERPWD en libcurl), es un candidato a filtración al redirigir.
5. Busque la reutilización de conexiones al cambiar de proxy. Un handle de libcurl, una sesión de requests o un agente HTTP, a través de los cuales se envían solicitudes con diferentes proxies por turnos. La opción más sencilla de corrección: una sesión separada para cada proxy.
6. Desactive las redirecciones automáticas donde no son necesarias. En requests, esto es allow_redirects=False, en urllib3 redirect=False, en curl no use -L y CURLOPT_FOLLOWLOCATION. Entonces, los 3xx se manejan manualmente, y usted decide a dónde ir a continuación. Este es el enfoque que sugieren los autores de requests y urllib3.
7. Realice una prueba en vivo para detectar filtraciones. Levante un simple servidor HTTP que imprima todos los encabezados recibidos y haga una redirección a otro servidor igual. Ejecute su parseador con proxy en un escenario real, incluyendo el cambio de esquema de http a https. Si alguno de los servidores vio Proxy-Authorization, la filtración se confirma en su código, y no en teoría.

Trampas

• Las imágenes de Docker viven su propia vida. Actualizó curl en el host, pero el parseador funciona en un contenedor con una imagen base antigua. Debe verificar dentro del contenedor: docker exec <contenedor> curl -V.
• El curl de consola y libcurl se actualizan de manera diferente. CVE-2026-8927 no afecta al curl de consola, mientras que CVE-2026-6253 sí lo afecta. Un curl -V fresco en la terminal no dice nada sobre la biblioteca con la que se compiló su PHP o Python.
• Digest no salva. Sí, con Digest la contraseña no se envía en texto claro. Pero en CVE-2026-8927, el atacante no necesita la contraseña: repite el encabezado interceptado mientras el nonce esté activo.
• La contraseña en la URL es conveniente, pero peligrosa. La filtración en requests se manifestaba precisamente cuando las credenciales estaban escritas en la dirección del proxy en formato user:pass@host:port. Esto no es motivo para renunciar al formato, pero sí para mantener las bibliotecas actualizadas.
• La redirección puede no venir del objetivo. Las páginas de captcha, los banners de consentimiento, los acortadores de enlaces y los CDN también responden con 3xx. Cuanto más "siga enlaces" haya en el crawler, mayor será la superficie de ataque.

Cómo limitar el daño si la contraseña se filtra

No se puede excluir completamente la filtración: mañana saldrá el siguiente CVE. Por lo tanto, es importante cuánto cuesta una filtración.

• Un proyecto, un acceso. No mantenga un inicio de sesión compartido para todos los parseadores. En ProxyCove, cada proxy comprado recibe un par de nombre de usuario y contraseña separados, por lo que el acceso filtrado de un script no abre el tráfico de los demás.
• No mantenga más tráfico del necesario en un solo acceso. Rellene poco a poco según la tarea, y no para seis meses por adelantado.
• Controle el consumo. Un aumento repentino en el tráfico sin un aumento en el número de tareas es el primer signo de que alguien más está utilizando su acceso.
• Cambie la contraseña inmediatamente al sospechar y según un cronograma. Cómo organizar esto sin tiempo de inactividad se detalla en la guía sobre rotación de contraseñas de proxy.

Qué tipo de proxy elegir y qué tiene que ver con esto

La filtración no depende del tipo de proxy: el error reside en el cliente. Pero el costo de la filtración sí depende. Los proxies de centros de datos son más baratos por gigabyte, y para el scraping de sitios simples con redirecciones frecuentes, es razonable mantenerlos separados del tráfico costoso. Los proxies residenciales deben dedicarse a tareas donde realmente se necesitan, y para ellos se deben crear accesos separados con redirecciones automáticas desactivadas. Los proxies móviles, los más caros por gigabyte, deben mantenerse en el código con el mínimo de dependencias externas y siempre con verificación de versiones de bibliotecas en cada compilación.

Conclusión

La contraseña del proxy puede filtrarse sin un hackeo, sin virus y sin error humano: basta con un libcurl obsoleto, una redirección a un dominio ajeno y una conexión reutilizada. La lista de verificación es corta: curl y libcurl desde 8.21.0, requests desde 2.31.0, urllib3 desde 1.26.19 o 2.2.2, libsoup actualizado, una sesión separada para cada proxy, redirecciones bajo control y una prueba en vivo para detectar filtraciones. Además, acceso separado para cada proyecto, de modo que una filtración cueste un script y no todo el saldo.