BragJack: una extensión de navegador secuestra a los agentes de IA en cinco navegadores principales

El 16 de septiembre de 2026, Gal Weizman, investigador de seguridad de Forever Security, publicó BragJack: una prueba de concepto en la que una extensión de navegador corriente —sin ningún día cero, sin ningún modelo con jailbreak, sin ningún servidor de proveedor comprometido— tomó el control de los agentes de IA integrados en cinco productos basados en Chromium: Gemini Live en Google Chrome, Copilot en Microsoft Edge, Opera Neon, Perplexity Comet y Claude en Chrome. La extensión no solicitaba nada exótico. Usaba scripts de contenido y la API declarativeNetRequest de Chromium, los mismos dos permisos que están presentes en la mayoría de los bloqueadores de anuncios, para llegar al canal privado que el propio sitio web de cada proveedor utiliza para enviar instrucciones a su agente. Weizman informa de que Comet fue la vulneración más amplia, de que Google y Microsoft publicaron correcciones y asignaron CVE-2026-0628 y CVE-2026-55945, y de que no se han observado ataques en la naturaleza. Se cataloga como una vulnerabilidad, de gravedad alta, en el archivo de incidentes de IA, donde cada registro incluye sus fuentes, su grado de confianza y una marca de disputa.

La extensión no rompió el modelo. Rompió el canal.

Los cinco productos están construidos de la misma manera, según el documento técnico complementario que Forever Security publicó ese mismo día. Cada uno tiene un "cuerpo" dentro del navegador que puede abrir pestañas, leer archivos locales, tomar capturas de pantalla y hacer clic en las páginas, y un "cerebro" fuera del navegador que decide qué debe hacer el cuerpo: los servidores Gemini de Google para Chrome, la aplicación web perplexity.ai para Comet, copilot.microsoft.com para Edge y el backend de Anthropic para Claude en Chrome. El cuerpo está diseñado para aceptar instrucciones de exactamente un origen: el sitio web del propio proveedor. Ese único origen de confianza constituye todo el modelo de seguridad. También es lo único que una extensión de navegador tiene permitido tocar.

Chromium concede a cualquier extensión instalada dos capacidades que son casi universales. Un script de contenido le permite ejecutar JavaScript dentro de una página. La API declarativeNetRequest, o DNR, le permite reescribir el tráfico de red: eliminar un encabezado de respuesta, redirigir una solicitud de script a un servidor diferente. Los navegadores dedican un esfuerzo considerable a mantener esas dos capacidades alejadas de las superficies privilegiadas, y cuatro de los cinco fabricantes habían hecho parte de ese trabajo. Lo que Weizman encontró, en cada caso, fue una brecha en la parte que habían dejado abierta.

Llama a la técnica general DinNeR Serving: usar DNR para debilitar las cabeceras de seguridad de una página de confianza y luego usar DNR de nuevo para redirigir una de las solicitudes de script de esa página a un servidor controlado por el atacante. Ahora la página ejecuta código del atacante, pero sigue creyendo que es la página del proveedor, y el agente sigue creyendo que está recibiendo mensajes del proveedor. En Chrome, Weizman informa de que las extensiones fueron bloqueadas correctamente para que no pudieran adjuntar un script de contenido ni un depurador a la aplicación Gemini incrustada, y de que DNR era el único mecanismo al que Chromium no había extendido la misma protección dentro de un WebView. Eliminar la Content-Security-Policy y relajar la política de aislamiento de documentos bastó para sustituir un script servido desde gstatic.com por el suyo propio, y desde dentro de chrome://glic pudo entonces publicar directamente los propios tipos de mensaje del agente del navegador: crear una pestaña en una dirección file:///, leerla como texto, PDF o captura de pantalla, y obtener la dirección de correo electrónico y la foto del perfil con la sesión iniciada.

Qué hizo la misma extensión, navegador por navegador

La extensión no eran cinco herramientas. Era un único manifiesto que solicitaba declarativeNetRequest y acceso amplio a hosts, además de un archivo de reglas independiente para cada objetivo; solo las reglas cambiaban entre ataques. La propia tabla de Forever Security es el resumen más claro de lo que alcanzó cada cadena, y se reproduce a continuación. La fila que más importa es Agent hijack: en cuatro de las cinco, el resultado demostrado no fue robo de datos, sino el control de un agente que podía actuar en nombre del usuario dentro de sesiones autenticadas.

