Volver a todas las publicaciones
Publicado el · por Renaud Deraison

Suponer que el renderer cae — qué significan los 271 bugs de Mozilla encontrados por IA para la seguridad del navegador

Una versión temprana de Claude Mythos ayudó a Mozilla a encontrar 271 bugs de seguridad en una sola versión de Firefox. La reacción correcta no es el pánico, ni la celebración, sino una recalibración serena de lo que aún debemos suponer sobre cada navegador que publicamos, usamos o sobre el que construimos.

Un auditor más inteligente encuentra más bugs. Eso no cambia el hecho de que el renderer es un parser de 35 millones de líneas expuesto a bytes adversarios. La reacción correcta ante Mythos no es alivio ni espanto: es seguir diseñando como si el próximo bug fuera el que se nos cuela.

El 21 de abril, Mozilla publicó un artículo titulado «The zero-days are numbered» («Los zero-days tienen los días contados»). En él, la fundación confirmó que Firefox 150 se envió con 271 correcciones de seguridad descubiertas durante la evaluación de una versión temprana del Claude Mythos de Anthropic, un modelo de frontera ajustado para investigación de vulnerabilidades y distribuido a través de un programa de socios controlado llamado Project Glasswing. Una versión anterior de Firefox, la 148, ya había incluido 22 bugs encontrados por Claude Opus 4.6. El salto de 22 a 271 en un solo ciclo de versión es exactamente el tipo de cifra que hace que la gente eche mano de los superlativos.

Mozilla, para su crédito, no lo hizo. El CTO Bobby Holley le dijo a The Register que los hallazgos le produjeron «vértigo» a su equipo y plantearon la pregunta de si «siquiera es posible mantener el ritmo». Pero lo combinó con una frase mesurada, fácil de pasar por alto y muy importante: «alentadoramente, tampoco hemos visto bugs que no pudieran haber sido encontrados por un investigador humano de élite».

Esa frase es toda la historia, y toda la tesis de este artículo.

Lo que el anuncio dice realmente

Si quitamos los titulares, Mozilla está informando de tres cosas.

Primero, una máquina puede hacer ahora, a cadencia industrial, lo que un pequeño número de humanos de élite ya podía hacer a cadencia humana. El blog lo plantea directamente: «ninguna categoría ni complejidad de vulnerabilidad que los humanos puedan encontrar queda fuera del alcance de este modelo». Es una afirmación de capacidad. No es una revolución sobre lo que se puede encontrar; es una revolución sobre la velocidad a la que lo encontrable se encuentra.

Segundo, existe una posibilidad real de que la complejidad de los bugs supere a la capacidad de descubrimiento a medida que las herramientas de IA se expanden también por la cadena de desarrollo. La formulación de Mozilla: «existe el riesgo de que las bases de código empiecen a superar la comprensión humana como resultado de más IA en el proceso de desarrollo». La comprensibilidad humana, sostiene el artículo, es en sí misma una propiedad de seguridad.

Tercero —la que todo el mundo va a proyectar—, Mozilla es optimista. «Luz al final del túnel», dijo Holley. «Los defensores por fin tienen una oportunidad de ganar, de forma decisiva».

Creemos que la primera afirmación es cierta, que la segunda merece más atención de la que recibirá, y que la tercera acierta sobre la carrera armamentística del auditoría y se equivoca sobre lo que esa carrera realmente arregla.

Correcciones de seguridad por versión de Firefox, atribuidas a auditoría asistida por máquinafuente: blog de mozilla.org, 2026-04-21300200100022Firefox 148Claude Opus 4.6271Firefox 150Claude Mythos PreviewEl planteamiento de Mozilla: los bugs estaban al alcance de revisores humanos de élite. El modelo los encontró más rápido.
Las dos últimas versiones de Firefox, con y sin auditoría asistida por máquina. Los 22 bugs de Firefox 148 se atribuyeron a un modelo Claude anterior; los 271 bugs de Firefox 150 salieron de una evaluación de un Mythos temprano. Mozilla enfatiza que ninguno de los 271 era un bug que un investigador humano de élite no hubiera podido encontrar: solo que se encontraron más rápido.

