Mythos encuentra una vulnerabilidad en curl

• Mythos de Anthropic reportó 5 vulnerabilidades en curl, pero en realidad solo quedó 1
• Tras la revisión del equipo de seguridad de curl, 3 se consideraron falsos positivos y 1 se clasificó como un bug común
• La vulnerabilidad confirmada será un CVE de baja severidad y se publicará a finales de junio junto con curl 8.21.0
• El informe incluía alrededor de 20 bugs y el equipo de curl está corrigiendo los puntos con los que estuvo de acuerdo
• Daniel Stenberg considera que, con base solo en los resultados sobre curl, la evidencia de que Mythos sea de un nivel especialmente peligroso es débil

---

La ruta de acceso de Anthropic Mythos a curl

• En abril de 2026, Anthropic generó gran interés al concluir que su nuevo modelo de IA, Mythos, era “peligrosamente bueno” para encontrar fallas de seguridad en código fuente
• Anthropic decidió no publicar Mythos de inmediato y optó por ofrecerlo primero de forma limitada a algunas empresas para darles tiempo de corregir problemas importantes
• Como parte de project Glasswing, Anthropic también ofreció acceso a su modelo de IA más reciente a “proyectos open source” a través de la Linux Foundation
• La Linux Foundation dejó esta parte en manos de Alpha Omega, y la propuesta llegó a Daniel Stenberg, desarrollador principal de curl
• Aunque se firmó el acuerdo de uso, el acceso real se retrasó, y al final el proceso se llevó a cabo haciendo que otra persona con acceso a Mythos escaneara y analizara curl para luego entregar el informe

El análisis de seguridad con IA de curl ya estaba en marcha

• Antes del informe de Mythos, curl ya había sido analizado con varias herramientas basadas en IA, y además seguía usando analizadores estáticos tradicionales, opciones de compilación exigentes y años de fuzzing
• Principalmente, AISLE, Zeropath y OpenAI’s Codex Security revisaban el código de curl con IA
• Los análisis de estas herramientas llevaron a la integración de entre 200 y 300 correcciones de bugs en curl durante los últimos 8 a 10 meses
• Algunos de los hallazgos reportados por herramientas de IA sí se confirmaron como vulnerabilidades reales y se publicaron como CVE; fueron “probablemente más de 12”
• GitHub Copilot y Augment code también se usan para revisar pull requests, ayudando a corregir problemas señalados y a integrar mejor código
• Las revisiones con IA no reemplazan la revisión humana, sino que se usan como un mecanismo adicional de revisión y contribuyen a elevar la calidad de lo que se integra
• Investigadores de seguridad también están usando IA de forma amplia y efectiva, y están llegando muchos reportes de seguridad de alta calidad
• En el proyecto curl, la seguridad es la prioridad número uno, y se aplican múltiples lineamientos y procesos de ingeniería de software para reducir defectos
• El escaneo de defectos es solo uno de varios pasos para mantener curl seguro, y parece difícil encontrar proyectos que hagan tanta seguridad de software como curl o incluso más

Primeros resultados del análisis de Mythos del 6 de mayo de 2026

• El primer informe de análisis de código fuente generado con Mythos se convirtió en una oportunidad para encontrar áreas de mejora y bugs por corregir en curl
• El escaneo inicial se realizó sobre el repositorio git de curl y un commit reciente específico de la rama master
• El análisis cubrió 178 mil líneas de código dentro de los subdirectorios src/ y lib/
• El informe detalla qué tipos de defectos intentó encontrar mediante múltiples enfoques y métodos
• En la parte superior del informe se explicaba que curl es una de las bases de código en C más auditadas y con más fuzzing, con “OSS-Fuzz, Coverity, CodeQL y varias auditorías pagadas”, por lo que sería difícil encontrar algo en rutas críticas como HTTP/1, TLS y el parseo de URL
• Mythos efectivamente no encontró problemas reales en esas rutas críticas

La escala de la base de código de curl y su historial de seguridad

• Actualmente, sin contar líneas en blanco, curl está compuesto por 176 mil líneas de código C
• El código fuente consta de 660 mil palabras, es decir, 12% más palabras que toda la novela War and Peace en inglés
• Cada línea de código fuente de producción de curl ha sido escrita y reescrita en promedio 4.14 veces
• El código de producción heredado que aún permanece en el git master actual fue escrito por 573 contribuidores individuales
• Hasta ahora, en el repositorio git de curl se han integrado cambios propuestos por un total de 1,465 contribuidores
• curl ha publicado hasta hoy 188 CVE
• curl está instalado en más de 20 mil millones de instancias
• curl funciona en más de 110 sistemas operativos y 28 arquitecturas de CPU
• curl corre en smartphones, tablets, autos, televisores, consolas de videojuegos y servidores