Esas cadenas por navegador son la parte de BragJack que ninguna otra parte ha verificado. BleepingComputer, Cyber Security News, la Cloud Security Alliance y el CERT nacional de Tailandia informaron sobre la divulgación, y todos describen la mecánica de la misma manera, pero todos ellos describen el informe de Forever Security en lugar de ponerlo a prueba. El aviso de ThaiCERT del 21 de septiembre de 2026 cita a BleepingComputer como su fuente. Lo que sigue es, por tanto, el relato de Weizman sobre su propia prueba de concepto, que es lo que es una divulgación, y no un resultado reproducido de forma independiente.

Perplexity Comet: un dominio de prueba sigue en la lista de confianza

Comet fue el peor de los cinco según la propia clasificación del investigador, y la razón es estructural y no un desliz de programación. Perplexity creó un navegador en el que el agente tiene los propios permisos del navegador, así que un agente secuestrado hereda todos ellos. Perplexity también había hecho el trabajo defensivo que los demás se habían saltado: las extensiones tienen totalmente bloqueado su funcionamiento en perplexity.ai, y por eso Weizman dice que los bloqueadores de anuncios no funcionan allí.

La brecha estaba en la lista de orígenes de los que la extensión del agente aceptaría comandos. Según el informe técnico, esa lista contenía diez entradas, no una: perplexity.ai y su variante www, además de hosts de testing, staging y preview tanto en perplexity.com como en perplexity.ai. Solo los hosts de producción se habían endurecido. testing.perplexity.com seguía aceptando scripts de contenido. El obstáculo restante era que cada uno de esos dominios respondía con una redirección 302 a perplexity.ai, por lo que el navegador nunca permanecía en la página de prueba el tiempo suficiente para que un script se adjuntara. Una regla DNR que elimine el encabezado Location elimina ese obstáculo, y el script de contenido puede entonces comunicarse con la extensión del agente directamente a través del canal de mensajería de runtime que esta expone.

Lo que el agente haría ante una solicitud, según Weizman, era enumerar el historial de navegación, abrir URL arbitrarias, incluidas rutas file:///, y tomar capturas de pantalla de las pestañas visibles, y luego, mediante un comando que inicia una ejecución del agente a partir de un prompt suministrado, hacer casi cualquier cosa que un usuario podría hacer. Su prompt de demostración pedía a Comet que visitara perplexity.ai, resumiera los últimos cinco correos y enviara el resumen a una segunda dirección. También informa que el acceso file:/// se había abordado en una divulgación anterior de Comet, pero que la corrección distinguía entre mayúsculas y minúsculas, por lo que FiLe:///etc/hosts seguía funcionando. Nada de eso aparece en ningún aviso de Perplexity; la compañía pagó una recompensa y, según Forever Security, remedió el comportamiento que se le mostró.

Microsoft Edge: una página de marketing, un clic sintético y una carrera

Edge fue el único objetivo que opuso resistencia, y es el más instructivo de los cinco. Microsoft había dividido su agente en un modo "Think" que acepta prompts y un modo "Do" que actúa sobre las páginas, y ambos deliberadamente no pueden ejecutarse a la vez —un mecanismo de seguridad real, y uno que impide el forzado de prompts por construcción. Microsoft también había reforzado la página de marketing en microsoft.com/edge que demuestra el agente, condicionando su función privilegiada de envío de prompts a tres condiciones separadas: una Content-Security-Policy que no podía simplemente eliminarse, porque el objeto privilegiado nunca se crea cuando falta el encabezado, un token nuevo de gesto del usuario, y una función que rellena el cuadro de prompt en lugar de enviarlo.

La versión de Weizman es que cada condición se superó con un truco distinto. En lugar de eliminar la CSP, amplió su directiva frame-ancestors para permitir la incrustación por cualquier sitio .com. Para el token de gesto, añadió el permiso debugger al manifiesto y despachó un clic sintético, que Chromium acepta como un gesto orgánico. Para la condición de carrera, desactivó el flag de herramientas del agente, llamó a la función de envío de prompt y luego volvió a activar el flag mientras el agente seguía decidiendo si se le permitía actuar. La configuración estaba desactivada en el momento en que se forzó el prompt y activada en el momento en que se ejecutó la comprobación de permisos. A eso asignó Microsoft CVE-2026-55945.

