Chrome VRP: Google sube las recompensas, pero solo en parte

Google ha subido las recompensas del Chrome Vulnerability Reward Program (Chrome VRP), el programa que paga a quien notifica vulnerabilidades en el navegador. El anuncio es del martes 13 de octubre de 2026 y lo recogen SecurityWeek y Help Net Security. Las novedades afectan sobre todo a los fallos de corrupción de memoria y a las fugas de la sandbox.

Es el segundo cambio de Google en sus programas de recompensas en pocas semanas: a principios de octubre ARX News contó la suspensión de las recompensas por vulnerabilidades de producto del OSS VRP, desbordado por informes automáticos no válidos. No hay CVE ni actualizaciones ligadas a esta noticia.

Qué ha pasado

Según SecurityWeek, en abril de 2026 Google redujo de forma considerable las recompensas estándar para algunas vulnerabilidades de Chrome, para centrar el programa en los informes útiles para actuar; algunos investigadores observaron recompensas diez veces más bajas. La base para los problemas de seguridad de la memoria bajó a 500 dólares, con multiplicadores según la alcanzabilidad del fallo y su grado de explotabilidad. El medio relaciona estos ajustes con la forma en que la inteligencia artificial está cambiando el ritmo y el perfil del descubrimiento de vulnerabilidades.

Ahora la base sube a 2.000 dólares, cuatro veces más: lo confirman ambas fuentes. SecurityWeek precisa que, pese al aumento, las nuevas tarifas siguen muy por debajo de las vigentes antes de la revisión de abril; Help Net Security no menciona los recortes y presenta la noticia solo como una actualización del programa.

Las nuevas tarifas

Para la corrupción de memoria (datos coincidentes en ambas fuentes, salvo donde se indica):

• procesos del navegador, de red y de GPU: hasta 20.000 dólares. Solo Help Net Security detalla la escala: hasta 4.000 dólares por lecturas y bloqueos, hasta 10.000 por escrituras, use-after-free y lecturas controladas, hasta 20.000 por escrituras controladas demostradas desde contenido web;
• proceso renderer, el que procesa las páginas: hasta 8.000 dólares por escrituras en memoria y use-after-free;
• sandbox de V8: tarifa fija de 5.000 dólares;
• errores lógicos de V8: 4.000 dólares.

Fuera de la seguridad de la memoria:

• 2.000 dólares fijos por las vulnerabilidades de gravedad media, si el informe incluye una corrección o lleva directamente a identificarla;
• hasta 20.000 dólares por las fugas de la sandbox que no aprovechan bugs de memoria (las de alto impacto, según Help Net Security).

Vuelve además el bono de 2.000 dólares para los fuzzers, destinado a quien desarrolle y aporte fuzzers nuevos. Según Help Net Security, las instrucciones de envío se publicarán en las FAQ del Chrome VRP junto con el equipo Chrome Fuzzing, y Google prevé premios discrecionales de fin de año (más hallazgos, mejor informe, mejor bug).

Las reglas se aplican de inmediato: los informes enviados después del 30 de abril de 2026 y aún en evaluación se pagarán con las nuevas tarifas, como indican ambas fuentes.

Por qué importan el proceso y la sandbox

La escala de recompensas sigue la arquitectura de Chrome. El renderer ejecuta el contenido web en un proceso aislado y con pocos privilegios: un bug de memoria ahí es grave, pero por sí solo queda confinado. Los procesos del navegador, de red y de GPU trabajan con más privilegios, así que un fallo explotable desde una página web está más cerca de comprometer el sistema. La sandbox de V8 es una barrera adicional dentro del renderer, pensada para contener los efectos de los bugs del motor JavaScript.

Las fuentes no describen ataques en curso. Sin embargo, en las cadenas reales estas clases de fallos son las que sirven para comprometer un equipo durante la navegación (MITRE ATT&CK T1189, Drive-by Compromise) y para ejecutar código en el cliente (T1203): pagar más a quien los encuentra, y a quien aporta también la corrección, busca que se cierren antes.

Impacto para las empresas europeas e italianas

Si gestionas puestos de trabajo, nada cambia de inmediato: no hay parches nuevos. Lo que cuenta es la dirección: Google premia más los bugs que eluden el aislamiento y los informes que llegan con la corrección, es decir, lo que acorta el tiempo entre el descubrimiento y la actualización. El navegador sigue siendo uno de los programas más expuestos de la empresa, y su ciclo de actualización debe gestionarse como el del sistema operativo.

Para las entidades sujetas a NIS2, la gestión de vulnerabilidades y actualizaciones forma parte de las medidas de gestión de riesgos; los fabricantes de software sujetos al Cyber Resilience Act deberán además contar con una política de divulgación coordinada de vulnerabilidades. Las decisiones de Google son una referencia útil también si gestionas tu propio canal de notificación.

Qué hacer ya

1. Mantén activa la actualización automática de Chrome y de los demás navegadores basados en Chromium, y comprueba con las políticas de gestión que ningún equipo la haya desactivado.
2. Verifica en el inventario la versión instalada y los equipos con el reinicio del navegador pendiente: la actualización solo se aplica al volver a abrirlo.
3. No desactives la sandbox (por ejemplo con la opción --no-sandbox en quioscos, automatizaciones o aplicaciones integradas): es la barrera que encarece las cadenas de ataque.
4. Si gestionas un programa de notificación, premia los informes con pruebas reproducibles y una corrección propuesta, como hace ahora Google, y mide el tiempo que lleva verificarlos.

Cómo ayuda ARXDOME

ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, con su antigüedad y con las ya explotadas por los atacantes destacadas: te ayuda a encontrar los equipos con un navegador desactualizado. ARX Sentry recoge el inventario de ordenadores y servidores, para que sepas qué versiones están realmente instaladas.

Última actualización: 14 de octubre de 2026