La gravedad de una vulnerabilidad no determina por sí sola el pago de una recompensa. La gravedad mide el impacto técnico en unas condiciones concretas. La urgencia de la corrección añade datos como la explotación activa y la exposición del activo. La recompensa también depende de lo que entregó el investigador, las reglas publicadas por el programa, la calidad del informe, las bonificaciones y una decisión humana. Esta diferencia explica una línea desconcertante del aviso de Chrome que Google publicó en septiembre de 2026. CVE-2026-85046 era un fallo de gravedad alta en V8. Google señaló que había un exploit observado en ataques reales. La recompensa publicada fue de 1 000 USD. La cifra solo parece absurda si supones que «gravedad alta», «explotación activa» y «recompensa» son tres formas de poner precio a lo mismo. No lo son. Para el equipo de seguridad de una startup, este caso ofrece un modelo útil para separar cuatro decisiones: gravedad técnica, urgencia de corrección, material de explotación entregado y deliberación sobre el pago. ## ¿Por qué publicó Google una recompensa de solo 1 000 USD por un fallo de Chrome explotado? Al grano: el registro público no revela el cálculo de Google. Muestra una vulnerabilidad, una prioridad de corrección y una recompensa final. Estos datos pertenecen a sistemas distintos. La [actualización del canal estable del 3 de septiembre](https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html) de Google incluyó CVE-2026-85046 como una «confusión de tipos en V8» de gravedad alta. Atribuyó el hallazgo al investigador Salvatore Gulizia, también conocido como Serotav, indicó que lo comunicó el 4 de agosto y publicó una recompensa de 1 000 USD. Google también señaló que tenía constancia de que el CVE ya se estaba explotando en ataques reales. Las versiones corregidas fueron 152.0.7977.82 o .83 para Windows y Mac, y 152.0.7977.82 para Linux. La actualización contenía 12 correcciones de seguridad. Google advirtió de que el acceso a los detalles del fallo podría seguir restringido hasta que la mayoría de los usuarios hubiera actualizado. | Dato público | Qué responde | Qué no responde | |---|---|---| | Gravedad alta | Cómo clasificó Google el impacto técnico | Cuánto debería pagarse por el informe | | CVSS 8.8 | Las condiciones técnicas del vector de puntuación de CISA | Si la explotación está extendida | | Exploit observado en ataques reales | Si los equipos defensivos deben tratar la corrección como urgente | Qué exploit entregó el investigador | | Recompensa de 1 000 USD | La recompensa que Google decidió publicar | El cálculo privado o la compensación total | Nada de esa tabla es contradictorio. El error consiste en intentar deducir la última fila a partir de las tres primeras. Por eso una matriz de recompensas necesita intervalos, no una lista de precios. Si tu tabla dice «gravedad alta equivale a 1 000 USD», oculta las preguntas relevantes dentro de ese nivel de severidad. ¿Entregó el investigador un fallo que provocaba un cierre inesperado, una prueba de concepto fiable, una capacidad de explotación reutilizable, una mitigación o una cadena completa? ¿Era el informe claro y original? El nivel de severidad puede acotar la discusión, pero no sustituirla. Nuestra guía sobre [niveles de recompensas por vulnerabilidades](/blog/bug-bounty-reward-tiers-researchers-trust-hackerone-cuts) explica cómo publicar esa base sin convertirla en una fórmula rígida. ## ¿CVE-2026-85046 permite escapar del sandbox de Chrome? No, al menos según las pruebas públicas. El CVE oficial señala que un documento HTML manipulado podía ejecutar código arbitrario **dentro del sandbox**. Es una vulnerabilidad grave de ejecución de código en el motor JavaScript V8 de Chrome, pero no equivale a escapar del sandbox y tomar el control del sistema operativo. Chrome aísla el contenido web en un proceso de renderizado restringido. Si un atacante logra ejecutar código en él, el sandbox debe impedir que ese código acceda libremente al sistema anfitrión. Una cadena completa para comprometer el navegador suele necesitar otra vulnerabilidad que cruce esa frontera. Project Zero de Google ha documentado esta diferencia en su trabajo sobre [cómo escapar del sandbox de Chrome](https://googleprojectzero.blogspot.com/2020/02/). El [análisis técnico](https://serotav.github.io/Writeups/v8/when-sorting-leads-to-confusion/) del propio Gulizia deja esta frontera especialmente clara. Describe una confusión de tipos que permitía leer y escribir de forma arbitraria en el heap de JavaScript. Después explica que encadenó «este fallo» con un **escape de sandbox n-day** para conseguir una flag en el v8CTF de Google. Es decir, este CVE aportó una parte de la cadena. Otro exploit ya conocido permitió escapar del sandbox. Esta diferencia importa por dos motivos. Primero, delimita la afirmación técnica. Llamar «escape de sandbox» a este CVE atribuiría al primer fallo la capacidad del segundo exploit. «RCE de sandbox» también es una abreviatura arriesgada, porque muchos lectores entenderán «ejecución de código que escapó del sandbox». La formulación precisa es **ejecución de código arbitrario dentro del renderizador V8 aislado por el sandbox de Chrome**. Segundo, delimita el debate sobre la recompensa. Un fallo de V8 que aporta una capacidad útil y una cadena funcional capaz de comprometer el navegador de extremo a extremo no son la misma entrega. Un programa puede definir de forma legítima categorías y bonificaciones distintas para cada una. No puedes deducir cuál recibió Google a partir de un análisis externo publicado más tarde. El título enviado a Hacker News también afirmó que el fallo afectaba a «todas las versiones de Chromium». El historial del código fuente demuestra lo contrario. La optimización de `Array.prototype.sort` implicada [se incorporó a V8 el 27 de abril de 2026](https://chromium.googlesource.com/v8/v8/+/66a3f1e94d4b681bff6476a876067a3c79a853f0). La [correspondencia de versiones](https://v8.dev/docs/version-numbers) de V8 sitúa la versión 14.9 en Chrome M149. El registro CVE marca el límite superior, las versiones anteriores a 152.0.7977.82, pero no el inferior. El historial del repositorio aporta el punto de partida que falta. CISA señala que el problema podría afectar a varios navegadores que utilizan Chromium, entre ellos Chrome, Edge y Opera. Es un aviso para consultar el boletín de cada proveedor, no una prueba de que todas las versiones históricas y todas las variantes de Chromium fueran vulnerables. ## ¿Por qué CVSS y el catálogo KEV de CISA responden a preguntas distintas? CVSS describe características técnicas. El catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA indica a los equipos defensivos que la explotación ha pasado de ser posible a observarse en la práctica. Necesitas ambas señales, pero no debes fusionarlas en una única puntuación ni en una regla de pago. El [registro CVE oficial](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/85xxx/CVE-2026-85046.json) indica que un documento HTML manipulado podía provocar la ejecución de código arbitrario dentro del sandbox. Clasifica el problema como CWE-843, acceso a un recurso mediante un tipo incompatible. La puntuación 8.8 que muestra [NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-85046) es una evaluación secundaria de CISA ADP, no una puntuación independiente de NVD. Su vector es `AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H`. En lenguaje llano: - Puede explotarse a través de la red. - La complejidad del ataque es baja. - No requiere privilegios previos. - Exige interacción del usuario, por ejemplo, que este acceda a contenido web manipulado. - El alcance no cambia, en consonancia con una ejecución dentro del sandbox. - El impacto sobre la confidencialidad, la integridad y la disponibilidad se considera Alto dentro de ese alcance. CVSS no pregunta si esta semana circula un exploit. En ese punto entra KEV. CISA [añadió CVE-2026-85046 a su catálogo KEV](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) el 4 de septiembre y fijó el 18 de septiembre como fecha límite de corrección para los organismos federales afectados. Las empresas privadas no están sujetas a ese plazo federal, pero la señal operativa sigue siendo valiosa: el equipo debe dejar de debatir si la explotación es meramente teórica y poner la actualización al principio de la cola. De ahí sale una regla clara para las startups: **CVSS ayuda a describir el impacto; KEV ayuda a ordenar el trabajo.** Ninguno de los dos calcula una recompensa. Si tu programa quiere pagar una bonificación por un informe que llegue con pruebas de explotación activa, incluye esa regla en la política. No la improvises después de que aparezca un titular. ## ¿Qué se recompensó exactamente con los 1 000 USD de Chrome? La única respuesta defendible es esta: el aviso de Chrome divulgó esa recompensa por el informe de Gulizia sobre el CVE. Los datos públicos no identifican la categoría exacta del programa de recompensas por vulnerabilidades (VRP), el cálculo ni el contenido del informe confidencial. Las [reglas actuales del programa de recompensas por vulnerabilidades de Chrome](https://bughunters.google.com/about/rules/chrome-friends/chrome-vulnerability-reward-program-rules) explican por qué no es seguro reconstruir el importe. Las recompensas son discrecionales. Google indica que tiene en cuenta factores como la reproducción, la posibilidad de explotación, la calidad del informe, las mitigaciones propuestas y la originalidad. El baremo contiene una base para fallos de seguridad de memoria, varios multiplicadores relacionados con V8 y bonificaciones condicionales mucho mayores para las cadenas de exploits que cumplen los requisitos. Esas cifras publicadas describen un marco, no una factura. No sabemos qué fila aplicó Google, si hubo algún ajuste ni qué pruebas incluía el informe original. Tampoco sabemos si el exploit observado en ataques reales se parecía al trabajo del investigador. El v8CTF añade otro motivo de confusión. Sus [reglas oficiales](https://github.com/google/security-research/blob/master/v8ctf/rules.md) describen una recompensa de 10 000 USD para la primera flag válida que cumpla los requisitos en una versión designada. Gulizia afirma que consiguió una flag al encadenar este fallo con un escape n-day. No hemos encontrado ninguna fuente primaria pública que confirme que Google validara o pagara esa flag. Sumar 10 000 USD a 1 000 USD convertiría una posible recompensa independiente en un total falso. Mantén separadas tres clases de entrega: 1. **Informe de vulnerabilidad:** una descripción clara y original que permite al proveedor reproducir y corregir un fallo de seguridad. 2. **Capacidad de explotación:** una primitiva fiable, como el acceso controlado a memoria, que permite avanzar hacia una explotación mayor. 3. **Cadena completa:** los componentes necesarios para cruzar las fronteras de seguridad pertinentes y alcanzar un resultado de extremo a extremo. Los programas suelen valorarlas de forma distinta porque requieren trabajos diferentes y demuestran impactos diferentes. El importe final también puede reflejar la calidad del informe, la novedad, las mitigaciones, si el informe estaba duplicado, el alcance y las bonificaciones específicas de la política. Por eso la gravedad no puede ser el precio por sí sola. ## ¿Cómo debería decidir una startup el importe de una recompensa? Utiliza un flujo de cuatro registros. Cada registro tiene un responsable, unos criterios de prueba y un resultado distintos. El objetivo no es añadir burocracia, sino evitar que una sola etiqueta cargada de emoción lo decida todo. ### 1. Evalúa la gravedad técnica Reproduce el problema y documenta la frontera que se ha cruzado. Incluye los privilegios necesarios, la interacción, el activo afectado y el impacto sobre la confidencialidad, la integridad y la disponibilidad. Anota también la frontera que **no** se ha cruzado. En este caso, «dentro del sandbox» es tan importante como «ejecución de código arbitrario». No dejes que una puntuación CVSS hable por sí sola. Guarda el vector y su justificación para que otro revisor pueda comprobar cómo se obtuvo la puntuación. ### 2. Fija la urgencia de la corrección Combina la gravedad con la exposición actual y los datos sobre amenazas. Los activos expuestos a Internet, la disponibilidad de código de explotación, la explotación activa y la inclusión en KEV pueden hacer que un informe pase por delante de otro técnicamente similar. Esta es una decisión de respuesta. Puede cambiar deprisa a medida que cambia la información disponible. La urgencia no debe reescribir en silencio lo que entregó el investigador. Si la explotación aparece después del informe, acelera la corrección y documenta la nueva señal. Aplica una bonificación solo si la política publicada la contempla o si una persona autoriza expresamente una excepción discrecional. ### 3. Clasifica el material de explotación entregado Registra lo que aportó realmente el investigador, no lo que tu equipo construyó después. Una taxonomía concisa ayuda: | Entrega | Datos que debes registrar | |---|---| | Reproducción | Pasos, versión afectada, comportamiento esperado y observado | | Prueba de concepto | Fiabilidad, restricciones, fallos y efectos controlados | | Capacidad de explotación | Capacidad obtenida y frontera de seguridad que sigue intacta | | Cadena completa | Cada componente, frontera cruzada y resultado de extremo a extremo | | Contribución a la mitigación | Idea para el parche, análisis de evasiones o solución provisional verificada | Este registro evita que se atribuya al investigador trabajo que el equipo añadió después. También te ofrece una razón defendible para situar dos vulnerabilidades con la misma gravedad en puntos distintos del intervalo de recompensa. ### 4. Delibera y aprueba el pago Parte del intervalo publicado para el nivel de severidad y compara después la entrega, la calidad, la originalidad y las bonificaciones documentadas. Presenta una cifra y su justificación. Permite que los revisores discrepen proponiendo un importe alternativo, no solo con un voto negativo. Por último, exige que una persona identificada y con autoridad apruebe la recompensa. El registro de la decisión debe responder a cinco preguntas: - ¿Qué política y nivel de severidad se aplicaron? - ¿Qué entregó el investigador? - ¿Qué factores desplazaron la propuesta dentro del intervalo? - ¿Qué alternativas valoraron los revisores? - ¿Quién aprobó el importe final y cuándo? Si esto parece más reflexivo que escribir una cifra en un formulario de pago, esa es precisamente la idea. Una recompensa se convierte en una promesa externa cuando se aprueba. Hasta entonces, la discusión interna debe ser reversible. La guía de [recompensas y pagos](/docs/bounties-and-payouts) explica el momento en el que la deliberación se convierte en dinero. ## ¿Por qué la urgencia de la corrección y la equidad del pago necesitan registros distintos? Una vulnerabilidad explotada activamente debe avanzar deprisa por el proceso de corrección. Eso no significa que una señal de inteligencia sobre amenazas deba reescribir automáticamente la recompensa. La equidad depende de aplicar reglas conocidas a la contribución real del investigador y documentar con honestidad las excepciones. El caso de Chrome muestra los cuatro estados a la vez. La vulnerabilidad era técnicamente grave. La explotación activa hizo urgente la corrección. Los datos públicos describen una capacidad dentro del sandbox y un escape n-day independiente empleado en una cadena de investigación. Google publicó una recompensa de 1 000 USD sin explicar el cálculo. La conclusión correcta no es que Google valorara en 1 000 USD un ataque real capaz de comprometer el navegador. Los datos públicos no permiten reducir todos esos juicios a una sola cifra. Para los equipos que aún están definiendo la recepción de informes, el alcance, el puerto seguro (Safe Harbor) y las expectativas de respuesta, el punto de partida es un [programa de divulgación de vulnerabilidades](/blog/how-to-set-up-vulnerability-disclosure-program). Un proceso de recompensas no puede reparar un canal de entrada que pierde pruebas o mantiene a los investigadores en la incertidumbre. ## Cómo evita Kit que la gravedad se convierta en un precio automático Un buen proceso de pagos necesita un punto de partida acotado, una revisión independiente, una justificación documentada y una decisión humana. El flujo de trabajo de CSIRT de Kit permite aplicar esos controles sin fingir que puede descubrir el precio correcto. Kit guarda importes mínimos y máximos para cada nivel de severidad. La evaluación conserva una instantánea del intervalo sugerido, y el máximo de esa instantánea limita las propuestas, los importes alternativos y las recompensas. Si la instantánea no contiene un máximo, Kit utiliza como alternativa el máximo actual del nivel de severidad. Si el programa usa una matriz y aun así no puede determinar el techo, el proceso de pago se bloquea por seguridad. Ante una recompensa que no sea obvia, un miembro del equipo puede crear una propuesta de recompensa con una justificación cifrada en reposo. La votación es a ciegas de forma predeterminada, por lo que los revisores ordinarios no ven nombres, posturas ni importes alternativos antes de emitir su propio voto. Toda objeción debe incluir un importe alternativo positivo. El recuento informa a la persona autorizada para aprobar, pero es consultivo: no existe un cuórum automático, una regla de consenso ni un pago automático. Esto es deliberación, no cálculo. Kit actualmente **no** incorpora datos de CVE, NVD, CISA KEV ni EPSS. No calcula recompensas a partir de CVSS ni del estado de explotación. No dispone de un conjunto de datos externo para comparar recompensas, no distingue entre una capacidad de explotación y un escape de sandbox y no conserva una versión inmutable de la matriz de recompensas o la política vigente en el momento de presentar el informe. El intervalo queda registrado como una instantánea durante la evaluación, pero esta sucede después de presentar el informe. Estos límites importan. El software puede conservar los datos de entrada, reducir el sesgo de anclaje, hacer cumplir un techo y registrar la decisión. No puede convertir la gravedad en un precio objetivo. Si quieres un proceso más claro para las recompensas controvertidas, consulta cómo funcionan las [propuestas de recompensa y la votación del equipo](/docs/bounty-proposals) y decide después si esa disciplina encaja en tu programa. El estándar práctico es modesto: evalúa el fallo, prioriza la corrección, clasifica las pruebas entregadas y debate el importe antes de que se convierta en una promesa. Mantén separados esos cuatro registros y una cifra sorprendente tendrá una explicación en lugar de convertirse en un titular.

Haz que la decisión de pago sea revisable. Kit reúne en un mismo flujo de trabajo de CSIRT los intervalos por nivel de severidad, la justificación de la propuesta, los votos a ciegas, los importes alternativos y la aprobación humana.

Empieza tu prueba gratuita