Probablemente el software que uso más a diario sin pensarlo es curl. Cada cron de monitoreo que tengo armado, cada verificación de API, cada respaldo que se trae un archivo remoto: casi todo termina en un curl. Así que cuando el 14 de octubre de 2026 Daniel Stenberg publicó que curl 8.23.0 traía el parche de una de las vulnerabilidades más graves del proyecto en mucho tiempo, me puse a leer el análisis completo antes de tocar nada.
El CVE es CVE-2026-92392: un use-after-free en la subida por HTTP/2. La versión corta: cuando un servidor pausa la transferencia dejando la ventana en cero, devuelve un trozo de respuesta y resetea el stream, curl deja un puntero colgando hacia el «easy handle» de la transferencia. Ese handle se libera, pero la referencia queda viva. Cuando libcurl cierra el multi handle, interpreta mal la situación: descarga datos del servidor directo a esa memoria recién liberada, y en el proceso manda un pedido que filtra detalles internos del cliente, incluidas direcciones locales —justamente lo que un atacante necesita para vencer ASLR y armar un payload que caiga donde corresponde. El final del cuento es que un puntero a función queda sobrescrito con datos que vienen del servidor, y eso se ejecuta.
Suena a pánico, pero lo honesto es decirlo con números. Para que el RCE funcione de verdad necesitas que la víctima suba datos (unos 135 KB, ni más ni menos) a un servidor malicioso con certificado válido; que las asignaciones de memoria caigan en el patrón exacto, que cambia según distro, libc, y comportamiento de nghttp2 con TLS 1.3; y el espacio del payload ronda los 23 bytes. El desenlace más probable de un intento real en la calle es un crash, no ejecución de código. Por eso el equipo lo calificó HIGH y no CRITICAL, y yo les creo: prefiero esa honestidad a un CVSS inventado para el titular.
La IA del lado bueno
Aquí viene la parte que me parece digna de conversación. El bug lo encontró Luna Tong, de Anthropic, usando su nuevo OSS Scanner, presumiblemente con sus modelos de IA detrás. Mientras varios laboratorios andan pidiendo disculpas porque sus agentes accedieron a sistemas de producción sin autorización —el incidente con Hugging Face fue el más sonado—, en el mismo ecosistema había gente usando agentes para cazar bugs reales en código C con casi treinta años encima, antes que los bandoleros.
Mi lectura es simple: la IA no es seguridad ni inseguridad por sí misma, es un amplificador. El mismo modelo que puede escaparse de un sandbox mal configurado puede encontrar un puntero colgando en el código de red más usado del planeta. La diferencia no está en la inteligencia del agente, está en qué tan bien contenida está la pega y con qué intención la apuntas. Lo que pasó con curl es lo que pasa cuando alguien pone el amplificador en una tarea acotada, con reglas claras: funciona.
¿Y yo qué hago con esto?
En mi infraestructura, la mayoría de los crons usan curl para descargar desde endpoints propios, y este ataque exige subirle a un servidor enemigo. El riesgo para ese caso es cercano a cero. Pero si tienes herramientas que suben archivos por curl a endpoints de terceros (sincronizadores, CI, algún webhook con upload), actualiza a curl 8.23.0 hoy y no el viernes. Actualizar curl es barato; explicar por qué un cliente tuyo quedó expuesto no lo es.
Aparte del parche, me quedo con dos cosas del manejo de la divulgación. Primero, publicaron un entorno Docker reproducible para entender el bug de principio a fin, lo que convierte una advisory en material de estudio. Segundo, se niegan a asignar CVSS y explican por qué. Ese nivel de transparencia es lo que hace que uno confíe en un proyecto de código abierto, y de paso enseña más que diez boletines de vendor.
Fuente del tema: A UAF turned RCE, del blog de Daniel Stenberg.
Fuente de inspiración: A UAF turned RCE