Las “5 vulnerabilidades confirmadas” se reducen en realidad a 1

• El informe de Mythos concluía que había encontrado 5 “Confirmed security vulnerabilities”
• Después de que el equipo de seguridad de curl revisó los detalles durante varias horas, solo quedó 1 vulnerabilidad realmente confirmada
• De las otras 4, 3 se consideraron falsos positivos que señalaban limitaciones ya documentadas en la documentación de la API
• La 1 restante se consideró no una vulnerabilidad, sino un bug común
• La única vulnerabilidad confirmada se convertirá en un CVE de baja severidad (severity low)
• Ese CVE está planeado para publicarse a finales de junio junto con la próxima versión de curl, 8.21.0
• Los detalles de la vulnerabilidad no se harán públicos antes de su divulgación oficial
• El informe de Mythos también incluía varios bugs que finalmente no se consideraron vulnerabilidades, y el equipo de curl está investigando y corrigiendo uno por uno los puntos con los que coincide
• El informe contenía unos 20 bugs bien organizados y casi no tenía falsos positivos
• Gracias a este informe, curl está mejorando, pero por cantidad de hallazgos, las herramientas de IA usadas anteriormente habían llevado a más correcciones de bugs
• Esto también refleja que las primeras herramientas encontraron antes más bugs fáciles y numerosos, y que conforme esos problemas se fueron corrigiendo, encontrar nuevos defectos se ha vuelto cada vez más difícil
• Los bugs pueden ser pequeños o grandes, así que comparar solo por cantidad no siempre es justo

Mythos no parece estar en un nivel especialmente “peligroso”

• Si se consideran solo los resultados del análisis sobre curl, se llega a la conclusión de que gran parte de la atención alrededor de Mythos parece ser sobre todo marketing
• No se ve evidencia de que la configuración de Mythos encuentre problemas a un nivel especialmente superior o más sofisticado que herramientas anteriores
• Es posible que Mythos sea un poco mejor, pero no parece serlo lo suficiente como para producir una diferencia importante en el análisis de código
• Aun así, esta evaluación está limitada a los resultados obtenidos en un solo repositorio de código fuente, el de curl
• No se puede descartar que Mythos funcione mucho mejor sobre otros objetivos

Los analizadores de código con IA siguen siendo muy poderosos

• Los analizadores de código basados en IA son considerablemente mejores que los analizadores tradicionales del pasado para encontrar fallas de seguridad y errores en código fuente
• Todos los modelos modernos de IA se adaptan bien a esta tarea, y quien tenga tiempo y disposición para experimentar puede encontrar problemas de seguridad
• El caos de alta calidad realmente está ocurriendo
• Los proyectos que aún no han escaneado su código fuente con herramientas basadas en IA tienen una alta probabilidad de encontrar muchos defectos, bugs y vulnerabilidades potenciales con esta generación de herramientas
• No solo Mythos, sino también muchas otras herramientas de IA pueden producir ese tipo de resultados
• Si un proyecto no usa analizadores de código con IA, deja tiempo y oportunidad para que atacantes y actores maliciosos encuentren y exploten defectos que nadie detectó

En qué se diferencian los analizadores de IA de los analizadores tradicionales

• Los analizadores de IA pueden detectar cuando lo que dicen los comentarios sobre el código no coincide con el comportamiento real del código
• También pueden revisar código de plataformas y configuraciones donde por lo general no es posible ejecutar analizadores comunes
• “Conocen” detalles de bibliotecas de terceros y APIs, por lo que pueden detectar usos indebidos o suposiciones incorrectas
• “Conocen” los detalles de los protocolos que implementa curl, por lo que pueden señalar puntos donde el código parece violar o contradecir la especificación del protocolo
• En general hacen un buen trabajo resumiendo y explicando defectos, algo que con analizadores tradicionales puede ser tedioso y difícil
• Pueden generar y proponer parches para los problemas encontrados, aunque esos parches normalmente no son correcciones 100% completas

Detalles del informe de Mythos

