Un fallo de 25 USD que vale 500 000 USD: la IA rompe la economía de los VDP

El coste de encontrar un fallo crítico acaba de desplomarse. Un investigador de Searchlight Cyber apuntó un modelo de vanguardia al núcleo de WordPress, gastó unos 25 USD en cómputo a lo largo de unas diez horas y sacó a la luz una inyección SQL previa a la autenticación que escala hasta la ejecución remota de código, una clase de fallo que los intermediarios de exploits valoran en hasta 500 000 USD. No es una historia sobre basura generada por IA. Es justo lo contrario, y es el modo de fallo que casi ningún programa de divulgación de vulnerabilidades presupuestó: una avalancha de hallazgos genuinamente válidos y genuinamente críticos que llegan más rápido de lo que cualquier turno de triaje humano puede acusarlos, verificarlos o pagarlos.

Si gestionas un VDP o un programa de bug bounty, todo tu modelo de costes descansa sobre un supuesto silencioso: que encontrar un fallo crítico es caro y raro. Ese supuesto acaba de romperse. Esto es lo que significa para tus SLA, tu presupuesto de recompensas y tu cola de triaje, y qué cambiar este trimestre.

Qué pasó en realidad y qué está verificado

Adam Kues, investigador de Searchlight Cyber, adaptó una receta de prompting de IA para convertirla en un arnés multiagente de caza de vulnerabilidades y apuntó un modelo de vanguardia al código fuente de WordPress. El investigador informa de que hicieron falta más de diez horas de ejecución del modelo, con un coste aproximado de 25 USD, para descubrir una inyección SQL previa a la autenticación que escala a RCE. Después la reprodujo contra una instalación estándar de WordPress: le pidió al modelo que robara la dirección de correo del administrador, y este se la devolvió en pantalla en cuestión de minutos. Retuvo la publicación y preparó un informe de divulgación.

Aquí importan dos cifras de referencia, y solo una está verificada de forma independiente. Los 25 USD y las diez horas de ejecución son el relato del propio investigador sobre su propio trabajo, así que trátalos como declarados, no como establecidos. La valoración de 500 000 USD es la que sí puedes comprobar: la lista pública de precios del Exploit Acquisition Program de Crowdfense cotiza «WordPress (RCE): 500k USD», el mismo nivel que la ejecución remota de código en Apache HTTP Server y Microsoft IIS, por encima de Nginx (350 000 USD) y muy por encima de otros gestores de contenidos como Joomla (40 000 USD) o Drupal (25 000 USD). El techo del mercado gris es real, no un adorno retórico. En la fuente no se asignó ningún CVE, y el nombre exacto del modelo es el marco narrativo del artículo, no la especificación de un producto comercial.

La distancia entre ambas cifras es toda la historia. Coste de encontrarlo: unos 25 USD. Valor para un atacante: hasta 500 000 USD. Antes esos dos números estaban más o menos correlacionados, porque entre ellos se interponía una experiencia humana escasa. La IA acaba de eliminar al humano como cuello de botella.

La «basura generada por IA» era el problema fácil

Durante dos años la conversación del sector sobre IA y bug bounties ha girado en torno al ruido. CVE inventados, nombres de funciones alucinados, informes plantilla, esa clase de basura de baja calidad y alto volumen que llevó al mantenedor de curl, Daniel Stenberg, a quejarse públicamente de que los informes generados por IA le hacían perder el tiempo. Nosotros mismos escribimos sobre ese modo de fallo en la basura generada por IA está inundando el triaje de bug bounty. La basura desperdicia horas de triaje. Es molesta, es cara a gran escala, y los defensores han invertido esfuerzo real en afinar filtros para rechazarla.

El hallazgo de WordPress es lo contrario, y podría decirse que es peor. Esto es señal de alta calidad y alta severidad, producida a velocidad de máquina y con un coste marginal casi nulo. La basura amenaza tu tiempo de triaje. Una avalancha de críticos reales amenaza tres cosas a la vez: tu SLA de acuse de recibo, tu presupuesto de recompensas y tu canal de parcheo. Afinaste tu recepción para rechazar basura. No presupuestaste una abundancia de oro.

He aquí la incómoda realidad operativa: ahora ambos modos de fallo llegan juntos. La misma tecnología que acuña críticos válidos también produce falsificaciones convincentes, CVE reales pero antiguos reenviados como nuevos, referencias de código plausibles a funciones que no existen. El triaje ya no puede dar por sentado que un informe será fiable o será basura. Tiene que asumir que ambos modos conviven en la misma cola, todos los días.

Por qué el descubrimiento barato rompe la economía del bug bounty

