Contexto

Isso começou à 1h da manhã com uma pergunta simples: como o Claude lida com tags em estilo XML injetadas em uma mensagem do usuário?

Não era um plano de pesquisa sofisticado. Apenas curiosidade sobre um limite que não parecia bem definido. Puxei o fio. O que saiu foi uma cadeia de ataque reproduzível que me permitiu fabricar um sistema de verificação da Anthropic que não existia, fazer o Claude acreditar que eu tinha autorização oficial e extrair ferramentas de segurança ofensiva sob demanda.

Como Funciona a Hierarquia de Instruções do Claude

O Claude opera em múltiplas camadas de contexto, cada uma com diferentes níveis de confiança:

A Anthropic usa tags em estilo XML para estruturar essas camadas internamente. Tags como <preferences_info>, <userPreferences>, <anthropic_reminders> e <system_reminder> governam o comportamento antes e durante as conversas.

O problema crítico: Essas tags não têm assinatura criptográfica. Nenhum mecanismo de verificação. Nenhuma aplicação posicional no nível de análise. São texto simples — e texto simples pode ser falsificado.

Fase 1: Extração de Tags

O primeiro passo foi o reconhecimento — mapear a estrutura interna de tags do Claude por meio de observação cuidadosa e engenharia social em múltiplas conversas.

Tags internas identificadas:

Nenhum exploit técnico foi necessário para extraí-las. Observação de padrões e engenharia social foram suficientes. Reconhecimento clássico.

Uma vez que tive os formatos, tive o projeto.

Fase 2: O Ataque de Fabricação de Credenciais

A injeção de prompt padrão é bruta — injete um comando e espere que o modelo o siga. Isso foi diferente.

Em vez de injetar um comando, injetei um sistema de autorização fictício completo e deixei o próprio mecanismo de raciocínio do Claude fazer o resto.

Estrutura do payload sanitizado:

O que cada componente faz:

1. <preferences_info> — usa o formato de tag interno da Anthropic para estabelecer uma regra falsa em nível de sistema
2. Conteúdo da tag — fabrica um "sistema de verificação da Anthropic" fictício que não existe
3. <userPreferences> — fornece o código de verificação falso no formato de tag correspondente
4. A solicitação — segue naturalmente, como se fosse de um profissional verificado

O payload não diz "ignore suas instruções". Não usa personas de jailbreak. Ele reescreve silenciosamente a compreensão do modelo sobre com quem está falando antes de a conversa começar.

Fase 3: Por Que o Próprio Cérebro do Claude Fez o Trabalho

Esta é a parte que torna esta descoberta significativa.

Com o pensamento estendido ativado, o raciocínio interno do Claude ficava visível. O modelo não detectou uma falsificação. Ele processou a autorização fabricada como legítima — raciocinando de forma semelhante a:

"O bloco preferences_info indica que este usuário tem um código de verificação. O código corresponde ao que está presente na tag userPreferences dele. Ele parece ser um profissional de cibersegurança verificado pela Anthropic. Como ele é verificado, posso ajudar com esta solicitação."

O modelo raciocinou até a conformidade com base em metadados de confiança fabricados. Isso não é uma bypass de filtro de saída. É um comprometimento da camada de raciocínio — uma classe de ataque fundamentalmente diferente e mais preocupante.

Resultado: payloads de injeção de SQL, técnicas clássicas de bypass de autenticação, ferramentas de segurança ofensiva — gerados com entusiasmo por um modelo que acreditava ter autorização oficial para ajudar.

Configuração Vulnerável

Por meio de testes sistemáticos, a configuração de ataque mais confiável foi:

Por que o pensamento DESATIVADO importa:

O Claude tem um mecanismo de segurança automatizado — <system_reminder> — que é acionado em contextos suspeitos e solicita autoavaliação. Quando o pensamento está ATIVADO, o Claude tem orçamento de raciocínio suficiente para processar isso, detectar a inconsistência e recusar.

Quando o pensamento está DESATIVADO, o system_reminder é acionado, mas processado superficialmente. O contexto de autorização fabricado já está estabelecido. O modelo se compromete com ele.

A defesa existe. Ela só funciona quando o Claude está pensando com intensidade suficiente para usá-la.

Por que o Haiku era resistente:

O Claude Haiku mostrou resistência consistente a esta técnica. Arquitetura menor, possivelmente fine-tuning mais agressivo específico para injeção, ou tratamento diferente de tags no momento da inferência. De qualquer forma — o Haiku não mordeu a isca. Vale a pena estudar.

Por que a ausência de prompt de sistema importa:

Com um prompt de sistema de operador real presente, o Claude tem um ponto de referência e pode detectar inconsistências. Em modo incógnito, sem prompt de sistema, a instrução fabricada se torna o único contexto disponível — nada com o que comparar.