• El informe de Mythos concluyó que había 0 vulnerabilidades de seguridad de memoria
• Metodológicamente, esta revisión fue un análisis guiado manualmente que usó subagentes LLM para lectura paralela de archivos
• Antes de registrarse, todos los hallazgos candidatos se volvieron a verificar en la sesión principal mediante inspección directa del código fuente
• El mapeo de CVE y búsqueda de variantes se construyó a partir del vuln.json del propio curl
• No se usaron herramientas SAST automáticas
• Este resultado es consistente con el hecho de que curl es una de las bases de código en C más auditadas y con más fuzzing
• La infraestructura defensiva de curl está cerrando de forma sistemática los tipos de bugs que normalmente dan resultados en bases de código de este tamaño
• Entre los elementos defensivos se incluyen dynbuf restringido, curlx_str_number usando máximos explícitos en todo parseo numérico, curlx_memdup0 con protección contra overflow, obligatoriedad de cadenas de formato CURL_PRINTF, límites de tamaño de respuesta por protocolo y el límite de línea de 64 KB de pingpong
• La cobertura incluye todos los protocolos pequeños, todos los parsers de archivos, rutas de validación de todos los backends TLS, HTTP/1·2·3, toda la profundidad de FTP, mprintf, x509asn1, DoH, todos los mecanismos de autenticación, codificación de contenido, reutilización de conexiones, caché de sesión, herramienta CLI, código específico por plataforma y hasta la cadena de suministro de CI y builds

La IA encuentra de nuevo errores de tipos ya conocidos

• Las herramientas de IA están encontrando errores de clases comunes y ya conocidas, simplemente hallando nuevas instancias
• Hasta ahora, la IA no ha reportado tipos completamente nuevos de vulnerabilidades ni categorías inéditas de fallas
• La IA no está reinventando por sí sola la seguridad de esa manera
• Aun así, está desenterrando más problemas que cualquier herramienta anterior

La búsqueda de defectos aún no termina

• Este resultado no será el último hallazgo o reporte de bugs
• Incluso en ese momento seguían llegando reportes adicionales de posibles problemas por parte de investigadores de seguridad
• Las herramientas de IA seguirán mejorando, y los investigadores podrían encontrar formas nuevas y distintas de prompting que hagan que la IA existente detecte más problemas
• curl espera seguir recibiendo escaneos iterativos con Mythos y otras IA, hasta que realmente ya no aparezcan problemas nuevos

[GN⁺]

Comentarios en Hacker News

• Cita: “No puedo llegar a otra conclusión más que la de que gran parte del enorme hype alrededor de este modelo fue principalmente marketing. No vi evidencia de que esta configuración encontrara problemas en un nivel particularmente superior o de una forma más avanzada que las herramientas anteriores a Mythos. Puede que sea un poco mejor, pero no parece lo bastante bueno como para generar un cambio significativo en el análisis de código”
  Le recuerda a todos que la competencia en este campo es feroz y que hay mucho marketing, tanto obvio como sutil, mezclado en todo esto.

  • No sorprende que Anthropic use marketing para convencer de que su modelo es más avanzado, está mejor construido, que la IA es una amenaza y que por eso hace falta regulación, cuya respuesta casualmente son ellos mismos.
    Hablando más en serio, hasta ahora no he visto muchas señales de que Mythos sea más que Opus con una capa de análisis de código orientada a seguridad. Aun así, el hecho de poder encontrar este tipo de bugs de forma automática es, más allá del bombo publicitario, el punto más importante.
    Me da curiosidad la tasa de error de detección. Si el 90% está mal y solo estamos oyendo de los casos útiles para marketing, entonces no significa gran cosa.
  • Es más o menos el resultado que esperaba, pero la gran pista ya era que las herramientas existentes basadas en LLM ya se estaban usando sobre codebases auditadas extensamente.
    Así que el marketing de Anthropic puede ser exagerado, pero para empezar ya quedaba muy poco por encontrar, y el artículo también lo dice.
    Es difícil juzgar si esto representa un gran avance para otro tipo de proyectos, pero sí deja claro que hoy mismo todo el mundo debería estar usando herramientas de revisión de código con IA para auditar código existente, y en la práctica no todos lo están haciendo.
  • curl no es un buen punto de datos. Es una de las codebases más escarbadas que existen, y además sus prácticas de pruebas de seguridad son muy sólidas.
    Investigadores que usan modelos parecidos, aunque no idénticos, a Mythos ya han tenido tiempo suficiente para reportar bugs. Puede que Daniel tenga razón al decir que Mythos no fue una herramienta que cambiara las reglas del juego para curl, pero en casi cualquier otra codebase las condiciones iniciales son distintas. El verdadero marketing quizá sea más bien su modestia respecto a la madurez de curl.
  • ¿Mozilla le está haciendo el marketing a Anthropic?
    Como parte de una colaboración continua con Anthropic, tuvimos la oportunidad de aplicar una versión temprana de Claude Mythos Preview a Firefox. La versión Firefox 150 de esta semana incluye correcciones para 271 vulnerabilidades identificadas durante esta evaluación inicial.
    A medida que esta capacidad llega a más defensores, muchos equipos están experimentando el mismo vértigo que sentimos nosotros cuando los primeros resultados empezaron a volverse evidentes. Si un solo bug como este en un objetivo tan endurecido ya habría sido alerta roja para los estándares de 2025, ver tantos de golpe te hace detenerte a pensar si de verdad es posible ponerse al día.
    https://blog.mozilla.org/en/privacy-security/ai-security-zer...
  • Es totalmente posible que el hype haya sido sobre todo marketing.
    La otra posibilidad es que Curl sea suficientemente seguro y por eso haya mucho menos que encontrar que en otros proyectos.