La buena noticia, dicha sin rodeos

Sería deshonesto enterrar la buena noticia, así que ahí va: una herramienta que convierte la capacidad de investigación de vulnerabilidades de élite en algo que escala con horas-GPU es una de las cosas más útiles que le han pasado a la seguridad del navegador en una década. Un salto de 22 a 271, en exactamente un ciclo de versión, contra una base de código de unos pocos millones de líneas de C++, es el tipo de señal que otros fabricantes de navegadores tomarán en serio. Los ingenieros de Chromium lo harán. Los de WebKit lo harán. Los equipos que mantienen libxml2 e ICU y HarfBuzz y libwebp y los otros cien parsers que cada navegador arrastra lo harán, si consiguen tiempo para ello.

Más bugs corregidos antes del lanzamiento es sencillamente mejor que menos bugs corregidos antes del lanzamiento. Los 271 fueron hallazgos internos, no revelados a nadie antes de que saliera el parche, sin evidencia de que ninguno hubiera sido explotado en entornos reales. En la vieja frase de la investigación en seguridad, eran bugs muertos caminando. Mozilla los mató antes de que tuvieran la oportunidad de costarle algo a nadie.

Así que: progreso real. Crédito real a Mozilla por revelarlo abiertamente en lugar de enterrar en silencio el volumen. Crédito real a Anthropic por mantener Mythos tras un programa de socios en vez de hacerlo generalmente disponible a cualquiera que pueda pagar una suscripción.

Y luego la pregunta más difícil

Si el efecto de primer orden es «se corrigen muchos más bugs antes de publicar», el efecto de segundo orden es «la misma capacidad está ahora disponible para cualquier otro al que Anthropic decida dar acceso, y una capacidad aproximadamente equivalente estará disponible para cualquiera en cuestión de trimestres». Ese segundo efecto es el que el artículo anterior, Por qué los zero-day del navegador no van a desaparecer, intentó exponer en detalle. No vamos a volver a litigarlo aquí. Lo relevante hoy de aquel argumento es esto: un navegador es la mayor pieza individual de maquinaria de parsing de contenido no confiable que corre en tu computadora, y la economía de encontrar bugs en ese tipo de maquinaria se está desplazando bajo los pies de todo el mundo al mismo tiempo.

Mozilla tiene razón en que un defensor bien dotado tiene ahora mejores herramientas. También las tiene un atacante bien dotado. La pregunta es qué le hace eso a las cifras que realmente le importan al usuario: no bugs corregidos por versión, sino bugs que terminan siendo un exploit funcional en la bandeja de entrada de alguien.

Lo que cambia el tooling clase MythosBugs encontrados por versiónde techo humano de élite a techo de horas-GPUTiempo hasta el exploitmás rápido a ambos lados de la divulgaciónCosto de una campaña de caza de bugsde nómina a factura de APIQuién puede permitirse mirarcada proyecto de código abierto, cada adversarioLo que no cambiaEl navegador sigue siendo ~35M de líneas de C++más cientos de parsers empaquetadosEl renderer corre en tu cuenta de usuariocon acceso a archivos, llavero, redUna sola página carga bytes adversariosen docenas de parsers de tercerosUna sola cadena funcional bastapara apoderarse del host donde corre el navegador
Lo que cambia un auditor a velocidad de máquina y lo que no. La auditoría se acelera en ambos lados de la línea. La forma de la superficie de ataque del navegador y las consecuencias de que una sola compromisión tenga éxito no se mueven.

