El Grupo de Inteligencia de Amenazas de Google (GTIG) afirma que, por primera vez, ha visto a un actor de amenazas usar un exploit zero-day que cree construido con la ayuda de un modelo de IA. El exploit era un script de Python que eludía la autenticación de dos factores en una herramienta de administración de código abierto. Google retuvo tanto al actor como al producto para proteger la corrección.
El titular se escribe solo, pero apunta en la dirección equivocada. El verdadero cambio no es un phishing más inteligente ni unos cebos mejor redactados. Es la compresión del ciclo de los exploits: la IA está reduciendo el tiempo y la habilidad necesarios para encontrar una vulnerabilidad y convertirla en un exploit funcional. Para algo tan grande y tan expuesto como un navegador web, eso cambia las cuentas.
Lo que Google realmente encontró
El informe de GTIG, publicado el 2026-05-11, es cuidadoso con lo que afirma. No dice que la IA escribió el exploit. Dice que Google tiene un alto nivel de confianza, basándose en la estructura del código, de que el actor usó un modelo de IA para ayudar a descubrir y armar el fallo. Las señales estaban en el código fuente: docstrings de manual, una disposición de estilo Python extrañamente parecida a un tutorial y una puntuación CVSS alucinada que ningún investigador humano inventaría. Google también señala que su propio modelo, Gemini, probablemente no fue el que se usó.
El mismo informe describe otros tres patrones que conviene separar del bombo publicitario:
- Generación de exploits asistida por IA, donde los modelos aceleran la investigación y el armado en lugar de reemplazar al atacante.
- Malware más autónomo, todavía experimental, donde una carga útil consulta a un modelo en tiempo de ejecución para leer el estado del sistema y elegir su siguiente acción en vez de seguir una lógica programada de forma fija. Google señala familias en fase de investigación como PROMPTSPY y PROMPTFLUX.
- Abuso industrializado del acceso a modelos premium, donde los delincuentes usan middleware y procesos de registro automatizados para sortear los límites de uso.
Nada de esto es "la IA reemplaza a los hackers". Es "la IA hace más rápidas las partes lentas y costosas". Esa es la parte en torno a la cual los defensores deberían planificar.
El verdadero cambio es la compresión del ciclo de los exploits
Encontrar una vulnerabilidad grave y escribir un exploit fiable siempre ha sido la parte costosa de un ataque. Requiere una habilidad poco común, tiempo y paciencia. El texto del phishing nunca fue el cuello de botella.
La compresión ataca ese cuello de botella. Cuando un modelo ayuda a un actor de nivel medio a leer código fuente desconocido, detectar una ruta de código débil y montar una prueba de concepto funcional, la distancia entre "existe un fallo" y "se está explotando un fallo a gran escala" se acorta. El caso de Google es un solo punto de datos. La tendencia es lo que importa: investigación más rápida, armado más rápido, mayor ritmo operativo.
Eso importa sobre todo para el software que es enorme, cambia rápido y está en todas partes. El navegador es el ejemplo más claro.
Por qué el navegador es el objetivo más grande
Los navegadores son sistemas vastos y de múltiples componentes
Un navegador moderno no es un solo programa. Chromium, el motor detrás de Chrome, Edge, Brave, Opera y muchos otros, alcanza decenas de millones de líneas de código e incorpora más de 200 librerías de terceros. Muchas de ellas son de código abierto y las mantienen equipos separados:
- V8 ejecuta JavaScript y WebAssembly.
- Blink renderiza la página.
- Skia dibuja gráficos 2D.
- ANGLE traduce las llamadas gráficas para la GPU.
- libwebp decodifica imágenes WebP.
- WebRTC gestiona el audio y el vídeo en tiempo real.
Cada uno de ellos es una superficie de ataque. Un solo fallo de memoria en cualquiera de ellos puede convertirse en ejecución remota de código. El código abierto es una fortaleza para la revisión y la velocidad, pero también significa que el código exacto que estudia un atacante es el mismo código que se distribuye a miles de millones de dispositivos.
Las nuevas funciones se publican constantemente, y los nuevos zero-days las siguen
Chrome publica un nuevo hito aproximadamente cada cuatro semanas, y la plataforma web sigue creciendo: nuevas APIs, nuevos códecs, nuevas rutas de GPU. Más funciones significan más código, y más código significa más fallos. El resultado es constante, no ocasional. Google parcheó alrededor de nueve zero-days de Chrome explotados activamente en 2024 y alrededor de ocho en 2025, y se agrupan en los mismos componentes complejos:
- Confusión de tipos en V8: CVE-2025-10585 y CVE-2025-13223.
- Validación de ANGLE y GPU: CVE-2025-6558.
- Skia y V8 de nuevo en 2026: CVE-2026-3909 y CVE-2026-3910, ambos explotados en la práctica.
Los zero-days en el navegador no son eventos raros para los que prepararse. Son una condición recurrente que hay que tener en cuenta en el diseño.
Un componente de código abierto, un radio de impacto entre ecosistemas
La advertencia más clara vino de libwebp. CVE-2023-4863 era un desbordamiento de búfer en el heap de esa única librería de decodificación de imágenes, explotable con un solo archivo WebP manipulado. Primero se puntuó como 8.8 al ser un fallo de Chrome, y luego se reclasificó a 10.0 una vez que se comprendió su alcance, porque libwebp está en todas partes. (Un segundo identificador, CVE-2023-5129, se incorporó después como duplicado.)
El mismo fallo afectó a Chrome, Firefox, Signal, 1Password, Telegram y, de forma crítica, a casi todas las aplicaciones construidas sobre Electron. Una librería, un fallo, y el radio de impacto cubrió una gran porción del software que la gente usa a diario.
Los zero-days no se detienen en la pestaña del navegador
Aquí es donde la compresión se vuelve peligrosa. El sandbox del navegador existe por una razón: una pestaña se supone que es un entorno hostil, aislado del resto de tu máquina. Pero el mismo motor que impulsa tu navegador también se distribuye dentro de aplicaciones de escritorio.
Electron incluye su propia copia de Chromium para que los desarrolladores web puedan crear apps con apariencia nativa. VS Code, Slack, Discord y la app de escritorio Claude de Anthropic son todas aplicaciones de Electron. Cada una lleva su propia compilación de Chromium, y esas compilaciones van por detrás de la versión original. Cuando Google parchea un zero-day de V8, cada app de Electron sigue siendo vulnerable hasta que incorpora la corrección y publica una actualización, lo que puede llevar semanas.
Ahora combina dos hechos. Primero, estas apps heredan los zero-days del navegador. Segundo, se ejecutan fuera del sandbox del navegador, a menudo con acceso completo al sistema de archivos y, en el caso de los agentes de IA para programación, con la capacidad de ejecutar comandos de shell. Un fallo del motor del navegador que sería un problema contenido y aislado en una pestaña se vuelve mucho más grave dentro de una app local que puede leer tus archivos y ejecutar código. El caso de libwebp ya demostró que las apps de Electron heredan estos fallos. A medida que se extienden las apps de escritorio de IA y los agentes para programación, la población de software con muchos privilegios y portador de Chromium en las máquinas de los desarrolladores sigue creciendo, y con ella el botín de un solo zero-day del motor del navegador.
Las dependencias envenenadas se ejecutan en el mismo navegador
La compresión tiene un segundo frente: la cadena de suministro. La misma IA que acelera la investigación de exploits acelera la búsqueda y el abuso de dependencias débiles, y el código de las dependencias se ejecuta en el lugar exacto que no puedes ver desde el servidor.
El ecosistema de npm lo hizo concreto en 2025. El 2025-09-08, unos atacantes hicieron phishing a un mantenedor y publicaron versiones maliciosas de paquetes enormemente populares, incluyendo chalk y debug. La carga útil inyectada era un crypto-clipper dirigido al navegador: enganchaba window.ethereum y las llamadas de red para intercambiar de forma silenciosa direcciones de monederos en el navegador de la víctima. Días después, el gusano autorreplicante "Shai-Hulud" comprometió cientos de paquetes y robó credenciales de desarrolladores mientras se propagaba.
Este es el patrón Magecart generalizado. El código malicioso de terceros no necesita un fallo de memoria. Solo necesita cargarse, y una vez que lo hace, se ejecuta en el mismo contexto que tu página, con acceso a los formularios, los tokens y todo lo que escribe el usuario.
Por qué el escaneo previo al lanzamiento no es suficiente
La mayoría de los presupuestos de seguridad siguen estando antes del despliegue: análisis estático, escaneo de dependencias, una puerta de revisión y luego publicar. Esos controles son necesarios, pero comparten un mismo punto ciego. Inspeccionan una instantánea de código que ya conoces, en un momento anterior a su ejecución.
Los zero-days son, por definición, los fallos que nadie ha catalogado todavía. Las dependencias comprometidas a menudo cambian después de pasar la revisión, intercambiando código limpio por código malicioso en una carga posterior. Los scripts de terceros se actualizan a sí mismos en producción sin preguntar. Y la compresión del ciclo de los exploits acorta la ventana entre que un fallo se hace conocido y que un fallo se utiliza. Escanear una instantánea previa al lanzamiento no puede detectar una carga útil que solo aparece en tiempo de ejecución, en el navegador, después de que tu canalización haya terminado.
Esa brecha no es un fallo de las herramientas. Es un fallo de visibilidad. No puedes escanear hasta el punto de ver lo que se ejecuta en la sesión del navegador de otra persona.
Qué hacer esta semana
- Inventaría cada script de terceros en tu sitio, incluidos los que cargan otros scripts.
- Monitoriza el comportamiento de los scripts en tiempo de ejecución, no solo en el despliegue: qué se carga, qué cambió, qué lee cada script y a dónde envía los datos.
- Ajusta la cadencia de parcheo de los navegadores y de las apps de Electron que usa tu equipo. Trata un zero-day de Chromium como una fecha límite para VS Code, Slack y herramientas similares, no solo para el navegador.
- Aplica una Content Security Policy que limite desde dónde pueden cargarse los scripts y a dónde pueden enviarse los datos.
- Alerta sobre las anomalías: un script conocido que de repente contacta con un nuevo dominio, lee campos de pago o cambia su carga útil.
Cómo encaja cside
cside vigila la capa que el resto de tu stack no puede: la sesión del navegador en vivo. Te da visibilidad en tiempo de ejecución de cada script que se ejecuta en tu sitio, qué carga, cómo cambió desde la última versión, qué datos toca y a dónde van esos datos.
Eso importa en un mundo de ciclos de exploits comprimidos porque no depende de conocer el exploit por adelantado. Cuando un script de confianza empieza a comportarse de forma distinta, cuando una dependencia introduce código nuevo tras el despliegue, o cuando una carga útil empieza a exfiltrar datos de formularios, el cambio es visible en tiempo de ejecución incluso si la vulnerabilidad subyacente es completamente nueva. El escaneo previo al lanzamiento te informa sobre el código que publicaste. cside te dice qué se está ejecutando realmente ahora mismo.
Empieza con seguridad del lado del cliente para una monitorización completa de scripts en tiempo de ejecución, o con Privacy Watch para ver exactamente qué recopilan y envían los scripts de terceros.
Más lecturas sobre cside
- Compromiso de la cadena de suministro del Web SDK de AppsFlyer
- Los mayores ataques Magecart de la historia (hasta ahora)
- Ataque a la cadena de suministro web a través de jQuery troyanizado
- Cómo los scripts de terceros comprometidos pueden inyectar prompts a los agentes de IA
- Buenas prácticas para asegurar los scripts de terceros
A fecha de 2026-06-03. Los recuentos de zero-days de Chrome y los hallazgos del GTIG reflejan la información disponible en esa fecha.
Sobre el autor
Simon Wijckmans es el fundador y CEO de cside. Escribe sobre seguridad del lado del cliente, amenazas en la capa del navegador, scripts de terceros y el trabajo de estandarización necesario para hacer la web más segura.