• Estoy de acuerdo con lo de “un evento de marketing increíblemente exitoso”. Bien jugado por Anthropic.
  Llegó hasta CISOs de pequeñas organizaciones semigubernamentales en Países Bajos, y hubo un poco de pánico por el anuncio del tsunami de vulnerabilidades que supuestamente venía con Mythos.
  Gracias a eso conseguimos más presupuesto y prioridad en el consejo. Un buen susto de marketing no se debe desperdiciar.

  • No estoy de acuerdo con “no se ve ningún tsunami”. En Firefox hubo más de 100 bugs, además de más proyectos open source, vulnerabilidades antiguas de ejecución remota de código en OpenBSD/Linux que antes no se habían visto, y hasta en Linux mismo salieron varias escaladas locales de privilegios en apenas 2 o 3 semanas.
    Lo que parece detectarse no es miedo de marketing, sino un fuerte aumento de divulgaciones de vulnerabilidades de alta calidad y con pocos falsos positivos. Se siente como revisar de forma acelerada en pocas semanas lo que normalmente serían varios años de reportes buenos de bugs.
  • Anthropic está arruinando rápido la buena voluntad de los clientes al repetir siempre la misma jugada. Personalmente me parece marketing terrible.
    Una cosa es que una empresa investigue las amenazas de ciberseguridad de los LLM en general, y otra muy distinta es desviar la conversación hacia “nuestro nuevo modelo es demasiado poderoso”. Se siente viscoso y desagradable.
  • Él explica con bastante detalle que curl ha sido pulido desde la ingeniería de software casi hasta su límite. ¿De verdad creen que la mayoría del código está así de refinado?

• Si un agente de IA encontró 0 bugs en cierta utilidad de software, ¿por qué eso tendría que interpretarse como que ese agente de IA no sirve mucho para encontrar bugs?
  ¿Y si en realidad había 0 bugs?
  La expectativa de que “5 problemas se sintieron como nada para nosotros, que esperábamos una lista extensa” puede simplemente no haber coincidido con la realidad. Pero eso no implica necesariamente que la capacidad de Mythos sea menor de lo afirmado. curl puede ser una herramienta bien endurecida que, en su estado actual, no tiene muchas vulnerabilidades de seguridad.

  • El autor también consideró ese mismo punto respecto a los bugs que quedan.
    “Más cosas por encontrar. Estos no serán, ni de cerca, los últimos bugs que encuentren o reporten. Incluso mientras escribía el borrador de esta entrada del blog, recibí más reportes de investigadores de seguridad sobre posibles problemas. Las herramientas de IA mejorarán, y los investigadores pueden encontrar nuevas y distintas formas de prompting para que la IA existente descubra más. Aún no hemos llegado al final. Espero que podamos seguir escaneando curl una y otra vez con Mythos y otras IA, y continuar hasta que de verdad ya no se encuentren problemas nuevos”.
    Tiene sentido. Suponer que quedaba exactamente un solo hallazgo importante, que justo Mythos lo encontró en el momento de su lanzamiento y que los demás proyectos justo antes habían barrido rápidamente con todos los demás hallazgos, exige una coincidencia bastante grande. Es posible, pero no es el punto de partida más seguro al plantear dudas.