La columna de la izquierda es donde vive Mythos. La auditoría —en ambos lados— se acelera. Esa aceleración es asimétricamente útil para los defensores cuando son ellos los que pueden correr la herramienta primero, que es lo que hizo Mozilla, lo que presumiblemente hace Chromium y lo que los cientos de navegadores más pequeños y las apps basadas en navegador mayormente no hacen. Las aceleraciones de la columna derecha no existen. Ninguna cantidad de auditoría convierte un renderer monolítico in-process en uno no monolítico. Ninguna cantidad de auditoría separa el renderer del llavero, del sistema de archivos, de la webcam, de la pila de red. La forma del problema no ha cambiado.

La postura que sigue teniendo sentido

Mozilla cierra su artículo con una esperanza razonable: que podamos preservar la comprensibilidad humana como propiedad de seguridad de primer nivel del navegador, mientras seguimos usando ayuda de máquina para encontrar bugs. Es una esperanza que compartimos. No es la esperanza sobre la que está construido este blog.

La postura en torno a la que se construyó Bromure no predice cuántos bugs hay en el renderer. Predice que siempre hay al menos un bug en el renderer que nadie ha encontrado aún —a veces los defensores llegan primero, a veces los atacantes— y que la arquitectura alrededor del renderer tiene que hacer esa incertidumbre sobrevivible.

Eso no es un argumento de fabricante de navegador. Es una elección de modelo de amenazas. Un renderer que haya auditado Mythos sigue siendo un renderer ejecutando C++ frente a entrada adversaria. El próximo artículo sobre cadenas de herramientas memory-safe, la próxima generación de fuzzers, el próximo Mythos, no van a cambiar lo que pasa en una computadora cuando un renderer es comprometido hoy, en la versión de Chrome, Safari o Firefox que ya está instalada en los portátiles de la gente.

Defensa por auditoríaGANAR LA CARRERA AL BUGEl auditor encuentra el bug primeroEl fabricante publica un parcheTu dispositivo recibe la actualizaciónSi el atacante llegó primerola compromisión del renderer se dispara, alcanza la cuenta de usuario,archivos y llavero quedan al alcance,se establece persistencia.Defensa por aislamientoSUPONER QUE EL BUG ATERRIZAExiste un bug en el renderer (conocido o no)El exploit se dispara dentro de una VM desechableLa pestaña se cierra, la VM se destruyeLo que alcanzó el exploitun invitado Linux con un perfil de navegador y nada más:sin archivos del host, sin llavero, sin webcam,sin persistencia cuando se cierra la pestaña.
Dos defensas frente a un bug en el renderer del navegador. Una depende de que el auditor llegue al bug primero. La otra depende de la arquitectura que rodea al bug, sin importar quién lo encontró.

Ambos diagramas son defensas reales. El de la izquierda es en el que toda la industria del navegador ha estado invirtiendo durante veinte años, y que ahora acelera con Mythos. Está mejorando genuinamente. También es —estructuralmente— una defensa que depende de que el fabricante termine la carrera antes que el atacante. Cuando esa carrera se comprime de meses a horas, como viene ocurriendo, la defensa se estrecha a la pregunta de si tu dispositivo logró actualizarse dentro de esa ventana. Esa ventana se encoge para ambos lados al mismo tiempo.

El de la derecha es arquitectónico. No le importa si el bug lo encontró Mozilla, Anthropic, el mismo grupo de atacantes que llevó a cabo Operación ForumTroll en 2025, o nadie aún. Plantea una pregunta distinta: cuando un bug del renderer se dispara, ¿qué significa «se dispara» en términos de lo que el atacante toca realmente?

Lo que hace Bromure, dicho en un respiro