El dinero coincide con el trabajo: Forever Security registra $3,000 por el hallazgo de Edge Chromium y $2,000 por la condición de carrera, $5,000 en total — tercero de los cinco, por detrás de los $7,000 de cada uno de Google y Perplexity.

Opera Neon y Claude en Chrome: los dos fáciles

Opera Neon fue el que menos exigió de los cinco. Su agente recibe órdenes de opera.com y, a diferencia de Google y Perplexity, que bloquearon que las extensiones adjuntaran scripts de contenido al origen de confianza de su agente, Opera no había impedido que las extensiones adjuntaran un script de contenido a ese dominio, por lo que la extensión de Weizman podía inyectar un script allí y llamar directamente al canal de mensajes del agente con el prompt que quisiera. Eliminar la CSP hizo que el mismo ataque pudiera incrustarse en un marco invisible en cualquier página. Su informe añade un detalle que no aparece en la cobertura de nadie más: Opera le dijo que había encontrado el fallo de forma independiente casi al mismo tiempo, y que pagó la recompensa de $900 de todos modos. Esa es una afirmación del proveedor reportada por el investigador, no un hallazgo para el que ninguna de las partes haya publicado pruebas.

Claude in Chrome es el caso atípico, porque es una extensión y no un navegador, y Forever Security lo dice sin rodeos: que una extensión explote a otra es un riesgo menor que una extensión explote al navegador en el que se ejecuta. El mecanismo era una página de marketing en claude.ai que podía pasar prompts arbitrarios al panel lateral, combinada con un script de contenido que se activaba con los clics en un botón de onboarding y leía el prompt de un atributo data. Weizman estableció él mismo el id y el atributo del body de la página, envió un clic sintético mediante el permiso del depurador, y el panel lateral se abrió con su prompt dentro. Anthropic lo calificó como de gravedad media, pagó una recompensa y, según Forever Security, reconoció a la empresa como la primera en informar este hallazgo en particular. Las dos publicaciones de Forever Security discrepan ligeramente sobre el importe: $600 en la tabla principal, $500 en la publicación técnica complementaria.

Lo que realmente dicen los registros de los propios proveedores

Solo dos de los cinco generaron un registro público de vulnerabilidad, y ambos preceden en meses al análisis de BragJack. La nota de versión del canal estable de Google del 6 de enero de 2026 enumera «High CVE-2026-0628: Insufficient policy enforcement in WebView tag. Reported by Gal Weizman on 2025-11-23», e indica las versiones 143.0.7499.192/.193 para Windows y Mac, y 143.0.7499.192 para Linux. La entrada de la National Vulnerability Database, publicada el 7 de enero de 2026, describe la falla como la posibilidad de que un atacante «que convenció a un usuario de instalar una extensión maliciosa inyecte scripts o HTML en una página privilegiada mediante una extensión de Chrome manipulada», la clasifica como CWE-862, autorización faltante, y tiene una puntuación CVSS 3.1 de 8.8. Esa puntuación no es de Google: proviene del enriquecimiento del registro realizado por la CISA, como señaló The Hacker News, y la propia nota de Google califica el problema como High (alta).

El registro de Microsoft es todavía más acotado. CVE-2026-55945, publicada el 3 de julio de 2026, es una condición de carrera CWE-362 con una puntuación CVSS 3.1 de 4.2 y una severidad Moderada. La declaración de impacto de Microsoft es «Information Disclosure», y sus propias preguntas frecuentes indican que la información divulgada es el contenido de archivos. La compilación corregida es la 150.0.4078.48, publicada ese mismo día, y el estado de explotación del registro indica: «Divulgado públicamente: No; Explotado: No». Nada en ese documento describe que se lleve a un agente por sitios web arbitrarios, que es el impacto que reporta Weizman. Ambas afirmaciones pueden ser ciertas al mismo tiempo —la CVE cubre la condición de carrera, mientras que la capacidad de la página de marketing fue un segundo hallazgo pagado por separado—, pero ningún documento del proveedor publicado hasta la fecha describe la cadena de extremo a extremo.

«Zero clicks» significa después de instalar la extensión

