Por qué los zero-day del navegador no van a desaparecer, y qué hace Bromure al respecto
Apple y Google gastan hoy decenas de millones de dólares al año en encontrar y corregir fallos de navegador. Aun así, cada año hay entre ocho y diez zero-day de navegador explotados activamente. Este artículo expone por qué esa cuenta no va a cambiar, cómo Claude Mythos y la «Vulnpocalypse» están a punto de empeorarla, y por qué un navegador diseñado para asumir que será vulnerado es un producto de naturaleza distinta.
No puedes gastar para salir de un problema con treinta y cinco millones de líneas de código. El navegador no es seguro porque haya sido escrito con esmero; es el mayor analizador de contenido no confiable que se ejecuta en tu computadora. Diseñar asumiendo eso es lo único que escala.
Un navegador, en reposo, parece un milagro de ingeniería bien financiado. Google y Apple emplean cada uno a cientos de personas cuyo trabajo a tiempo completo es hacer que Chrome y Safari sean menos explotables. Ambas compañías publican parches en pipelines de integración continua que se miden en minutos. Ambas operan programas de bug bounty con pagos de seis y siete cifras. Ambas publican post-mortems. Ambas cuentan con infraestructura de fuzzing de primer nivel. Y, sin embargo, con una regularidad perfecta, cada año, los usuarios del software de consumo más parcheado, más endurecido y más auditado del planeta descubren que una página que abrieron hace tres días se había apoderado silenciosamente de su máquina.
Este artículo explica por qué. También explica por qué esa cuenta está a punto de empeorar mucho, y cuál creemos realmente que es la única salida.
El dinero de las recompensas es real. Los bugs también.
Apple y Google pagan hoy cifras récord por fallos de navegador.
El Programa de Recompensas por Vulnerabilidades (VRP) de Google pagó en 2024 $12 millones en todos sus productos, de los cuales Chrome se llevó $3,4 millones repartidos entre 137 investigadores. 2025 pulverizó esa cifra: el VRP pagó $17,1 millones a 747 investigadores — un salto interanual del 45% y el mayor año de recompensas en la historia de Google. Un solo escape del sandbox de Chrome (un bug en Mojo) pagó $250.000 a un único investigador.
Apple está en la misma liga. La página de recompensas de seguridad de la compañía lista ahora un pago máximo de $2 millones para sus cadenas de mayor severidad (frente a $1 millón anteriores), con multiplicadores adicionales que pueden llegar a $5 millones; los pagos acumulados desde que el programa se abrió al público han superado los $35 millones.
Son números grandes. Son los números correctos; ambas compañías han sido transparentes al respecto. Pero hay algo incómodo en gastar $17 millones en encontrar bugs: lo que realmente estás haciendo es comprar evidencia de que hay más bugs.
Los recibos, año por año.
En este gráfico están pasando varias cosas a la vez, y cada una es peor que la anterior.
La línea de 2023 a 2025 parece progreso. Menos CVE de Chrome al mes, año tras año, durante el mismo periodo en que el gasto de Google en bounty aumentó en un 50%. Los zero-day en circulación, la única categoría que realmente le importa a un usuario, se mantuvieron aproximadamente estables en unos ocho al año solo para Chrome — más algunos cada año para Safari y WebKit, incluidos CVE-2023-42916 / 42917 (ambos marcados como «explotados activamente» por Apple a finales de 2023), CVE-2024-23222 (el primer zero-day de Apple de 2024), y CVE-2025-24201 (explotado en «ataques extremadamente sofisticados»).
La interpretación era tentadora: esto funcionaba, solo que despacio.
Y entonces llegó 2026. Los primeros tres meses de este año ya han producido unos 200 CVE de Chrome — un ritmo que, si se mantiene, superará con creces cualquier año registrado anteriormente. El número de zero-day en circulación ya va por cuatro, con más de ocho meses por delante. Algo cambió.
Eso que cambió tiene nombre.
El 7 de abril de 2026, Anthropic anunció una vista previa de un modelo de frontera, designado internamente como «Copybara» y comercializado como Claude Mythos, optimizado para una sola tarea: encontrar y explotar vulnerabilidades de seguridad de forma autónoma. El informe público de red team describe un modelo que:
- Generó un exploit zero-day funcional el 72,4% de las veces en benchmarks internos, frente a menos del 1% de la generación anterior Opus 4.6.
- Encadenó cuatro vulnerabilidades separadas en un único JIT heap spray que se escapó tanto del motor de renderizado como del sandbox del sistema operativo en un navegador importante.
- Encontró «miles» de zero-day de severidad alta y crítica en todos los sistemas operativos principales y todos los navegadores web principales, en el transcurso de una evaluación.
Anthropic, para su crédito, no va a liberar Mythos al público. En su lugar, la capacidad se está distribuyendo a través de un programa controlado llamado Project Glasswing, que incluye a Apple, Google, Microsoft, AWS, Cisco, CrowdStrike, NVIDIA, Palo Alto Networks, JPMorgan Chase, Broadcom y la Linux Foundation. Esas organizaciones tienen ahora una conexión directa a un modelo que encuentra zero-day a un ritmo que no se mide en meses sino en horas.
Esa es, en términos relativos, la buena noticia. La mala es que Mythos es un anuncio, no una invención. Si un laboratorio de frontera ha alcanzado esta capacidad dentro de un piloto restringido, alguien más —un gobierno no amistoso, un proveedor comercial de spyware, un grupo criminal bien financiado— tendrá algo equivalente en unos pocos trimestres. Ese es el fenómeno más amplio al que la cobertura temprana ya ha empezado a llamar la Vulnpocalypse.
La Vulnpocalypse no es retórica. Es un cambio medible en la ventana.
El término se ha usado, de forma más visible, en el reportaje del 9 de abril de NBC News sobre Mythos y en el artículo «Mythos and the Vulnpocalypse» de la Cloud Security Alliance. No es un ejercicio de branding. Describe un cambio concreto y cuantificable: el tiempo medio entre la divulgación pública de una vulnerabilidad y su explotación activa ha caído de aproximadamente 2,3 años en 2019 a menos de 24 horas en 2026. Cuando a AISLE, una empresa de investigación de vulnerabilidades con IA, se le entregó el aviso de OpenSSL de enero de 2026 el mismo día de su publicación, de forma independiente redescubrió las doce zero-day parcheadas en cuestión de horas.
Esto no es hipotético. La NVD, la base de datos de vulnerabilidades canónica del gobierno de EE. UU., lleva más de un año admitiendo en silencio que no da abasto: a principios de 2026, el atraso de CVE sin enriquecer con pruebas de concepto de exploit funcionales es la historia dominante de sus operaciones. Los envíos de nuevos CVE han subido más del 260% desde 2020 mientras la plantilla de analistas se mantiene plana, y el discurso público del NIST ha pasado de «nos pondremos al día» a «priorizaremos los de mayor riesgo».
Si estás esperando a que el fabricante parchee, a que el parche se distribuya, a que tu dispositivo reciba la actualización y a que reinicies el navegador — ese es un plan de seguridad que, en 2026, tiene una ventana de 24 horas para completarse. La media.
Por qué este problema es arquitectónico, no presupuestario.
La razón por la que Google y Apple no pueden arreglar esto con más dinero es sencilla, y vale la pena decirla con claridad: el navegador es el mayor analizador de contenido no confiable que se ejecuta en tu computadora, y no existe tal cosa como un analizador seguro para tanta cantidad de datos controlados por el atacante.
Chromium son aproximadamente 35 millones de líneas de C++, más un
enorme directorio //third_party que agrupa
más de 200 librerías externas —
el decodificador de WebP (CVE-2023-4863,
famosamente encadenado al Pegasus de NSO en el incidente BLASTPASS), el
decodificador VP8/VP9, libxml2, ICU, Skia, ANGLE, Dawn, BoringSSL. Cada
una de esas librerías es un analizador que procesa entrada controlada
por quien posea la página que abriste. Cualquier bug en cualquiera de
ellas es un bug en el navegador.
Safari y WebKit son más pequeños — el núcleo ronda los 2,5 millones de líneas de C++, según la auditoría de Igalia — pero la forma de la superficie de ataque es idéntica: una pila monumental de analizadores en C y C++, manejando entrada adversarial, con cada byte decodificado ejecutándose dentro del mismo espacio de direcciones que tu perfil de navegador.
No se puede escribir tanto C++ que procesa tanta entrada no confiable sin que haya bugs. No puedes comprar la salida de los bugs cuando el lado atacante del mercado tiene ahora acceso a un fuzzer que genera exploits en horas. El ritmo al que el defensor puede encontrar y publicar correcciones y el ritmo al que el atacante puede encontrar y armar nuevos bugs están, a fecha de abril de 2026, divergiendo matemáticamente.
Qué hicieron realmente los zero-day recientes.
Antes del anuncio de Mythos, los zero-day de navegador más importantes de los últimos tres años ya eran motivo de preocupación. Una lista breve:
BLASTPASS / libwebp, 2023
CVE-2023-4863 fue un desbordamiento de heap en el decodificador de imágenes WebP usado tanto por Chrome como por Safari. El exploit, desplegado por el spyware Pegasus del Grupo NSO, no requería interacción alguna: bastaba con visitar la imagen equivocada. Sigue siendo una de las demostraciones más claras en el mundo real de cómo un analizador de un tercero puede comprometer todo el navegador.
Operation ForumTroll, 2025
CVE-2025-2783, descubierto por Kaspersky GReAT, fue un escape del sandbox de Mojo en Chrome. Se encadenó con un compromiso del motor de renderizado para entregar el spyware comercial de Memento Labs a objetivos rusos y bielorrusos. Google lo arregló pocos días después de su divulgación. Los atacantes llevaban al menos meses usándolo.
Explotación de V8 por Corea del Norte, 2024
CVE-2024-7971 fue una confusión de tipos en V8 utilizada por actores alineados con Corea del Norte para desplegar un kit de robo de criptomonedas. Ese mismo año hubo varios bugs adicionales en V8 vinculados a proveedores comerciales de spyware. El punto en común: cada uno de ellos solo necesitaba una página web.
Safari, finales de 2025
CVE-2025-24201 fue explotado en lo que Apple describió como «ataques extremadamente sofisticados» dirigidos a individuos concretos. Un par adicional en diciembre (CVE-2025-43529, CVE-2025-14174) explotó WebKit y ANGLE y se marcaron como activamente explotados en ataques dirigidos. WebKit comparte una genealogía de código con ANGLE de Chromium; a veces un bug en uno se parchea en ambos.
Estos bugs no se encontraron porque los ingenieros fueran descuidados. Se encontraron porque a los adversarios modernos les pagan por encontrarlos, y porque siempre hay más. Lo que hace Mythos es cambiar la proporción entre «investigadores que pueden encontrar un bug» y «personas que pueden permitirse un investigador que encuentre un bug». Anthropic ha restringido su herramienta por ahora. Habrá otras.
El argumento arquitectónico.
Todo lo anterior debería apuntar a una conclusión: el supuesto de diseño correcto es que el navegador tiene un zero-day dentro ahora mismo, del que no tienes conocimiento, que se usará contra alguien este año, y que podría usarse contra ti.
Dado ese supuesto, la única pregunta que importa es: ¿qué pasa después de que se dispare el bug?
En un navegador tradicional, la respuesta es brutal. El navegador se ejecuta dentro de tu cuenta de usuario. Su motor de renderizado tiene acceso a tus archivos, tu llavero, tus cookies, tu cámara, tu micrófono y tu red local — porque esas son cosas a las que la cuenta de usuario tiene acceso, y el navegador es un programa que se ejecuta como ese usuario. Un compromiso del renderizador que burle el sandbox del navegador — exactamente lo que demostró Mythos en un navegador importante durante su evaluación — es un compromiso de tu computadora. Punto.
Ese es el resultado que el resto de la industria acepta implícitamente y planifica en silencio — con capas de EDR, detección de endpoints, MDM, telemetría, respuesta a incidentes y, para los más desafortunados, abogados especializados en negociar con operadores de ransomware.
Bromure hace algo distinto.
Bromure no intenta correr más que Mythos. Esa carrera no se puede ganar. Lo que hace Bromure es cambiar hasta dónde llega realmente un zero-day.
En Bromure, el navegador se ejecuta dentro de una VM invitada sellada. Cuando se dispara un compromiso del motor de renderizado — el mismo escape del sandbox de Mojo que corrió en Operation ForumTroll, la misma confusión de tipos en V8 encadenada que Mythos generó en pruebas internas — el atacante tiene ahora ejecución de código dentro de una máquina virtual Linux desechable. Esa VM no contiene tus archivos. No contiene tu llavero. No contiene tu cámara ni tu micrófono ni tu red local. Contiene un navegador, un perfil y el estado que ese perfil haya acumulado.
Cuando la sesión termina y cierras la ventana, la VM se destruye. El exploit se destruye con ella. La persistencia —el movimiento más valioso que hace un atacante tras el acceso inicial— no puede establecerse en algo que está a punto de dejar de existir.
Lo que no estamos afirmando.
La arquitectura de Bromure no es una bala de plata. Dos límites que vale la pena enunciar:
El exploit sigue comprometiendo la sesión del navegador
Las contraseñas tecleadas en esa sesión, las cookies guardadas en ese perfil, los datos introducidos en formularios durante la ventana de exploit — todo eso vive dentro de la VM y es alcanzable por un compromiso de esa VM. El aislamiento mantiene el daño acotado a la sesión; no protege retroactivamente las entradas ya entregadas a la sesión. La separación por perfil y las sesiones desechables reducen el valor de ese radio de impacto; no lo vuelven cero.
Una fuga de VM sigue estando sobre la mesa
Una cadena lo suficientemente severa podría, en principio, escapar de la propia VM. Ese es un problema mucho más difícil que escapar del sandbox de un navegador — varios órdenes de magnitud menos bugs, y la superficie de ataque del hipervisor es más estrecha que la de un navegador por diseño — pero no es cero. Bromure reduce la probabilidad de que un zero-day de navegador se traduzca en un compromiso del host; no la elimina.
El número útil no es «riesgo cero». El número útil es «cuántos zero-day al año terminan realmente comprometiendo tu computadora». Con un navegador tradicional, ese número ha ido subiendo y está a punto de subir más rápido. Con Bromure, está limitado por una clase distinta de bug que cuesta unas cien veces más encontrar.
Planifica para el mundo en el que vas a vivir.
Los zero-day de navegador no son un error del ecosistema. Son una característica estructural de ejecutar decenas de millones de líneas de C++ en el camino de bytes adversariales, para lo cual no existe una solución de ingeniería creíble, y cuyo disuasivo económico (eres demasiado caro de atacar) está a punto de quedar automatizado. Apple y Google no están relajándose. El problema es genuinamente más difícil que sus presupuestos.
Lo que sí podemos hacer, y lo que hace Bromure, es mover el radio de impacto. Aislar el navegador. Hacer que cada sesión sea desechable. Poner el sistema operativo anfitrión un muro más allá de cada página. Esa es una forma de producto distinta, y es la única que hemos encontrado que sigue teniendo sentido cuando el adversario es una fábrica de exploits con IA siempre activa y una factura de API de tres cifras.
Instala Bromure. Conviértelo en tu navegador por defecto para cualquier cosa en la que no confíes plenamente. Y cuando el próximo titular diga «Zero-day activamente explotado en Chrome parcheado en una versión de emergencia» — y lo dirá, en cuestión de semanas —, sigue leyendo, porque el desenlace no tiene por qué ser el tuyo.