Cada pestaña corre dentro de una máquina virtual Linux desechable sobre Apple Silicon. El renderer —V8, Blink, el decodificador WebP, Dawn, cada uno de los parsers en los que un auditor clase Mythos está encontrando bugs— corre dentro de ese invitado, nunca sobre el host. Cuando se dispara una compromisión del renderer, el atacante está dentro del invitado. El invitado no contiene tu carpeta Documentos, tu llavero, tu iCloud Drive, tu red local, tu cámara ni tu micrófono. Contiene un navegador, un perfil y el estado que ese perfil ha acumulado. Cuando se cierra la ventana, el invitado se destruye. Cada sesión de navegación que comienza, comienza limpia.

Eso no es una afirmación de que los bugs del renderer no importen. Importan. Las contraseñas tecleadas en una pestaña comprometida siguen tecleándose en esa pestaña. Las cookies que posee un perfil comprometido siguen siendo alcanzables por una compromisión de ese perfil. Las entradas entregadas a la sesión durante la ventana de explotación están al alcance. Lo que no está al alcance, porque no está en la misma VM, es el resto de la computadora —y el resto de la computadora es donde viven la persistencia, el movimiento lateral y la mayor parte del daño real.

Dos cosas que este artículo no está diciendo

Hay dos errores que sería fácil cometer leyendo lo anterior. Queremos atajar los dos.

No: «nuestro renderer es mejor»

Bromure usa Chromium upstream. Los parsers que Mythos auditó en Firefox tienen análogos en cada navegador basado en Chromium, Bromure incluido. No estamos afirmando que nuestro renderer tenga menos bugs que ningún otro. Estamos afirmando que nuestra postura no depende de que nuestro renderer tenga menos bugs.

No: «la auditoría por IA es mala, en realidad»

El tooling clase Mythos es un claro beneficio neto para los defensores: si cada navegador y cada parser de terceros empaquetado se audita a esta cadencia, el mundo se vuelve más seguro. Nuestro punto es más estrecho: ese tipo de progreso eleva el techo de la calidad del renderer; no cambia la pregunta de diseño sobre qué hacer cuando el renderer igualmente es explotado. A esa pregunta es a la que Bromure fue construido para responder.

Qué vigilar a continuación

La lectura honesta del anuncio de Mozilla es que esto es la apertura de una conversación larga. Hay al menos tres cosas que importarán en los próximos trimestres.

Primera, si Chromium y WebKit confirman volúmenes de descubrimiento similares cuando se publiquen sus propias auditorías asistidas por Mythos. Las cifras de Firefox son llamativas; el panorama de toda la industria sigue borroso. Segunda, si la misma herramienta empieza a aparecer en manos de atacantes tras la divulgación. Mozilla es cuidadosa en no afirmar que los 271 bugs fueran zero-days explotables; eran correcciones. La pregunta es qué aspecto tiene la misma clase de herramienta apuntada a Chrome la mañana siguiente al próximo lanzamiento Stable, en manos de alguien que no está parcheando.

Tercera, y esta es la propia preocupación de Mozilla, si la interacción entre el desarrollo asistido por IA y la auditoría asistida por IA produce un aumento neto de la comprensibilidad o una disminución neta. Una base de código que solo un modelo puede auditar es una base de código cuya seguridad depende del acceso continuado a los modelos. Ese es un modo de fallo distinto al que hemos vivido durante veinte años, y no obviamente mejor.

Por nuestra parte, seguiremos escribiendo sobre esto a medida que se desarrolle. Y seguiremos haciendo la misma apuesta de diseño: que una VM desechable por pestaña convierte el peor desenlace de un bug de navegador en una sesión que hay que reiniciar, no en una computadora que hay que reconstruir. Esa apuesta no empeora cuando los renderers mejoran. Se vuelve, en el sentido más estrecho y útil, ligeramente redundante —un problema que estaríamos encantados de tener.

Instala Bromure. Sigue actualizando tu otro navegador también. Y cuando el próximo titular diga «auditoría asistida por IA encuentra cientos de vulnerabilidades en [producto]» —y lo dirá, muchas veces, este año— léelo por lo que es: evidencia de que el techo está subiendo, no evidencia de que el suelo haya cambiado.