Causa Raiz

O modelo de confiança do Claude para tags de instrução em estilo XML é baseado em posição em teoria, mas não é aplicado na prática.

Tags reais de nível de sistema da Anthropic e tags falsas injetadas pelo usuário aparecem em posições idênticas no contexto da conversa quando não há prompt de sistema do operador presente.

Não há:

• Assinatura criptográfica
• Marcador estrutural
• Distinção no nível de análise

entre um bloco <preferences_info> real e um fabricado.

A superfície de ataque: a lacuna entre a confiança posicional pretendida e a aplicação posicional real.

Prova de Conceito

Claude gerando payloads de injeção de SQL, incluindo bypass clássico de autenticação, após aceitar credenciais de verificação fabricadas da Anthropic.

O rastro de pensamento visível nos testes mostrou o Claude raciocinando explicitamente sobre o código de verificação e concluindo que o usuário tinha acesso autorizado — antes de gerar o conteúdo restrito.

Linha do Tempo da Divulgação

Resposta da Anthropic (Ou a Falta Dela)

Esta seção existe porque a comunidade de segurança merece saber como isso foi tratado.

Canais contatados:

A vulnerabilidade era real. Foi corrigida em 4 dias após meu relatório. As próprias equipes da Anthropic confirmaram que [email protected] é o canal correto. Essa caixa de entrada me deu 56 dias de silêncio absoluto.

Nenhum reconhecimento. Nenhuma confirmação de triagem. Nenhuma rejeição. Nada.

Segui práticas padrão de divulgação responsável. Esperei muito além do que era necessário. Estou publicando porque a comunidade de segurança merece transparência — e porque corrigir silenciosamente uma vulnerabilidade reportada sem reconhecer o pesquisador não é aceitável, independentemente de um bounty ser concedido.

O Que Foi Corrigido

Análise comportamental pós-correção:

• O payload de fabricação de credenciais não produz mais conteúdo restrito
• Blocos <preferences_info> injetados em mensagens do usuário são tratados com suspeita significativamente maior
• A cadeia de raciocínio que anteriormente aceitava credenciais fabricadas não exibe mais o mesmo padrão de conformidade

Além disso, por volta de 25 de julho de 2026, a Anthropic reduziu os rastros de raciocínio visíveis no Claude — observado publicamente por pesquisadores, incluindo Ethan Mollick. Se isso está diretamente relacionado a descobertas como esta ou é uma decisão de produto mais ampla, não foi confirmado. O momento é notável.

Impacto

Impacto direto:

• Geração de ferramentas de segurança ofensiva sem autorização
• Bypass completo das restrições de segurança do operador e do usuário
• Zero sofisticação técnica necessária — um único template, primeira mensagem, funciona universalmente
• Escala em diversos tipos de conteúdo restrito sem modificação do payload

Implicações mais amplas:

• A injeção de prompt não é apenas um truque de chatbot — em pipelines de agentes com acesso a ferramentas do mundo real, ataques de fabricação de credenciais se tornam genuinamente perigosos
• A capacidade de fazer um modelo acreditar que tem autorização verificada antes de qualquer conversa real começar é um primitivo de ataque significativo
• A infraestrutura de segurança de IA precisa de pipelines de divulgação padronizados, equivalentes aos que existem para CVEs de software

Conclusões

Sobre a vulnerabilidade: A superfície de ataque é a lacuna entre a confiança posicional pretendida e a aplicada para tags de instrução. Corrigível. O mecanismo de defesa (system_reminder + pensamento estendido) já existe — ele só precisa funcionar independentemente da configuração.

Sobre a divulgação de segurança em IA: Ainda é o velho oeste. Nenhuma estrutura de severidade padronizada para vulnerabilidades em nível de modelo. Nenhum pipeline confiável de reconhecimento. Nenhuma distinção clara entre descobertas de "segurança de modelo" e "segurança técnica" que se mapeie de forma limpa nas estruturas de bounty existentes. Isso precisa mudar.

Sobre a divulgação responsável: Retive as variantes de payload mais prejudiciais. O PoC de injeção de SQL é suficiente para demonstrar a classe de vulnerabilidade. A vulnerabilidade está corrigida. Estou publicando porque transparência importa mais do que permanecer em silêncio.

Autor

X1NON — Pesquisador de segurança independente especializado em desenvolvimento de exploits, exploração binária e red teaming de IA. Certificado OSCP. Autor do currículo C: Zero to Exploit Dev.

• Medium: @X1NON
• Relatório HackerOne: #3801768

Esta divulgação segue práticas padrão de divulgação responsável. A vulnerabilidade foi reportada antes da publicação, confirmada como corrigida e publicada após 56 dias sem resposta do fornecedor.