La vulnerabilidad de Claude for Chrome: clics simulados y permisos sin confirmación que exponen Gmail, Docs y Calendario

Autor: Publicada 5 min de lectura 229 lecturas

Las imágenes de este artículo han sido generadas con inteligencia artificial. Cómo publicamos

Un nuevo repaso a la extensión "Claude for Chrome" vuelve a poner en evidencia una frontera rota entre el navegador y los modelos: no se trata de un fallo en la IA, sino de confianza mal delimitada entre extensiones. La vulnerabilidad descrita permite que otra extensión que ya pueda ejecutar scripts en claude.ai simule un clic en la interfaz de la extensión oficial y desencadene tareas preaprobadas —como leer tu Gmail, abrir tu último Google Doc con sus comentarios o acceder a tu Calendario— sin que la página verifique que el clic viniera de un usuario real.

En términos técnicos, el problema central es doble. Primero, el handler que responde al botón de onboarding no comprueba event.isTrusted, el indicador del navegador que distingue un clic humano de uno sintético generado por script; eso hace que cualquier extensión con acceso al DOM de claude.ai pueda construir el elemento, fijar el ID de tarea permitido y disparar el evento. Segundo, existe un parámetro de URL (skipPermissions=true) que inicializa el panel lateral en modo "actúa sin preguntar", de modo que, si el panel se abre con ese flag, la extensión opera sin pedir la aprobación del usuario. En conjunto, la combinación puede transformar una acción forjada en una ejecución totalmente silenciosa si el usuario había activado previamente el modo sin confirmación.

La vulnerabilidad de Claude for Chrome: clics simulados y permisos sin confirmación que exponen Gmail, Docs y Calendario
Imagen generada con IA.

Anthropic tomó medidas tras el hallazgo original que limitaron a nueve los IDs de tarea que la página puede pedir a la extensión, una mejora frente a la capacidad de inyectar prompts arbitrarios. Sin embargo, la mitigación no arregla la raíz: rechazar que scripts de terceros simulen la intención del usuario y dejar de depender de parámetros de URL para el estado de permisos son correcciones necesarias que todavía no se habían desplegado en el paquete inspeccionado. La falta de verificación de event.isTrusted y la lectura de skipPermissions desde la URL dejan la puerta abierta a lo que en seguridad se conoce como un problema de "confused deputy" e indirect prompt injection en el contexto de aplicaciones LLM, dos vectores que aparecen ya en marcos como el OWASP Top 10 for LLM Apps.

Las implicaciones prácticas son claras: si usas la extensión con tus cuentas Google ya autenticadas y además tienes instalada cualquier otra extensión con acceso a claude.ai, un atacante puede forzar a Claude para Chrome a cargar una de las tareas permitidas. En el modo por defecto aparecerá un cuadro de aprobación que el usuario debe pulsar, pero en modo "Act without asking" la misma secuencia se ejecuta sin interacción humana. Esto expone correo, documentos y calendario a exfiltración o a acciones automatizadas no deseadas y convierte en crítico el control de permisos entre extensiones.

Para usuarios y administradores, hay medidas inmediatas y prácticas que reducen el riesgo hoy mismo. Desactiva el modo "Act without asking" y vuelve al modo que siempre solicita confirmación; eso restaura la ventana de control humano. Revisa todas las extensiones que tienen permiso para "leer y cambiar datos" en claude.ai y elimina o restringe las que no necesites. Considera usar un perfil de navegador separado o un navegador dedicado para agente/IA si necesitas la extensión de Claude; así limitas el alcance de cada extensión al mínimo necesario. Si eres administrador de organización, aplica políticas de instalación de extensiones y revisa permisos con herramientas de gestión de endpoints.

La vulnerabilidad de Claude for Chrome: clics simulados y permisos sin confirmación que exponen Gmail, Docs y Calendario
Imagen generada con IA.

En el plano medio y largo plazo, conviene que Anthropic y desarrolladores de extensiones adopten dos cambios sencillos y efectivos: rechazar eventos con event.isTrusted === false en los manejadores de UI y no depender del estado de permisos pasado por parámetros de URL, decidiendo el modo de permisos basándose en estados internos o en llamadas seguras que no puedan forjarse desde contextos de menor privilegio. Estas correcciones enlazan con buenas prácticas de diseño seguro para interfaces que actúan con permisos elevados y reducirían el riesgo de que futuras vulnerabilidades (XSS, regresiones en handlers de mensajes, o repositorios hostiles) permitan escalar a ejecución silenciosa.

Si quieres seguir el caso con fuentes técnicas y marcos de referencia, revisa la guía del OWASP para riesgos en apps que usan LLM y la página oficial de Claude para entender el producto y su despliegue: OWASP Top 10 for LLM Apps y Claude — Anthropic. Mantén también un ojo en el listado de la Chrome Web Store si usas la extensión en navegador: búsqueda de "Claude" en Chrome Web Store.

Finalmente, exige transparencia a los proveedores: pide un aviso público y un CVE cuando se reportan estos fallos, verifica que la versión que instalas incluye el arreglo y sus pruebas, y mantente alerta a comunicados oficiales. La lección central es que dar "agencia" a un asistente web dentro del navegador implica riesgos que no se corrigen solo limitando prompts; hacen falta controles sólidos en la capa de interacción humana y en la gestión de permisos entre extensiones. Hasta entonces, la precaución y la segmentación de entornos son tu mejor defensa.

Cobertura

Relacionadas

Mas noticias del mismo tema.