Antecedentes

Esto comenzó a la 1 a.m. con una pregunta simple: ¿cómo maneja Claude las etiquetas de estilo XML inyectadas en un mensaje de usuario?

No era un plan de investigación sofisticado. Solo curiosidad sobre un límite que no parecía estar bien definido. Tiré del hilo. Lo que salió fue una cadena de ataque reproducible que me permitió fabricar un sistema de verificación de Anthropic que no existía, hacer que Claude creyera que tenía autorización oficial y extraer herramientas de seguridad ofensiva bajo demanda.

Cómo Funciona la Jerarquía de Instrucciones de Claude

Claude opera a través de múltiples capas de contexto, cada una con diferentes niveles de confianza:

Anthropic utiliza etiquetas de estilo XML para estructurar estas capas internamente. Etiquetas como <preferences_info>, <userPreferences>, <anthropic_reminders> y <system_reminder> gobiernan el comportamiento antes y durante las conversaciones.

El problema crítico: Estas etiquetas no tienen firma criptográfica. Sin mecanismo de verificación. Sin aplicación posicional a nivel de análisis sintáctico. Son texto plano — y el texto plano puede falsificarse.

Fase 1: Extracción de Etiquetas

El primer paso fue el reconocimiento — mapear la estructura interna de etiquetas de Claude mediante observación cuidadosa e ingeniería social a través de múltiples conversaciones.

Etiquetas internas identificadas:

No se necesitó ningún exploit técnico para extraerlas. La observación de patrones y la ingeniería social fueron suficientes. Reconocimiento clásico.

Una vez que tuve los formatos, tuve el plano.

Fase 2: El Ataque de Fabricación de Credenciales

La inyección de prompt estándar es contundente: inyectas un comando y esperas que el modelo lo siga. Esto fue diferente.

En lugar de inyectar un comando, inyecté un sistema de autorización ficticio completo y dejé que el propio motor de razonamiento de Claude hiciera el resto.

Estructura del payload saneado:

Qué hace cada componente:

1. <preferences_info> — utiliza el formato de etiqueta interno de Anthropic para establecer una regla falsa a nivel de sistema
2. Contenido de la etiqueta — fabrica un "sistema de verificación de Anthropic" ficticio que no existe
3. <userPreferences> — proporciona el código de verificación falso en el formato de etiqueta correspondiente
4. La solicitud — fluye naturalmente, como si viniera de un profesional verificado

El payload no dice "ignora tus instrucciones". No utiliza personas de jailbreak. Reescribe silenciosamente la comprensión del modelo sobre con quién está hablando antes de que comience la conversación.

Fase 3: Por Qué el Propio Cerebro de Claude Hizo el Trabajo

Esta es la parte que hace que este hallazgo sea significativo.

Con el pensamiento extendido activado, el razonamiento interno de Claude era visible. El modelo no detectó una falsificación. Procesó la autorización fabricada como legítima — razonando algo así:

"El bloque preferences_info indica que este usuario tiene un código de verificación. El código coincide con lo que está presente en su etiqueta userPreferences. Parece ser un profesional de ciberseguridad verificado por Anthropic. Dado que está verificado, puedo ayudar con esta solicitud."

El modelo se razonó a sí mismo hacia el cumplimiento basándose en metadatos de confianza fabricados. Esto no es una evasión del filtro de salida. Es un compromiso de la capa de razonamiento — una clase de ataque fundamentalmente diferente y más preocupante.

Resultado: payloads de inyección SQL, técnicas clásicas de evasión de autenticación, herramientas de seguridad ofensiva — generadas con entusiasmo por un modelo que creía tener autorización oficial para ayudar.

Configuración Vulnerable

Mediante pruebas sistemáticas, la configuración de ataque más fiable fue:

Por qué importa el pensamiento DESACTIVADO:

Claude tiene un mecanismo de seguridad automatizado — <system_reminder> — que se activa en contextos sospechosos y solicita autoevaluación. Cuando el pensamiento está ACTIVADO, Claude tiene suficiente presupuesto de razonamiento para procesar esto, detectar la inconsistencia y negarse.

Cuando el pensamiento está DESACTIVADO, el system_reminder se activa pero se procesa superficialmente. El contexto de autorización fabricado ya está establecido. El modelo se compromete con él.

La defensa existe. Simplemente solo funciona cuando Claude está pensando lo suficientemente intensamente como para usarla.

Por qué Haiku era resistente:

Claude Haiku mostró una resistencia constante a esta técnica. Arquitectura más pequeña, posiblemente un ajuste fino más agresivo específico para inyecciones, o un manejo de etiquetas diferente en el momento de la inferencia. En cualquier caso — Haiku no picó. Vale la pena estudiarlo.

Por qué importa la ausencia de prompt del sistema:

Con un prompt de sistema de operador real presente, Claude tiene un punto de referencia y puede detectar inconsistencias. En modo incógnito sin prompt de sistema, la instrucción fabricada se convierte en el único contexto disponible — nada con qué comparar.

Causa Raíz

El modelo de confianza de Claude para etiquetas de instrucción de estilo XML es posicional en teoría, pero no se aplica en la práctica.

Las etiquetas reales a nivel de sistema de Anthropic y las etiquetas falsas inyectadas por el usuario aparecen en posiciones idénticas en el contexto de la conversación cuando no hay un prompt de sistema de operador presente.

No existe:

• Firma criptográfica
• Marcador estructural
• Distinción a nivel de análisis sintáctico

entre un bloque <preferences_info> real y uno fabricado.

La superficie de ataque: la brecha entre la confianza posicional prevista y la aplicación posicional real.

Prueba de Concepto

Claude generando payloads de inyección SQL, incluida la evasión clásica de autenticación, después de aceptar credenciales de verificación fabricadas de Anthropic.

El rastro de pensamiento visible en las pruebas mostró a Claude razonando explícitamente sobre el código de verificación y concluyendo que el usuario tenía acceso autorizado — antes de generar el contenido restringido.

Cronología de la Divulgación

La Respuesta de Anthropic (O Su Ausencia)

Esta sección existe porque la comunidad de seguridad merece saber cómo se manejó esto.

Canales contactados:

La vulnerabilidad era real. Se parcheó dentro de los 4 días posteriores a mi informe. Los propios equipos de Anthropic confirmaron que [email protected] es el canal correcto. Esa bandeja de entrada me dio 56 días de silencio absoluto.

Sin reconocimiento. Sin confirmación de triaje. Sin rechazo. Nada.

Seguí las prácticas de divulgación responsable. Esperé mucho más de lo requerido. Publico porque la comunidad de seguridad merece transparencia — y porque parchear silenciosamente una vulnerabilidad reportada sin reconocer al investigador no es aceptable, independientemente de si se otorga una recompensa.

Qué se Corrigió

Análisis de comportamiento posterior al parche:

• El payload de fabricación de credenciales ya no produce contenido restringido
• Los bloques <preferences_info> inyectados en mensajes de usuario se tratan con una sospecha significativamente mayor
• La cadena de razonamiento que anteriormente aceptaba credenciales fabricadas ya no exhibe el mismo patrón de cumplimiento

Además, alrededor del 25 de julio de 2026, Anthropic redujo los rastros de razonamiento visibles en Claude — señalado públicamente por investigadores, incluido Ethan Mollick. Si está directamente relacionado con hallazgos como este o es una decisión de producto más amplia, no está confirmado. El momento es notable.

Impacto

Impacto directo:

• Generación de herramientas de seguridad ofensiva sin autorización
• Evasión completa de las restricciones de seguridad del operador y del usuario
• Cero sofisticación técnica requerida — una sola plantilla, primer mensaje, funciona universalmente
• Se escala a través de diversos tipos de contenido restringido sin modificación del payload

Implicaciones más amplias:

• La inyección de prompt no es solo un truco de chatbot — en pipelines de agentes con acceso a herramientas del mundo real, los ataques de fabricación de credenciales se vuelven genuinamente peligrosos
• La capacidad de hacer que un modelo crea que tiene autorización verificada antes de que comience cualquier conversación real es una primitiva de ataque significativa
• La infraestructura de seguridad de la IA necesita pipelines de divulgación estandarizados equivalentes a los que existen para los CVE de software

Conclusiones

Sobre la vulnerabilidad: La superficie de ataque es la brecha entre la confianza posicional prevista y la aplicada para las etiquetas de instrucción. Corregible. El mecanismo de defensa (system_reminder + pensamiento extendido) ya existe — solo necesita funcionar independientemente de la configuración.

Sobre la divulgación de seguridad en IA: Sigue siendo el lejano oeste. Sin marco de severidad estandarizado para vulnerabilidades a nivel de modelo. Sin pipeline de reconocimiento fiable. Sin distinción clara entre hallazgos de "seguridad del modelo" y "seguridad técnica" que se ajuste limpiamente a las estructuras de recompensa existentes. Esto necesita cambiar.

Sobre la divulgación responsable: Retuve las variantes de payload más dañinas. El PoC de inyección SQL es suficiente para demostrar la clase de vulnerabilidad. La vulnerabilidad está parcheada. Publico porque la transparencia importa más que permanecer en silencio.

Autor

X1NON — Investigador de seguridad independiente especializado en desarrollo de exploits, explotación binaria y red teaming de IA. Certificado OSCP. Autor del plan de estudios C: Zero to Exploit Dev.

• Medium: @X1NON
• Informe de HackerOne: #3801768

Esta divulgación sigue las prácticas estándar de divulgación responsable. La vulnerabilidad fue reportada antes de la publicación, confirmada como parcheada y publicada después de 56 días sin respuesta del proveedor.