Ubuntu corrige fallas en curl con riesgo de fuga de credenciales
USN-8084-1 corrige cinco vulnerabilidades en curl/libcurl que pueden exponer tokens OAuth, mezclar credenciales entre conexiones y, en un caso puntual, provocar uso de memoria liberada en flujos SMB.
Introducción
curl y libcurl están en el centro de miles de flujos de automatización: jobs de CI/CD, scripts de aprovisionamiento, chequeos de salud, integraciones con APIs y tareas de backup. Por eso, cuando aparece una tanda de vulnerabilidades en este componente, no es un tema menor para operaciones.
El 11 de marzo de 2026, Canonical publicó USN-8084-1 con correcciones para cinco CVE en curl. No todas tienen el mismo impacto ni aplican a todas las versiones de Ubuntu, pero varias tocan un punto sensible en entornos modernos: manejo de credenciales en redirecciones, proxies y autenticación reutilizada. En términos prácticos, el riesgo no se limita a “el comando curl del administrador”, sino a cualquier aplicación o pipeline que use libcurl por debajo.
Qué ocurrió
El aviso USN-8084-1 incluye correcciones para CVE-2026-1965, CVE-2026-3783, CVE-2026-3784, CVE-2026-3805 y CVE-2025-0167.
Los casos más relevantes para operación diaria son tres:
– **CVE-2026-3783**: posible fuga de bearer tokens OAuth2 cuando una solicitud HTTP(S) sigue un redirect y existe información en `.netrc` para el host de destino.
– **CVE-2026-3784**: reutilización incorrecta de conexiones HTTP proxy con credenciales distintas, lo que puede mezclar contextos de autenticación.
– **CVE-2026-3805**: uso de memoria liberada (use-after-free) en una segunda solicitud SMB al mismo host; su alcance es acotado pero existe riesgo de crash y, en escenarios muy específicos, filtración de datos.
Además, Canonical aclara que no todas las ramas están afectadas de la misma forma: por ejemplo, CVE-2026-3805 impacta en Ubuntu 25.10, mientras que CVE-2025-0167 afecta 22.04 LTS y 24.04 LTS en escenarios de redirección con `.netrc`.
Impacto para SysAdmin / DevOps
Para equipos SysAdmin/DevOps, el impacto real aparece en automatizaciones no interactivas:
1. **Pipelines que consumen APIs con OAuth2**
Si un flujo usa `Authorization: Bearer` y sigue redirecciones, un comportamiento incorrecto puede exponer tokens a un host no esperado.
2. **Ambientes con proxy corporativo autenticado**
En organizaciones con múltiples identidades de salida (por equipo, servicio o tenant), la reutilización incorrecta de conexiones puede contaminar sesiones.
3. **Herramientas internas que dependen de libcurl**
Muchas aplicaciones no “se anuncian” como dependientes de libcurl. Actualizar sólo el binario `curl` no siempre alcanza si hay imágenes o paquetes congelados en build previos.
4. **Riesgo transversal en contenedores e imágenes base**
Si las imágenes base de CI o runtime arrastran versiones vulnerables, el problema persiste aunque los nodos host estén parchados.
Detalles técnicos
Desde los avisos de curl y Ubuntu surgen varios datos técnicos útiles:
– **Rango afectado amplio en CVE-2026-3783 y CVE-2026-3784**: ambos abarcan gran parte del historial del proyecto hasta 8.18.0 y se corrigen en 8.19.0 upstream.
– **Severidad diferenciada**: curl clasifica CVE-2026-3783 como *Medium* (credenciales insuficientemente protegidas, CWE-522) y CVE-2026-3784 como *Low* (CWE-305).
– **CVE-2026-3805 también en Medium**: técnicamente es un UAF (CWE-416), pero el propio proyecto describe una explotabilidad práctica compleja.
– **Parcheo por distro, no sólo por upstream**: Ubuntu distribuye versiones corregidas propias (por ejemplo 8.5.0-2ubuntu10.8 para 24.04 LTS y 7.81.0-1ubuntu1.23 para 22.04 LTS), por lo que no hace falta esperar un número de versión “idéntico” al upstream para estar protegido.
Versiones corregidas reportadas por Ubuntu:
– Ubuntu 25.10 (questing): 8.14.1-2ubuntu1.2
– Ubuntu 24.04 LTS (noble): 8.5.0-2ubuntu10.8
– Ubuntu 22.04 LTS (jammy): 7.81.0-1ubuntu1.23
Este punto es clave para auditoría: validar estado por **paquete de la distro** y no únicamente por versión semántica de upstream.
Qué deberían hacer los administradores
1. **Actualizar inmediatamente curl/libcurl en servidores y runners**
Ejecutar el ciclo habitual de actualización y reinicio de servicios que dependan de librerías compartidas.
2. **Inventariar uso real de libcurl**
Revisar imágenes base, agentes CI, jobs legacy y utilitarios internos. El objetivo es detectar dónde se hereda la librería sin visibilidad directa.
3. **Revisar flujos con bearer tokens + redirects**
Si hay integraciones sensibles, minimizar redirecciones y limitar explícitamente dominios permitidos.
4. **Auditar uso de `.netrc` y credenciales de proxy**
Evitar archivos globales ambiguos, reducir entradas `default` y segmentar credenciales por servicio.
5. **Aplicar control en pipelines**
Incorporar chequeos de versión de curl/libcurl en etapas de build (policy gates) para impedir despliegues con versiones vulnerables.
6. **Verificar contenedores ya desplegados**
Rebuild + redeploy en workloads persistentes. Parchar host sin renovar imagen no corrige el riesgo dentro del contenedor.
Conclusión
USN-8084-1 no describe una única falla “catastrófica”, pero sí una combinación relevante de problemas de manejo de credenciales y reutilización de conexiones en un componente extremadamente ubicuo. Para equipos de infraestructura, el enfoque correcto es operativo: parchear rápido, validar dependencias indirectas y reforzar controles de autenticación en automatizaciones.
En 2026, la lección se repite: las vulnerabilidades con impacto moderado en librerías base pueden convertirse en riesgo alto cuando atraviesan CI/CD, proxies corporativos y tokens de servicio de alto privilegio.