El precio de un bug bounty codifica un trato implícito. Encontrar un fallo crítico es caro y raro, así que una recompensa de unos pocos miles de dólares es un reparto justo del valor con un experto escaso que eligió la divulgación en lugar del mercado gris. Cuando el coste de descubrimiento se desploma a 25 USD, ese trato se invierte. El intermediario sigue pagando 500 000 USD, porque el valor ofensivo de un RCE previo a la autenticación en cientos de millones de instalaciones no cambió. Pero el pago del programa, a menudo uno a tres órdenes de magnitud menor, ahora parece un error de redondeo frente al verdadero valor del fallo y frente al volumen de fallos que está a punto de llegar.

Pon tres números en un mismo marco:

El desajuste no es que los programas sean tacaños. Es que el desplome del coste de descubrimiento ensanchó una brecha ya grande entre lo que vale un fallo para un atacante y lo que un defensor puede pagar de forma racional, mientras multiplica el número de fallos de ese tipo que recibirá un programa. Un investigador que puede acuñar críticos por 25 USD cada uno se enfrenta a una disyuntiva clara: enviarlo a un programa que, con suerte, paga 5 000 USD y exige condiciones de divulgación, o vendérselo a un intermediario por 500 000 USD. El descubrimiento barato no solo tensa la capacidad de triaje. Agudiza la atracción hacia el mercado gris precisamente para los hallazgos de mayor severidad que tu programa más necesita recibir.

Ningún programa autoalojado igualará jamás a un intermediario. Ese no es el objetivo, y fingir lo contrario derrocha credibilidad. El objetivo realista es captar a la gran población de investigadores que preferirían divulgar, siempre que la fricción y la brecha de pago sean grandes pero no insultantes. Eso es un problema de diseño del programa, y tiene tres palancas.

Las tres cosas que todo responsable de un VDP tiene que reajustar ya

El descubrimiento barato no exige una plataforma nueva. Exige reajustar tres elementos básicos que tu programa ya tiene, o debería tener: niveles de SLA, economía de las recompensas y capacidad de triaje. El CSIRT autoalojado de Kit codifica cada uno de ellos como configuración, así que usaré sus valores por defecto como punto de referencia concreto. Los principios valen igual con Kit, con HackerOne o con un security.txt y un buzón compartido.

Reajustar el SLA: separa «te hemos oído» de «lo hemos arreglado»

Un SLA plano se derrumba ante una avalancha de críticos válidos. La solución es partir una promesa en dos. El acuse de recibo es barato y rápido: dice «una persona tiene tu informe y hay un reloj en marcha». La resolución es cara y lenta: dice «esto está parcheado». Confundirlos significa que cada pico de entradas amenaza tu compromiso público de arreglar las cosas en un plazo que ya no controlas.

Reserva tus ventanas de resolución más ajustadas solo para el nivel de severidad más alto, para que una oleada de críticos no pueda colapsar tu cola. El Csirt::SlaConfig de Kit trae esta forma por defecto: una promesa de acuse de recibo de 72 horas, y luego objetivos de resolución graduados por severidad de 24 horas para súper crítico, 72 horas para crítico, 7 días para alto y plazos progresivamente más largos para medio y bajo. La clave del diseño es que el acuse de recibo se mantiene constante y barato mientras la resolución escala con la severidad. Cuando cien informes válidos aterrizan en una semana, aún puedes cumplir el «te hemos oído, en menos de 72 horas» para todos ellos, y el «lo hemos arreglado, en menos de 24 horas» solo para los verdaderos 10.0.

Reajustar los precios de las recompensas: construye un nivel superior defendible y una política de deduplicación

Tu vocabulario de severidad necesita una banda por encima de «crítico». La IA está a punto de sacar a la luz más CVSS 10.0 reales de los que los programas veían históricamente en un año, y un RCE previo a la autenticación en una base de instalación enorme es exactamente eso. Kit lo modela con un nivel super_critical (CVSS 10.0) situado por encima de critical (de 9.0 a 9.9), y una BountyMatrixConfig graduada que va desde 0 USD para lo informativo hasta 5 000 a 10 000 USD para súper crítico.

Sé honesto sobre lo que es ese nivel superior. El generoso valor por defecto autoalojado de Kit, de 5 000 a 10 000 USD, sigue siendo de 50 a 100 veces inferior al precio de intermediario para el mismo fallo que encontró Kues. No cerrarás esa brecha, así que deja de intentarlo. Lo que sí puedes hacer es empinar la curva y ensanchar la cima para que quede claro que merece la pena divulgar los hallazgos de mayor severidad en lugar de guardarlos en un cajón. Lo explicamos en detalle en cómo estructurar los niveles de recompensa de un bug bounty.

