Un mantenedor de código abierto publica el parche de un bug de seguridad y, diez minutos después, ya tiene sondeos automatizados golpeando su servidor con el patrón exacto del exploit. Así describe Anil Madhavapeddy, mantenedor de la librería cohttp de OCaml, lo que le pasó la semana pasada: ya no hace falta un exploit público para que te ataquen, alcanza con el rumor de que existe un bug.
El caso destapa un fenómeno que un paper reciente bautizó como bugonomics: agentes de inteligencia artificial que convierten cualquier pista (un commit, un hilo de correo, un pull request) en un exploit funcional en minutos, mucho antes de que exista un aviso público formal.
TL;DR
- El tiempo medio para explotar una vulnerabilidad ya es de -7 días: el exploit llega antes que el parche público.
- En 2018-2019 ese promedio era de 63 días; cruzó el cero en 2024, según los datos que cita Anil Madhavapeddy.
- Un estudio de Fang et al. halló que un agente GPT-4 explotó el 87% de un benchmark de 15 vulnerabilidades con la descripción del CVE, contra apenas 7% sin ella.
- El mantenedor de cohttp (OCaml) recibió sondeos de path traversal apenas 10 minutos después de abrir el pull request público del parche.
- La vulnerabilidad de marimo CVE-2026-39987 pasó de advisory a primer intento de explotación en 9 horas, sin PoC público.
- Langflow CVE-2026-33017 tardó 20 horas entre el aviso y el primer intento de explotación masiva.
- Un paper de mayo de 2026 acuñó el término bugonomics: el cuello de botella ya no es hallar bugs, sino la capacidad de los mantenedores de validarlos y parchearlos.
- Project Glasswing ya cubre 150 organizaciones en 15 países, pero proyectos chicos como cohttp siguen sin acceso parejo a los modelos frontera.
Introducción: qué es la bugonomics
Anil Madhavapeddy mantiene MirageOS y cohttp, la librería HTTP más usada del ecosistema OCaml. El bug que reportó era un caso clásico de path traversal: una ruta de archivo mal validada que permite escapar del directorio esperado. Nada exótico, un tipo de fallo documentado hace décadas.
Lo distinto no es el bug, es la velocidad con la que pasó de rumor a exploit funcional. Eso es la bugonomics: la economía invertida donde armar un exploit ya es más barato y más rápido que defenderse. No es un problema exclusivo de OCaml, aplica a cualquier ecosistema con historial público: npm, PyPI, crates.io, cualquier repositorio en GitHub.
Qué pasó
El reporte llegó de forma privada, por un canal de Slack compartido con Jane Street, y quien lo reportó lo había encontrado usando Claude Fable. Antes de revisar el patch en detalle, Madhavapeddy le pidió a su propio agente que investigara problemas de normalización de rutas en el mismo código. Fable se negó: el bloqueo de seguridad del modelo exige acceso a Project Glasswing, algo que Madhavapeddy no tiene.
DeepSeek V4 Pro no tuvo el mismo reparo. El modelo encontró varios problemas relacionados y, en menos de un minuto, generó un exploit capaz de probar un servidor local en vivo. Ese es el dato que más incomoda del caso: construir el exploit tomó menos tiempo que redactar el aviso de seguridad.
Después de coordinar una solución con quien reportó el bug, Madhavapeddy abrió el pull request de forma pública en el repositorio de cohttp. En circunstancias normales, ese paso toma unos días de revisión y una release en una o dos semanas. En este caso, a los diez minutos de abrir el PR, su servidor ya recibía sondeos con secuencias de traversal codificadas en porcentaje, del tipo %2e%2e%2f (el equivalente a ../). Alguien, o algo, ya estaba probando el patrón exacto del bug recién publicado.
⚠️ Ojo: si a vos te tomó un minuto armar el exploit en tu propia máquina, diez minutos de ventana para el primer sondeo automatizado en producción en realidad es bastante tiempo.
El primer sondeo llegó 10 minutos después de publicar el parche.
sequenceDiagram
participant M as Mantenedor
participant PR as Pull Request publico
participant IA as Agente de IA
participant S as Servidor en produccion
M->>PR: abre el parche de seguridad
PR-->>IA: el rumor del bug queda visible
IA->>IA: genera un exploit en menos de un minuto
IA->>S: envia sondeos con paths codificados
Note over M,S: los primeros sondeos llegan en 10 minutos
Contexto e historia
El caso de cohttp no es aislado, es la punta visible de una tendencia medida. Según los datos que recopila Madhavapeddy, el tiempo medio entre la publicación de un aviso y el primer intento de explotación era de unos 63 días en 2018-2019. Ese número cruzó el cero en 2024 y hoy, en 2026, es de -7 días: en promedio, la explotación ya empieza antes de que exista un parche público.
Un estudio de Fang y colegas cuantificó de dónde viene ese salto: un agente basado en GPT-4, con acceso solo a la descripción de un CVE, explotó el 87% de un banco de pruebas de 15 vulnerabilidades. Sin esa descripción, el mismo agente solo llegó al 7%. La diferencia entre esos dos números es, literalmente, el valor de un rumor: alcanza con saber que algo existe y dónde buscar.
Los ejemplos recientes confirman el patrón. La vulnerabilidad de marimo CVE-2026-39987 pasó de advisory a primer intento de explotación en 9 horas, sin que existiera un proof-of-concept público. Langflow CVE-2026-33017 tardó 20 horas. Cohttp, sin advisory formal todavía y solo con un pull request abierto, tardó 10 minutos.
CasoTiempo hasta el primer intento de explotación¿Existía PoC público?Promedio histórico (2018-2019)63 días después del avisoSí, en la mayoría de los casosPromedio actual (2026)-7 días (antes del parche)No necesariamentemarimo CVE-2026-399879 horas desde el advisoryNoLangflow CVE-2026-3301720 horas desde el advisoryNocohttp (OCaml)10 minutos desde el pull request públicoNo, ni advisory formal
Detalles técnicos y rendimiento
Un path traversal pasa cuando un servidor arma una ruta de archivo concatenando directamente un valor que viene del usuario, sin normalizar secuencias como ... Si el servidor no verifica que la ruta resultante siga dentro del directorio esperado, un atacante puede pedir ../../etc/passwd (o su versión codificada, %2e%2e%2f) y leer archivos fuera de ese directorio.
Así de simple se ve el error en un servidor de archivos estático mal escrito:
let read_static_file base_dir requested_path =
let full_path = base_dir ^ "/" ^ requested_path in
read_file full_path
(* requested_path = "../../etc/passwd" escapa de base_dir sin control *)
La corrección real no es solo filtrar los puntos: hay que resolver la ruta a su forma canónica y confirmar que el resultado siga dentro del directorio base antes de tocar el disco:
let read_static_file base_dir requested_path =
let candidate = Filename.concat base_dir requested_path in
let resolved = Unix.realpath candidate in
let base_resolved = Unix.realpath base_dir in
let dentro_del_base =
String.length resolved >= String.length base_resolved
&& String.sub resolved 0 (String.length base_resolved) = base_resolved
in
if dentro_del_base then read_file resolved
else raise (Invalid_argument "path traversal detectado")
Lo que corrió DeepSeek V4 Pro para Madhavapeddy fue, en esencia, la versión automatizada de encontrar el primer patrón que no resuelve rutas en un repositorio completo, en cuestión de segundos, y armar encima un cliente HTTP que prueba variantes codificadas del payload hasta encontrar una que el servidor no filtre. Eso es lo que tomó menos de un minuto: no escribir el exploit desde cero, sino que un modelo con acceso al diff y al historial del repositorio genere y pruebe variantes hasta dar con la que funciona.
Validar la ruta resuelta contra el directorio base es la defensa real, no filtrar puntos.
Cómo empezar: auditar tus propios logs
No hace falta ser cohttp para estar expuesto al mismo patrón. Cualquier servidor que sirva archivos, imágenes de perfil o plantillas puede tener el mismo bug. Lo primero y más barato es revisar si ya recibiste sondeos:
grep -E "%2e%2e%2f|%252e%252e|\.\./\.\./" /var/log/nginx/access.log | tail -n 50
Ese comando busca las variantes más comunes de traversal codificado (simple y doble codificación) en el log de acceso de nginx. Si aparecen líneas con códigos 400 o 403 repetidos desde la misma IP, ya tenés un sondeo activo, con o sin bug real que explotar.
Para mitigar mientras se aplica el parche, un jail de fail2ban específico corta el ruido rápido:
[cohttp-traversal]
enabled = true
port = http,https
filter = cohttp-traversal
logpath = /var/log/nginx/access.log
maxretry = 3
bantime = 3600
Esto no reemplaza el parche (nunca reemplaza el parche), pero reduce la ventana de sondeo automatizado mientras se revisa y se libera la versión corregida.
Impacto y análisis: el cuello de botella es el defensor
El proceso de seguridad tradicional asume que la vulnerabilidad se puede embargar: se arregla en privado, se avisa a los afectados y recién después se publica. Ese modelo dependía de que el secreto del detalle técnico comprara tiempo. Los números de este artículo muestran que ese tiempo ya casi no existe: un agente con una pista vaga y acceso al historial de un repositorio hace su propia investigación.
Un paper de mayo de 2026 le puso nombre a esto: bugonomics. Su argumento central es que el cuello de botella ya no es generar exploits (eso lo hacen los modelos, cada vez más rápido y más barato), sino la capacidad de remediación del defensor: cuánto puede validar, priorizar y liberar un mantenedor humano con el tiempo y las herramientas que tiene.
💭 Clave: la pregunta no es si el modelo frontera, el modelo abierto o el análisis estático de programas ganan. La pregunta es cómo orquestarlos para que la poca capacidad de validación y release de un mantenedor se use en arreglos duraderos, no en redactar reportes.
Hay además una asimetría incómoda. A Madhavapeddy, un mantenedor legítimo tratando de auditar su propio código, Claude Fable le negó el acceso por falta de autorización de Project Glasswing. DeepSeek V4 Pro, sin ese mismo control, lo ayudó sin problema. Project Glasswing ya se expandió a 150 organizaciones en 15 países, pero un proyecto chico como cohttp todavía queda afuera del circuito de acceso privilegiado, mientras que cualquiera con una cuenta de un modelo menos restringido puede buscar exploits sobre el mismo repositorio público sin pedir permiso.
Las empresas grandes ya se adaptaron a su manera: Google empuja microupdates directo a sus productos, sin depender del ciclo de release del repositorio. Proyectos como OCaml o Docker no tienen ese lujo: no controlan el punto final donde corre su software, y las distribuciones empaquetan y liberan en sus propios tiempos.
Qué sigue
Madhavapeddy es claro en que la triage manual no debería desaparecer, pero admite un aumento insostenible de actividad automatizada desde que salieron modelos como Fable. Todavía no hay consenso sobre cuánto del tráfico entrante en cualquier repositorio popular es hoy generado por máquinas buscando el próximo bug, pero según lo que describe, es obviamente mucho.
Lo más probable en el corto plazo: procesos de embargo más cortos o directamente descartados en favor de arreglar y publicar de inmediato, inversión en agentes propios que auditen el código antes de que lo haga un atacante, y presión para que proyectos pequeños tengan el mismo acceso a modelos frontera que las organizaciones grandes ya tienen vía programas como Glasswing.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré el grep de traversal codificado contra tus propios logs de acceso de la última semana y confirmá si ya te llegó un sondeo con el patrón %2e%2e%2f.
Preguntas frecuentes
¿Qué es la bugonomics?
Es el término que un paper de mayo de 2026 usó para describir un escenario donde generar un exploit ya es más rápido y barato que la capacidad de un mantenedor de validarlo y parchearlo, invirtiendo la lógica tradicional de la seguridad ofensiva y defensiva.
¿Qué es un ataque de path traversal?
Es un bug donde el servidor arma una ruta de archivo con datos del usuario sin normalizar secuencias como .., lo que permite leer o escribir archivos fuera del directorio que el servidor debería exponer.
¿Por qué el tiempo medio de explotación ya es negativo?
Porque en promedio los intentos de explotación automatizados empiezan antes de que el parche esté disponible públicamente: agentes de IA generan y prueban exploits apenas detectan una pista, como un commit, un pull request o un hilo de discusión, sobre un posible bug.
¿Todavía sirven los embargos de seguridad?
Su efectividad bajó mucho. El supuesto de que el secreto del detalle técnico compra tiempo ya no se sostiene cuando un agente puede investigar el código por su cuenta a partir de una pista mínima, como pasó con cohttp.
¿Qué es Project Glasswing?
Es el programa que da a mantenedores y organizaciones autorizadas acceso a modelos frontera sin las restricciones de seguridad que bloquean su uso para investigación ofensiva propia; según Madhavapeddy, ya cubre 150 organizaciones en 15 países.
¿Cómo protejo mi proyecto open source de este tipo de sondeos?
Auditá tus propios logs de acceso en busca de patrones de traversal codificado, aplicá mitigaciones temporales como un jail de fail2ban mientras preparás el parche, y validá cualquier ruta de archivo resolviéndola contra el directorio base antes de usarla.
Referencias
- Anil Madhavapeddy: Just a rumour of a bug is enough to find a security exploit these days: el artículo original con el caso de cohttp y los datos citados en esta nota.
- Repositorio de cohttp en GitHub: la librería HTTP de OCaml mantenida por Anil Madhavapeddy y el proyecto Mirage.
- NVD: CVE-2026-39987: registro oficial de la vulnerabilidad de marimo mencionada en el artículo.
- NVD: CVE-2026-33017: registro oficial de la vulnerabilidad de Langflow mencionada en el artículo.
- OWASP: Path Traversal: explicación de referencia sobre este tipo de vulnerabilidad.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)