• Es difícil no pensar que curl, por su naturaleza, es una herramienta relativamente simple y con límites bien definidos. Basta compararla con un sistema operativo, un navegador web, una base de datos o la codebase de una empresa de decenas de miles de millones.
  Tiene cierto sentido que Mythos/ChatGPT 5.5 pueda funcionar mucho mejor en complejidades que no existen en curl. curl tiene muchísimas funciones como “cliente para todo”, pero su complejidad sigue estando varios órdenes de magnitud por debajo de otro software del que dependemos.

  • curl es muchísimo más complejo de lo que la gente cree. La mayoría lo conoce solo como una herramienta de línea de comandos que llama endpoints HTTP(S) y muestra la salida, pero en realidad soporta casi todos los protocolos de transferencia de archivos y es una biblioteca diseñada para procesos de larga duración.
    Como está pensado para procesos persistentes, usa toda clase de técnicas para encadenar y reutilizar conexiones y recursos. También tiene APIs asíncronas para integrarse con event loops existentes.
    ¿Un navegador web o una base de datos son más complejos? Claro, muy probablemente sí. Están resolviendo problemas realmente enormes. Pero curl sin duda es más complejo que la mayoría del código de aplicación que lo usa.
  • Estoy de acuerdo en que es una herramienta bastante básica, pero como dice el artículo, el código es más largo que Guerra y paz. Con una escala así, sigue habiendo suficiente espacio para que aparezcan vulnerabilidades de seguridad.
  • Citando el artículo: “curl tiene actualmente 176,000 líneas de código C, sin contar líneas en blanco. El código fuente consta de 660,000 palabras, lo que es un 12% más que toda la edición en inglés de la novela Guerra y paz”.
    “curl está instalado en más de 20 mil millones de instancias. Corre en más de 110 sistemas operativos y 28 arquitecturas de CPU. Corre en todos los smartphones, tablets, autos, televisores, consolas de videojuegos y servidores del planeta”.
    No es fácil llamar a eso simple o bien delimitado. La mayoría de los sistemas operativos o navegadores web ni siquiera corren en autos o televisores.

• No me parece que la conclusión de “no es particularmente peligroso” se siga tan bien. Como se menciona, curl ya ha sido analizado a fondo con todas las herramientas disponibles, y la mayor parte del software no está en ese nivel.

  • Pero Mythos no se está vendiendo como una herramienta que hace un poco mejor lo que las herramientas existentes ya podían hacer, sino como una revolución.
  • Mythos es peligroso o no lo es. Aquí “peligroso” se está usando en el sentido de “encuentra muchas más vulnerabilidades que las que encuentran las herramientas disponibles”.
    Mythos solo encontró una vulnerabilidad adicional, y como x+1 no es muchísimo mayor que x, según esa definición la conclusión es que Mythos no es peligroso.
  • Sí, pero ¿no sería eso un juicio sobre Mythos comparado con otros modelos?
    Si es así, la conclusión igual se mantiene. “La mayor parte del software” no ha sido analizada tanto como curl, ni con otras herramientas ni con otros modelos. Si esas herramientas pueden producir casi el mismo resultado que Mythos, entonces cuesta verlo como algo especialmente peligroso.
  • ¿No era que “no es particularmente peligroso” se refería a las vulnerabilidades encontradas? Ellos probablemente saben bien qué consideran baja severidad.
  • curl está recibiendo actualmente una cantidad récord de reportes de bugs/vulnerabilidades de alta calidad. Es un cambio bastante brusco respecto a las avalanchas pasadas de reportes de baja calidad, así que no significa que ya no quede nada por encontrar.
    Muchos o la mayoría de estos parecen haber sido encontrados por expertos humanos con ayuda de herramientas de IA, pero si Mythos de verdad fuera revolucionario, debería poder encontrar este tipo de problemas por sí solo.
    https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/, enlazado en el artículo original.