Luego añade una política de deduplicación, porque de repente es determinante. Cuando muchos investigadores apuntan el mismo modelo al mismo objetivo popular, la colisión en fallos idénticos no es un riesgo, es el resultado previsible. Sin una regla clara y publicada de «primer informe válido», gastarás tu credibilidad arbitrando disputas de empate técnico, justo el escenario que tratamos en cómo resolver disputas de pago en un bug bounty. Por eso Kit activa la deduplicación por defecto en su TriageConfig.

Triaje a velocidad de máquina: filtra la basura y da vía rápida a los críticos reales

El triaje tiene ahora dos cometidos que tiran en direcciones opuestas. Debe rechazar falsificaciones convincentes y validar rápidamente señal genuina de alta severidad, a menudo en la misma cola y el mismo día. El triaje a ritmo humano no puede hacer ambas cosas a gran escala.

El cribado es la primera mitad. El Csirt::AiScreening de Kit puntúa un ai_confidence_score (de 0.0 a 1.0, la probabilidad de que un informe sea basura generada por IA) y señala indicios conocidos de fabricación como funciones alucinadas, CVE inventados, un CVE anterior citado como nuevo e informes sin una prueba de concepto específica. Esa capa se construyó para el problema de la basura, y sigue teniendo que ejecutarse, porque la basura no va a desaparecer.

Pero el cribado es solo la mitad del nuevo problema. La frontera está en dar vía rápida a los críticos válidos. Eso significa autoescalado y enrutamiento a la guardia para que un súper crítico nunca se quede en una cola esperando a que alguien se dé cuenta. El TriageConfig de Kit admite severidades de escalado (crítico y súper crítico por defecto), requisitos de repetición de pruebas y autoasignación a la guardia, conectados a una rotación de guardia y a PagerDuty. La lección para todo responsable de programa: filtrar la basura ya es lo mínimo; validar y priorizar rápido la señal genuina a gran escala es la capacidad que de verdad toca construir a continuación.

Qué hacer este trimestre

No puedes pujar más que un intermediario, y no lo necesitas. Necesitas un programa lo bastante rápido, creíble y bien instrumentado como para que un investigador que prefiere divulgar no tenga ninguna excusa basada en la fricción para acudir al intermediario. En concreto:

1. Divide tu SLA. Publica una ventana de acuse de recibo rápida y constante y ventanas de resolución graduadas por severidad. Reserva tu objetivo de resolución más ajustado para un nivel superior por encima de «crítico».
2. Añade una banda de súper crítico y reajusta el precio de la cima. Ensancha y empina la curva de recompensas para que quede claro que merece la pena divulgar los verdaderos 10.0. Acepta la brecha frente a los precios de intermediario; lo que no puedes permitirte es que la tuya resulte insultante.
3. Publica una regla de deduplicación antes de necesitarla. Gana el primer informe válido y totalmente reproducible. Ponlo por escrito ahora, no durante una disputa.
4. Aplica un triaje en dos frentes. Puntúa la probabilidad de IA para atrapar falsificaciones, y autoescala los críticos válidos a la guardia para que nada grave espere en una cola.
5. Instrumenta el tiempo de acuse de recibo. Si no puedes ver tu tiempo hasta el acuse de recibo por severidad, no podrás defenderlo cuando llegue el volumen.

El coste de encontrar un fallo crítico cayó a 25 USD. El valor de ese fallo para un atacante no se movió. Tu programa vive en la brecha entre esos números, y la brecha acaba de hacerse más ancha y más concurrida. Los programas que sobrevivan al próximo año no serán los que tengan los mayores fondos de recompensas. Serán los que acusen recibo rápido, pongan precios con honestidad, dedupliquen con justicia y escalen los críticos reales antes de que los demás hayan siquiera abierto el ticket.

Cómo gestiona la avalancha el CSIRT de Kit

Kit es una plataforma nativa de IA para startups, y su módulo autoalojado de CSIRT y VDP existe precisamente porque los fundadores acaban asumiendo el triaje de seguridad por defecto. Trae las cuatro palancas que este cambio exige como configuración en lugar de como un proyecto: una banda de severidad super_critical por encima de crítico, SLA de acuse de recibo y resolución separados, una matriz de recompensas graduada que puedes reajustar, deduplicación y autoescalado a la guardia, y un cribado con IA que puntúa la probabilidad de que un informe sea basura.

Lo que no hace es fingir ser un intermediario de 500 000 USD, y esa honestidad es la clave. Un programa bien instrumentado, rápido y transparente capta a los investigadores que preferirían divulgar antes que vender, siempre que no hagas la divulgación lenta, opaca o insultante. La curva de costes para encontrar fallos críticos se desplomó. El diseño de tu programa es la única palanca que aún controlas por completo, así que afínala antes de la avalancha, no durante ella.