Un rumor de bug basta para que los agentes encuentren exploits

Just the rumour of a bug is enough to find an exploit these days

Un rumor de bug basta para que los agentes encuentren exploits

El mantenedor de cohttp, Anil Madhavapeddy, relata cómo un simple rumor sobre una vulnerabilidad de path traversal permitió a agentes de IA encontrar y explotar el fallo en minutos, incluso antes de que se publicara el parche. Este incidente revela que los embargos de seguridad ya no son efectivos: con solo una pista, los sistemas automatizados pueden generar exploits rápidamente. El autor propone cambios urgentes en los procesos de seguridad del software de código abierto, como desarrollo de parches en privado, lanzamientos continuos y protección proactiva a nivel de protocolo.

Dado que el simple rumor de un problema de seguridad parece ser suficiente para que los atacantes encuentren nuevos exploits, vamos a tener que cambiar la forma en que manejamos las respuestas de seguridad en el código abierto.
  1. nickcw

    Esto describe mi vida como mantenedor de código abierto en estos momentos. En los primeros 10 años del proyecto rclone recibimos unas 20 divulgaciones de seguridad a través de GitHub. ¡Hemos tenido que lidiar con más de 40 en el último mes! Eso me ha consumido una cantidad enorme de tiempo, incluso usando herramientas de IA para clasificarlas y proponer correcciones para revisar. La tasa de acierto de esas divulgaciones es bastante buena: alrededor del 75% tienen algo que merece la pena investigar. Las configuraciones de rclone se han vuelto cada vez más improbables, así que espero que acaben por desaparecer. Estuve considerando fusionar las correcciones directamente en la rama principal solo para facilitarme la vida, en lugar de mantener una docena de correcciones de seguridad independientes en ramas y fusionarlas en la versión puntual, esperando no tener demasiados conflictos que resolver. He decidido mantener el proceso por ahora. GitHub asigna CVEs a los avisos. Antes del apocalipsis de la IA tardaban 2-3 días en asignarlos, pero ahora van con 3-4 semanas de retraso, así que tengo que publicar las versiones puntuales con CVE-PENDING en el changelog, lo cual no es ideal. No sé cuál es la solución, pero definitivamente es un problema para nosotros.

  2. godelski

    Es más fácil encontrar errores y corregirlos, pero hay menos voluntad que nunca. Mis jefes solo quieren velocidad y me darán una charla de 30 minutos sobre por qué no necesito resolver un error que Claude resolvió en 5 minutos, que yo he verificado y que ya está en un PR abierto. Mientras tanto, estamos sacando errores cada vez más rápido. No importa lo buena que sea la IA corrigiendo errores, nunca los arreglaremos si no hay voluntad de arreglar las cosas. El software nunca será bueno si no hay voluntad de hacer buen software. El problema siempre ha sido la voluntad. Hay demasiados productos mejores. Es una locura que en una época en la que podemos mejorar en velocidad y calidad sigamos eligiendo la velocidad y nos digamos a nosotros mismos que es velocidad.

  3. bri3d

    No creo que esto sea nuevo con los LLM (encontrar un exploit basándose en unas pocas palabras al azar siempre ha sido una parte divertida del desarrollo de exploits), pero se ha escalado y democratizado hacia la explotación masiva de objetivos de bajo valor. Extraer PoCs de exploits de parches, mensajes de commit y frases sueltas escuchadas o leídas es una práctica tan antigua como la investigación de vulnerabilidades. La diferencia con los LLM es que una explosión de actores "suficientemente hábiles" (humanos o no) ha permitido a actores descuidados o de baja habilidad "explotar todo Internet" de una manera que antes no podían. Sí estoy de acuerdo con las ideas del autor; la mayoría de estas cosas deberían haberse hecho mucho antes, y supongo que en cierto sentido es bueno que ahora haya un factor que lo fuerce.

  4. stephbook

    Creo que el despliegue y la implementación son problemas aún mayores. ¿Quién actualiza su pila de software en 10 minutos? La mayoría de las ejecuciones de CI tardan más en verificar que la lógica de negocio sigue funcionando. Añade a eso el peligro de los ataques a la cadena de suministro, donde ni siquiera quieres actualizaciones automáticas.

  5. rndhouse

    Construí una herramienta que monitorea los commits e intenta detectar correcciones de errores silenciosas. Con modelos de clase GPT-5.5, puede identificar correcciones ocultas en commits que de otro modo serían rutinarios de manera bastante fiable. Ofuscar los cambios de código lo suficiente como para evitar la detección es difícil. He oído hablar de al menos un proyecto (¿c-lightning?) que publicó temporalmente un binario de código cerrado como solución provisional hasta que los usuarios pudieran actualizar de forma segura.

  6. ChrisMarshallNY

    Lamentablemente, parece que la lección de esto es mantener los repositorios privados. No soy fan de eso, pero creo que muchos lo sacarán de aquí.

  7. jameshart

    Me pregunto cuál es la tasa de éxito en general de Claude para encontrar un exploit exitoso cuando se le incita con un rumor que le lleva a asumir que el error está ahí. "Me han dicho que hay un exploit de path traversal en este paquete. ¿Puedes encontrarlo?" — probablemente tenga una probabilidad bastante alta de encontrar uno, incluso si te acabas de inventar ese rumor.

  8. janpeuker

    Entiendo la ansiedad por los nuevos errores, pero para ser honesto, temo más que en unos años sea tan barato corregir errores de seguridad medios y altos que el hacking discreto y la búsqueda de violaciones de privacidad preocupantes se vuelvan prohibitivamente caros para los ciudadanos.

Más de este día

2026-08-28