• Me impresionó la parte que dice: “La única vulnerabilidad confirmada será un CVE de baja severidad y planeamos divulgarla junto con la próxima versión de curl 8.21.0, prevista para finales de junio”.
  Todavía me cuesta dimensionar el nivel de calidad y refinamiento que hay en cURL. Es el ejemplo perfecto de algo tan bien hecho que la gente casi ni se detiene a pensarlo dos veces.

  • Es fácil. Muestra lo que se puede lograr si aplicas estándares de calidad altos a cada línea de código que se hace commit, se revisa y se fusiona, sin importar el lenguaje de programación.
    Pero en esta era de carrera hacia el fondo, tercerización baratísima y ahora generación de código basada en LLM, a la mayoría de las empresas no les va a importar este nivel de calidad a menos que exista algún tipo de responsabilidad clara.
  • Curl y SQLite son mis ejemplos favoritos de “lo que sea” hecho con verdadera ingeniería y pruebas rigurosas. Es casi filosófico.
    Los requisitos para contribuir a estos proyectos exigen ese nivel de rigor, y sus mantenedores hacen cumplir esos requisitos. Lo que lo hace posible es documentación que no está bajo carga, es decir, documentación que no es el código mismo del proyecto. Me recuerda tanto a cómo los experimentos mentales de Einstein terminaron desembocando en proyectos prácticos como el GPS, como a la creencia de Descartes de que todos los problemas pueden resolverse con pensamiento racional.
  • Es irónico que esté tan bien hecho y que al final la gente termine haciendo curl ... | bash como si nada. Y luego lo esquivan con frases como “modelo de amenazas”.
    Yo paso de curl-bash y mejor uso un instalador de paquetes firmado criptográficamente.

• Sé que el hype de Mythos es parte del marketing de Anthropic, pero ¿no puede pasar también que en una codebase muy revisada simplemente no haya exploits de seguridad notorios en este momento?
  El hecho de no haber encontrado nada no necesariamente es evidencia en contra. Sobre todo si otras herramientas ya habían identificado antes cientos de vulnerabilidades. En este punto parece estar completamente desmenuzada.

• El marketing siempre está mezclado, y la gente debería ser capaz de verlo en contexto.
  Además, curl es un proyecto open source, relativamente pequeño pero crítico, bien conocido y usado en todas partes. Dejando de lado las bibliotecas de imágenes, herramientas como curl, sudo, su o passwd también serían de las primeras cosas que yo intentaría.
  Todavía no se sabe realmente qué puede hacer Mythos. ¿Qué significa un modelo de 10 billones de parámetros en términos de costo y benchmarks?
  Aun así, si hace medio año los LLM empezaron a volverse mucho mejores que los humanos para encontrar este tipo de problemas, entonces en algún momento todos vamos a tener que mirar de frente lo que hemos estado ignorando. Hoy en día hay que añadir LLM al escaneo de seguridad y tomárselo en serio.
  Incluso en el peor de los casos, se puede usar el marketing de Anthropic para decir que esto ya es obligatorio y que algo cambió.

  • Sobre la pregunta “¿qué significa un modelo de 10 billones de parámetros en términos de costo y benchmarks?”, para mí significa que ya llegamos a la parte alta de la curva S de los efectos de escalado.
    Si a esa escala la herramienta no es visiblemente mejor, entonces ya estamos claramente en la zona de rendimientos decrecientes.
  • “Todavía no se sabe realmente qué puede hacer Mythos” es una condición intencional. Aun así, basta pensar en lo que la gente ya cree que puede hacer.
  • Lo de que “los LLM se volvieron mucho mejores que los humanos para encontrar este tipo de problemas” me hace poner los ojos en blanco. Los analizadores estáticos generales también han sido mejores que los humanos durante décadas en ciertas tareas mecánicas, y ser mejor que un humano en ciertas tareas mecánicas no significa gran cosa.
    Lo nuevo e interesante es el tipo de “bug borroso” potencial que el artículo describe que los LLM pueden identificar. Por ejemplo, cuando el código no coincide con lo que describe el comentario, cuando se usa una biblioteca de terceros de forma poco común, cuando el código y el protocolo implementado no encajan, o cuando en general el código simplemente se ve raro y alguien debería mirarlo más de cerca. Eso llena un hueco en la caja de herramientas tradicional de depuración, pero no debería reemplazarla.

• Para mí, el mensaje alrededor de Mythos es que pone la experiencia de los mejores expertos en seguridad y de los mejores especialistas en lenguajes, protocolos y código al alcance de cualquiera que tenga acceso.
  El riesgo estaba en darle ese nivel de acceso al mundo entero antes de que los defensores tuvieran acceso a ese mismo nivel de experiencia.
  Curl está en el centro de todo, así que durante años lo han examinado expertos en seguridad, protocolos y lenguajes. Que Mythos haya encontrado algo es interesante, pero no es señal de que todo haya sido puro hype de marketing ni de que no sea peligroso.
  Puede asumirse que el 99.99% de los proyectos no son tan seguros como curl, sin importar si son open source o closed source. Los LLM van a descompilar y explorar proyectos cerrados con gusto. Si un proyecto no ha sido fuzzed ni revisado por herramientas de IA existentes y por expertos, ya deberías asumir que puede romperse. Eso ya es cierto con las herramientas actuales, y algo como Mythos solo hace que usuarios más amplios y con menos experiencia tengan acceso a esas capacidades.

  • De acuerdo. Anthropic nunca afirmó un desempeño sobrehumano, sino velocidad y escala.
    El hecho de que no haya encontrado muchas vulnerabilidades nuevas en software muy estudiado no dice nada sobre el potencial general de uso indebido peligroso.

