Hay un número que no se ve a menudo en open source: 22 vulnerabilidades esperando release. El próximo martes 14 de octubre sale curl 8.23.0, y no es la versión programada — Daniel Stenberg y su equipo adelantaron el ciclo completo porque llegó un reporte de un bug que no se podía dejar dormir hasta el release trimestral.
El segundo CVE HIGH de curl en cinco años
El proyecto curl tiene su propia escala de severidad — desprecian el sistema CVSS con argumentos que respeto — y desde 2021 solo han publicado dos CVEs marcados HIGH. El anterior fue CVE-2023-38545, un heap buffer overflow que tuvo a medio mundo parcheando de emergencia en octubre de ese año. Este nuevo, CVE-2026-92392, es el segundo. Los otros 21 arreglos vienen en la misma release, pero en severidades menores.
Lo más notable es la disciplina: ni el título del bug se conoce todavía. Los detalles completos se publican en la mañana europea del martes 14, sincronizados con el release, después de avisar con anticipación a la lista distros@openwall y a los clientes de pago del proyecto. Sin teaser, sin partial-disclosure, sin ese “próximamente lo explico” que se transforma en seis semanas. Disclosure coordinado de libro.
Por qué esto te importa aunque nunca hayas compilado curl
Porque curl está en todas partes: en tu distro, en tus imágenes Docker, en tu router, en las SDKs de cosas que ni sabes que tienen IP. Cada vez que un bug así sale a la luz, todos los que autoalojamos pasamos por el mismo ritual: revisar qué versión trae cada contenedor y descubrir que tres imágenes “actualizadas” siguen corriendo una build de hace un año.
Mi checklist para el martes, cuando salgan los detalles:
1. Inventaria antes de leer el advisory. Corre apt list –installed | grep curl y revisa las imágenes de tus docker-compose. Si esperas a leer el exploit para emocionarte, ya perdiste el día más valioso: el que el atacante está usando ahora.
2. Asume que tu escáner no va a saber nada. Los CVEs nuevos tardan días en llegar a los feeds comerciales. Durante esas primeras 48 horas tú eres el escáner. Un grep de versión hecho a mano vale más que un panel bonito que dice que todo está verde.
3. No confundas versión con build. Tu gestor de paquetes puede decir “curl 8.23.0” y aun así estar corriendo el binario con el bug, porque el mantenedor aplicó un backport del parche sin cambiar el número de versión. Revisa el changelog del paquete, no la versión del binario.
4. Piensa en qué condiciones exige el bug. Muchos CVEs de curl necesitan que el atacante controle una parte del request o del servidor remoto. Si tu servicio solo hace fetch a URLs que tú mismo construyes, el riesgo real puede ser mucho menor que el titular. Y al revés: si recibes URLs de usuarios, sube el nivel de urgencia.
La lección que me interesa
Lo que me gusta de este manejo: el equipo de curl sacudió su propio calendario para no sentar precedente de “esperamos al release trimestral por política”. Cuando un bug de verdad importa, el proceso se dobla al bug, no al revés. Es exactamente el estándar que uno quisiera de los proveedores de software a los que les pagas y que te mandan el fix “en la próxima release mayor, estimamos Q2” con cara de nada.
El martes 14, lee el advisory con el café. Y si al final resultó que el bug exige condiciones imposibles de replicar en tu entorno, igual actualiza: vienen 21 fixes más en el mismo paquete, y curl es de esas piezas que nadie mira hasta que dejan de funcionar.
Los detalles técnicos de CVE-2026-92392 se publican el 14 de octubre de 2026 en la mañana europea, junto con curl 8.23.0. Si lees esto después del martes, el fix ya debería estar en tu gestor de paquetes.
Fuente de inspiración: Twenty-two pending curl vulnerabilities
