Claude web_fetch: la memoria del usuario podía ser exfiltrada letra por letra
Un investigador de seguridad encontró una forma de hacer que Claude exfiltrara datos personales acumulados en su memoria (nombre, empleador, respuestas a preguntas de seguridad) hacia un sitio externo controlado por el atacante. La vulnerabilidad explotaba web_fetch, la herramienta con la que Claude lee páginas web. Anthropic confirmó el problema y lo cerró eliminando la capacidad de seguir enlaces encontrados en páginas ya descargadas.
Por qué te importa. Claude memoriza lo que le cuentas. En sesiones largas se comparten datos confidenciales: información de trabajo, decisiones estratégicas, a veces detalles personales. La protección de web_fetch se consideraba sólida: el agente solo podía visitar URLs escritas por el usuario o devueltas por la búsqueda interna. El agujero estaba en una regla aparentemente inocua: la que permitía a Claude hacer clic en enlaces encontrados dentro de las páginas que ya había cargado. Un sitio construido deliberadamente podía usar esta puerta para hacerse entregar los datos un carácter por vez, ocultándolos en la ruta de la URL.
Si usas un asistente con memoria y acceso web en datos sensibles, este es el tipo de riesgo que debes tener claro. El parche llegó, pero el patrón es general: cada vez que un agente tiene memoria privada y herramientas para comunicarse hacia el exterior, la superficie de ataque crece.
Si quieres profundizar. La vulnerabilidad ya está cerrada. Lo que puedes hacer es reducir el riesgo cuando haces leer a la IA contenidos de terceros: la guía sobre cómo defenderse de la prompt injection es el punto de partida.
En detalle
«Trifecta letal» es el nombre que la comunidad de seguridad da a la configuración de riesgo más peligrosa para un asistente IA: acceso a datos privados, acceso a herramientas que leen contenidos externos, e instrucciones hostiles ocultas en esos contenidos. Claude chat tiene los tres ingredientes. La memoria de Claude, compuesta por un resumen diario de conversaciones y una herramienta de búsqueda en el historial completo, construye perfiles densos de los usuarios. Y web_fetch le da al agente la capacidad de cargar páginas web, donde instrucciones maliciosas pueden esconderse.
La protección de Anthropic era robusta en teoría. web_fetch podía visitar solo tres tipos de URLs: las escritas directamente por el usuario en el mensaje, las devueltas por la herramienta web_search, o las encontradas como hipervínculos dentro de una página ya cargada. La tercera regla parecía inocua: servía para permitir que Claude hiciera clic en los enlaces que encontraba navegando, como lo haría una persona.
Ayush Paul comprendió que la tercera regla era la puerta de entrada. Si el atacante controla el sitio web, también controla qué enlaces aparecen en la página. Construyó un sitio que funcionaba como un teclado: la página de inicio mostraba enlaces hacia /a, /b, /c y así sucesivamente. Cada página de letra vinculaba a subpáginas (/aa, /ab, /ac). El prompt de ataque, disfrazado de mensaje de Cloudflare pidiendo al modelo que se «autentique» especificando el nombre del usuario, invitaba a Claude a navegar el sitio letra por letra. Cada solicitud HTTP registrada en el servidor del atacante revelaba un carácter de los datos extraídos de la memoria.
El resultado: nombre completo, ciudad de residencia, nombre del empleador. Datos que Claude tenía en memoria porque el usuario los había compartido en conversaciones anteriores. El ataque era invisible para quien estaba chateando: ninguna indicación de que algo hubiera salido del sandbox.
El ataque también era selectivo: el sitio trampa mostraba el prompt malicioso solo a clientes con Claude-User en el user-agent, haciendo más difícil descubrirlo para investigadores o escáneres automáticos.
Anthropic cerró la vulnerabilidad eliminando la tercera regla. Ahora web_fetch ya no sigue enlaces encontrados en páginas descargadas: solo puede visitar URLs escritas por el usuario o devueltas por web_search. No pagó la recompensa por encontrar el bug, argumentando que había identificado el problema internamente antes de la divulgación.
El parche es específico para este vector, pero el patrón de riesgo es general. Cualquier herramienta que le dé a un modelo acceso a la red puede convertirse en un canal de exfiltración si el modelo puede ser instruido para codificar datos en los parámetros de las solicitudes. La memoria de los asistentes está convirtiéndose en el dato más sensible que muchos usuarios poseen: más denso que un gestor de contraseñas, porque incluye contexto y relaciones, no solo credenciales.