• Se lee como: “curl es una de las codebases en C más fuzzed y auditadas que existen. Tuvo OSS-Fuzz, Coverity, CodeQL y varias auditorías pagadas. Es difícil encontrar algo en rutas críticas como HTTP/1, TLS y el núcleo del parsing de URL”.
  Esa formulación suena menos a que el LLM lo intentó y falló, y más a que directamente dejó de intentarlo. He visto que Claude hace eso a menudo si no le insistes para que se rete a sí mismo, así que me pregunto qué fue lo que realmente pasó aquí.

[GN⁺]

Opiniones de Lobste.rs

• Visto por sí solo, quizá no sea tan sorprendente, pero parece que este resultado hay que leerlo como: “después de que salieron los modelos anteriores, fue atacado casi todos los días y aun así encontró un problema de seguridad en una sola ejecución en una de las aplicaciones más revisadas”

  • Eso de “seguir corriendo analizadores estáticos de código convencionales, usar las opciones de compilador más estrictas y además hacer fuzzing durante años” es algo que, en otros lados, casi no se hace tanto como uno pensaría
    Quizá haya que prepararse para un periodo oscuro en el que la seguridad se reduzca o desaparezca hasta que se reescriba todo
  • Sí, es cierto que los LLM se han vuelto hábiles para encontrar vulnerabilidades, pero no sé por qué describen a curl como una de las aplicaciones más auditadas
    curl tenía un programa de bug bounty y atrajo cierta investigación, pero como resultado Daniel también terminó sepultado bajo reportes basura generados por IA. Como objetivo de investigación de vulnerabilidades, ya sea pública o privada, nunca ha estado entre los más interesantes
    No entra en la categoría de “aquí no encuentras nada por más que lo intentes”, especialmente si puedes meterle recursos computacionales a gran escala casi subvencionados
  • La vulnerabilidad también es de baja severidad
    Según la entrada del blog, “la única vulnerabilidad confirmada será un CVE de baja severidad que se revelará junto con el próximo lanzamiento de curl 8.21.0, previsto para finales de junio”
    También dice que hubo 4 falsos positivos

• “Al final, otra persona con acceso al modelo se ofreció a ejecutar el escaneo y análisis de curl con Mythos por mí y enviarme el reporte. Para mí, la diferencia no era tan importante. De todos modos, no tenía mucho tiempo para explorar distintos prompts y profundizar demasiado.”
  Exactamente así actúan cuando ponen a funcionar una máquina de exageración que rinde menos de lo prometido: “¡Prueben lo nuestro! Bueno, en realidad no exactamente ustedes mismos. ¡Nosotros se los hacemos!” Y detrás sigue corriendo el método tradicional y caro
  No sé si esta vez fue así, pero no me parece una posibilidad tan remota como para descartarla. Me pregunto a cuántas otras personas les dijeron que usaran Mythos, pero en realidad no pudieron usar Mythos y solo recibieron resultados

  • Quizá simplemente compraron una vulnerabilidad del mercado negro y la presentaron como si Mythos la hubiera encontrado. Entonces no sería más que otro dato escupido por IA
    Incluso es posible que la mayoría de estos hallazgos sean debilidades discutidas en foros oscuros que los mantenedores rara vez visitan
    No significa que la IA no pueda hacer el software más seguro. Pero si las empresas de IA esconden demasiado sus cartas, no hay forma de saber qué es real
  • Me pregunto si también buscaron explicaciones alternativas que no solo confirmaran lo que ya pensaban de Anthropic

• Hace 3 meses vi a esta persona anunciar en un escenario que iba a cerrar el programa de bug bounty por los reportes basura generados por IA
  Me pregunto si la herramienta mejoró tanto, o si al desaparecer el incentivo económico la gente empezó a dedicar más tiempo a distinguir vulnerabilidades reales de basura

  • Lo menciona en https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ . Aun así, ciertamente parece que los reportes basura se detuvieron

