Google suspende el bug bounty de código abierto por informes IA

📌 Novedades posteriores: Chrome: cadena de 250.000 dólares creada con IA en seis días (14 de octubre de 2026) · Chrome VRP: Google sube las recompensas, pero solo en parte (13 de octubre de 2026)

Google ha suspendido hasta 2027 una parte de su programa de recompensas por vulnerabilidades en proyectos de código abierto, el Open Source Vulnerability Rewards Program (OSS VRP). El motivo, en palabras de la empresa, es un fuerte aumento de los envíos automáticos, en su gran mayoría no válidos.

No hay CVE que corregir ni productos que actualizar. Aun así, la noticia interesa a cualquiera que gestione vulnerabilidades: la inteligencia artificial abarata la producción de informes convincentes, mientras que verificarlos sigue requiriendo el tiempo de un técnico.

Qué ha pasado

Según Infosecurity Magazine, el anuncio llegó el 1 de octubre de 2026 con un mensaje de Google en redes sociales. The Hacker News y CSO Online precisan que la pausa afecta a los informes de vulnerabilidades de producto del OSS VRP: Infosecurity Magazine habla en general de suspensión del programa, pero confirma dos excepciones:

• los informes sobre la cadena de suministro (supply chain) del OSS VRP se siguen aceptando;
• los informes ya enviados no se ven afectados por la suspensión.

Google quiere reorganizar el programa y prevé dar novedades en el primer trimestre de 2027. Mientras tanto, invita a los investigadores a buscar vulnerabilidades en sus otros programas de recompensas o a participar en el Patch Rewards Program.

El programa OSS VRP

El OSS VRP nació en agosto de 2022 y premia a quien encuentra vulnerabilidades en los proyectos de código abierto de Google. Cubre las últimas versiones del software alojado en los repositorios públicos de Google en GitHub y en algunos repositorios de otras plataformas, incluida su configuración: workflows de GitHub Actions, reglas de acceso, configuraciones de las aplicaciones de GitHub. Las recompensas van de 100 a 31.337 dólares, según la gravedad y la importancia del proyecto.

Las vulnerabilidades en proyectos ligados a Google Cloud o a los productos de IA pasan, en cambio, por programas específicos, el Cloud VRP y el AI VRP.

Las señales de los meses anteriores

Según CSO Online, la suspensión llega tras otros intentos de contener el problema. En marzo Google ya había endurecido las reglas del OSS VRP tras un fuerte aumento de los informes generados con IA: algunos describían de forma errónea cómo se activa la vulnerabilidad, otros señalaban defectos de código con un impacto mínimo en la seguridad. Para algunas clases de vulnerabilidades Google empezó a pedir pruebas más sólidas, como resultados reproducibles o parches aceptados, y después dejó de premiar ciertos informes de producto de nivel más bajo.

El cuadro técnico: el cuello de botella es la verificación

Las fuentes no describen ataques, malware ni indicadores: no hay una cadena de ataque que mapear en MITRE ATT&CK. El punto técnico es otro: quien recibe un informe debe establecer si el código citado existe, si la ruta de ataque es alcanzable y si el impacto es real. Un informe creíble se genera en minutos; comprobarlo puede obligar a un ingeniero a seguir el código y reproducir las condiciones declaradas.

Un gran volumen de envíos no significa necesariamente poca calidad. CSO Online cita dos ejemplos:

• Vercel recibió 1.285 informes en dos semanas durante un reto de seguridad sobre su entorno Sandbox, automatizó parte del triaje y al final validó algunas decenas;
• una vulnerabilidad crítica en Rejetto HTTP File Server, encontrada con la ayuda de un modelo de IA, fue después objeto de intentos de explotación.

Los expertos consultados por CSO Online señalan dos riesgos para quien defiende:

1. el triaje como objetivo: un canal de notificación sin filtros podría permitir a un atacante consumir los recursos del equipo de seguridad sin vulnerar ningún sistema, por ejemplo enviando variantes del mismo informe a varios servicios. Las fuentes precisan que no hay elementos para afirmar que Google haya sido objeto de una campaña así;
2. la prompt injection en los informes: si el triaje se confía a un agente de IA, un informe malicioso puede contener instrucciones pensadas para manipular su evaluación o hacerle realizar acciones a través de las herramientas conectadas.

Impacto para las empresas europeas e italianas

La suspensión afecta al programa de Google, pero el mismo desequilibrio entre descubrimiento y verificación puede darse en tu empresa: en los informes que llegan de fuera y en los resultados de las herramientas de análisis asistidas por IA que usas internamente. Un hallazgo que llega al responsable de una aplicación antes de ser evaluado puede hacer perder horas de trabajo incluso cuando la versión afectada no está instalada o el código vulnerable no es alcanzable.

Para las entidades sujetas a NIS2, la gestión y la divulgación de vulnerabilidades forman parte de las medidas de gestión del riesgo que exige la directiva: un proceso de triaje que solo aguanta con volúmenes bajos es un punto débil a tener en cuenta.

Qué hacer ahora

1. Pide pruebas reproducibles a quien notifique una vulnerabilidad por tus canales, agrupa los informes duplicados y limita los envíos cuando aparezcan patrones de abuso.
2. Comprueba primero la presencia y la alcanzabilidad: ¿está instalada la versión afectada? ¿Está expuesto el servicio? Solo entonces el informe se convierte en una prioridad.
3. Trata cada resultado de un escáner como una hipótesis, no como la prueba de una vulnerabilidad explotable.
4. Prioriza según el contexto: un sistema expuesto y crítico o una vulnerabilidad ya explotada pesan más que la mera puntuación de gravedad.
5. Considera el texto y el código de los informes como entrada no fiable: si usas IA para el triaje, mantén las pruebas lejos de los sistemas de producción y haz que una persona verifique las acciones importantes.
6. Mide el esfuerzo de verificación y la antigüedad de las vulnerabilidades de alto riesgo confirmadas, no el número de hallazgos que producen las herramientas. Si el equipo dedica cada vez más tiempo a descartar informes débiles mientras los problemas confirmados siguen abiertos, hay que revisar el proceso.

Cómo ayuda ARXDOME

ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, con su antigüedad y destacando las ya explotadas por los atacantes: te ayuda a ver enseguida si un software notificado está realmente instalado en tus sistemas. ARX Expose añade la vista desde fuera, con las vulnerabilidades conocidas en los servicios públicos, para distinguir lo que está expuesto de lo que no.

Última actualización: 6 de octubre de 2026