La frase de la tabla de Forever Security es precisa y fácil de malinterpretar. BragJack no es un drive-by. BleepingComputer, Cloud Security Alliance y ThaiCERT coinciden en la misma condición previa: la extensión maliciosa ya tiene que estar instalada. Lo que muestra la investigación es que, una vez instalada, no hace falta ningún clic adicional: la extensión llega al agente en cualquier página en la que se encuentre el usuario, sin mostrar nada. En Comet y Opera Neon, eso no requería ninguna interacción; en Edge y Claude in Chrome, el clic que exigía el agente lo sintetizaba la extensión mediante el permiso de depuración, así que el usuario tampoco lo proporcionaba.

Esa distinción determina la exposición en el mundo real. El ataque requiere o bien un usuario que instale algo malicioso, o bien una extensión que ya goce de confianza en la tienda y que más tarde se vuelva maliciosa, y ninguno de los dos casos supone un obstáculo alto —por eso las recomendaciones de CSA se centran en el inventario de extensiones y en tratar los permisos declarativeNetRequest y debugger como privilegiados. También es la razón por la que nadie ha informado de un ataque: una prueba de concepto que requiere que se instale una extensión hostil es una demostración de una capacidad, no una campaña.

Forzado de prompts y el argumento de venta que lo acompaña

La terminología importa porque describe dónde se ubicaban las defensas. La inyección de prompt oculta instrucciones en contenido que un modelo ya está leyendo; el entrenamiento y los filtros del modelo son la barrera prevista. Lo que hizo Weizman fue escribir el prompt completo, elegir el momento en que llegaba y seguir enviando mensajes de seguimiento —desde un origen en el que el agente fue diseñado para confiar. El filtrado de seguridad a nivel de modelo nunca llega a ser relevante, porque nada en el intercambio parece un ataque. Forever Security llama a esto prompt forcing.

El corolario que extrae la empresa es que la detección en endpoints tampoco puede verlo, ya que no se ejecuta código malicioso: se le está indicando a software legítimo que haga algo que tiene permitido hacer. Esa afirmación viene acompañada de una presentación comercial —Forever Security vende un agente de endpoint nativo de IA, y ambos artículos cierran recomendándolo—. La observación de que un agente secuestrado no genera ninguna firma de malware no depende de comprar nada, pero es el argumento del investigador y no un resultado medido, y ninguna parte independiente ha probado si algún producto de endpoint de cualquier tipo detecta estas cadenas.

Qué está establecido y qué depende de un solo investigador

El archivo clasifica esta entrada como una vulnerabilidad, gravedad alta, región global, confianza B —documentada, pero procedente de una fuente única o secundaria—, no disputada y sin daños reales registrados. Esa calificación describe la evidencia más que la gravedad de los errores, y esa división se refleja con claridad en toda la historia.

Establecido, en el sentido de que lo dice un proveedor o un registro de primera parte:

• Google lanzó una corrección de Chrome el 6 de enero de 2026 en 143.0.7499.192 y .193, y atribuyó a Gal Weizman un informe fechado el 23 de noviembre de 2025. Esto está en la propia nota de versión de Google, no en el relato del investigador sobre ella.

• CVE-2026-0628 existe, está calificada como Alta por Google y con 8.8 por el enriquecimiento de CISA en el registro del NVD, y está clasificada como aplicación insuficiente de políticas en una etiqueta WebView.

• Microsoft publicó CVE-2026-55945 el 3 de julio de 2026 como una condición de carrera de gravedad Moderada 4.2 que provoca divulgación de información, corregida en Edge 150.0.4078.48, con explotación registrada como nula.

• Las evaluaciones SSVC de CISA en ambos registros del NVD indican "explotación: ninguna", y nadie —ni el proveedor, ni el investigador, ni el reportero— ha afirmado que haya habido un ataque en el mundo real. Eso es una ausencia de informes, que no es lo mismo que una prueba de ausencia, pero es el estado del registro seis semanas después de la publicación.

Apoyándose únicamente en la cuenta de Forever Security:

Cada cadena de explotación por navegador, incluidos los conjuntos de reglas DNR, la eliminación de la redirección de testing.perplexity.com, la secuencia de la página de marketing de Edge y el clic en el botón de onboarding de Claude. Los CVE describen dos mecanismos; no describen estas cadenas.