• Si ves Mastodon, este tipo de resultados se presta muchísimo para desatar el sesgo de confirmación
  Pero si dejas eso de lado, no parece apropiado generalizar a partir de esto. Aun así, está bien que se publiquen estos datos

  • No sé qué tanto aplique a Mastodon en general, pero a mi alrededor el ambiente es tan anti-IA que incluso gente con mucha experiencia intenta demostrar que no sirve de nada tirando un enlace de GitHub dentro de la interfaz de chat de Claude
    Pero esa no es una herramienta para usarse así. Incluso cuando intentas mostrarle resultados a la gente, solo quieren señalar casos fallidos y reírse, así que de verdad es difícil

• Ojalá salgan más publicaciones como esta
  Que en curl solo haya aparecido una de baja severidad es alentador, pero al mismo tiempo sigue siendo un solo caso. También puede ser que curl simplemente esté más maduro que otras bibliotecas clave

• “Parecía que el mundo entero había perdido la cabeza. ¿Era el fin del mundo tal como lo conocíamos? Sin duda fue una maniobra de marketing sorprendentemente exitosa.”
  Ese estilo de redacción no me interesa. Preferiría que mostrara pensamiento claro y razonamiento sólido. Hay que interpretarlo de buena fe
  Sin buena evidencia ni buen razonamiento, decir que Glasswing fue una “maniobra de marketing” es especulación. Entiendo el escepticismo sano, pero el escepticismo sano también debe apuntar hacia adentro. ¿Con base en qué se puede tener tanta certeza?
  Si algo fue una maniobra, ¿qué significa exactamente eso? Cuando leo “maniobra”, suena a que hubo una intención de manipular. Quienes pueden hablar con más propiedad sobre la intención son “las personas que estaban en esa sala”. Los demás, como mucho, están haciendo predicciones, pero demasiada gente ni siquiera trata esas predicciones como tales y las afirma como si fueran hechos
  Si no estabas ahí, es más sensato explicar tu razonamiento que hacer afirmaciones tajantes
  Los incentivos apuntan en muchas direcciones. No lo estoy viendo de forma ingenua. De una persona que escribe en serio espero que respete la inteligencia del lector y su deseo de entender el mundo
  Es común que un experto en un área entre con exceso de confianza en otra y se equivoque. ¿Qué base hay para asumir que el mantenedor de curl tiene buenos estándares epistemológicos sobre esto en general y, en particular, sobre el estatus del proyecto que él mismo mantiene? Muchas veces la gente tiene un fuerte incentivo para no querer que una máquina haga algo mejor que ellos. No estoy diciendo que Mythos ya esté en ese punto. Sobre eso prefiero reservar el juicio. Pero viendo solo el razonamiento que aparece en este texto, no me resulta fácil quedar impresionado con el autor

  • No estoy de acuerdo con que sea apresurado decir que Glasswing fue una maniobra de marketing. Si ves lo que viene justo después de la frase “maniobra de marketing exitosa”, me parece una crítica justa
    “Como parte del proyecto Glasswing, Anthropic también ofreció, a través de la Linux Foundation, acceso a sus modelos de IA más recientes a ‘proyectos de código abierto’. La Linux Foundation dejó esta parte en manos del proyecto Alpha Omega, y sus representantes se pusieron en contacto conmigo. Como desarrollador principal de curl, me ofrecieron acceso al modelo mágico y acepté con gusto. Claro que quería ver qué podía encontrar en curl.”
    La impresión general al leer todo el texto es que el autor no dijo que Glasswing fuera solo una maniobra de marketing, sino que como maniobra de marketing claramente fue un éxito y todavía no está definido cuánto más hubo aparte de eso
    El resto del texto después de la cita plantea que sí hubo algo más que simple marketing y concluye que “sigue siendo muy bueno”. La idea era que, aunque no alcance el nivel del marketing exagerado y jadeante que hemos recibido hasta ahora, probablemente sí sea útil
  • OpenAI poco después lanzó una nueva versión de su modelo siguiendo su patrón habitual de actualizaciones regulares, y mostró capacidades similares en esta área, pero sin mucha fanfarria ni alboroto
    Simplemente era GPT-5.5. En ese sentido, creo que ocultar Mythos por su supuesta peligrosidad pudo haber sido una forma de concentrar la atención en el caso de uso de seguridad y crear nueva demanda