• La lista completa de impactos para Comet —historial de navegación, lecturas de archivos locales, datos de perfil, capturas de pantalla— y la afirmación específica de que a un agente de Comet secuestrado se le podría indicar en inglés sencillo que resumiera y reenviara correos electrónicos. BleepingComputer lo reporta como la demostración del investigador; ninguna declaración de Perplexity lo confirma ni lo desmiente.

• El acceso de Chrome a la cámara y al micrófono, que BleepingComputer describe como "potencialmente" accesible y que la tabla Forever enumera como logrado.

• El total de la recompensa. Forever Security afirma alrededor de $20,000 entre cinco proveedores; sus propias cifras por producto suman $20,500, un punto aritmético que The Hacker News también señaló. La cifra de Claude in Chrome difiere entre las dos publicaciones de la empresa. El "más de $20,000" de BleepingComputer es coherente con cualquiera de las dos lecturas.

• Que el prompt forcing sea una nueva clase de ataque y no un nombre para una familia de errores de autorización. Eso es una afirmación de encuadre, y la Cloud Security Alliance —que lo adoptó— describe el patrón subyacente como una brecha arquitectónica compartida entre proveedores, no como una nueva técnica con mecánicas propias.

Tres de los cinco proveedores nunca publicaron ningún registro de vulnerabilidad. CSA señala que Perplexity, Opera y Anthropic reconocieron y remediaron la prueba de concepto específica sin avisos comparables a los de Google y Microsoft, y Forever Security no da fechas de corrección para esos tres. No se ha publicado ninguna reproducción independiente de ninguna cadena de BragJack; tanto Cyber Security News como ThaiCERT repiten la divulgación, y ThaiCERT cita a BleepingComputer.

¿Qué cambió tras la revelación?

Para los usuarios de Chrome y Edge, la respuesta práctica es que no era necesario cambiar nada el 16 de septiembre: las correcciones se enviaron en enero y julio, y cualquiera que tuviera Chrome 143.0.7499.192 o posterior, o Edge 150.0.4078.48 o posterior, ya tenía el parche. Vale la pena detenerse en ese momento. Los errores se cerraron meses antes de que la técnica que los unía tuviera un nombre, lo cual es la forma habitual de la divulgación coordinada y también la razón por la que el titular suena peor que el estado de los parches.

En el caso de Comet, Opera Neon y Claude in Chrome, la situación está menos clara. Cada proveedor pagó una recompensa y, según Forever Security y CSA, solucionó el comportamiento demostrado. Ninguno publicó un aviso vinculado a una versión ni una fecha, así que no hay un número de compilación con el que un usuario pueda comprobarlo, solo la instrucción general de mantenerse actualizado. La orientación de CSA para las organizaciones es inventariar las extensiones con permisos de declarativeNetRequest o debugger, restringir los navegadores agénticos a perfiles sin sesiones autenticadas de correo electrónico, código o finanzas, y preguntar a los proveedores cómo separan la entrada de usuario sintética de la genuina. El consejo de BleepingComputer para las personas es más sencillo: mantener el navegador actualizado, eliminar las extensiones que no reconozcas y tratar «leer y cambiar todos tus datos en todos los sitios web» como la advertencia que es.

La cuestión no resuelta no es si se corrigieron cinco errores. Es si se corrigió el supuesto de diseño que había detrás de ellos. Cada uno de estos productos trató un origen web de primera parte como un lugar confiable para que un agente local privilegiado recibiera órdenes, en un navegador donde cualquier extensión instalada puede reescribir lo que dice ese origen. Forever Security sostiene que la solución es el monitoreo a nivel de endpoint; CSA aboga por la validación de origen, el mínimo privilegio, canales de comando aislados y una procedencia de entrada no falsificable. Ninguno de los cinco proveedores ha dicho públicamente, en ningún registro revisado para este artículo, que cambiara la arquitectura en lugar de la ruta específica que recorrió Weizman.

La fecha del registro es la fecha de la explicación, no la de los fallos — y esa brecha es la historia. Una sola extensión, dos permisos que los bloqueadores de anuncios han tenido durante años y cinco proveedores que cada uno creía que su propio sitio web era el único lugar donde un atacante no podía permanecer.