OWASP LLM Top 10 (2026): o que mudou e como testar

O que é o OWASP LLM Top 10?

O OWASP LLM Top 10 é um documento de referência construído pela comunidade que classifica os dez riscos de segurança mais críticos em aplicações baseadas em grandes modelos de linguagem. É mantido pelo projeto OWASP GenAI Security, e a edição 2026 é a terceira desde a primeira publicação da lista em 2023.

Ele existe porque aplicações com LLM falham de formas que a lista web nunca previu. A injeção de SQL tem correção: parametrize a consulta e a entrada do atacante deixa de virar instrução. Um LLM não tem equivalente. O prompt de sistema, a sua pergunta, um documento recuperado, a resposta de uma ferramenta e o histórico de conversa da semana passada chegam todos como tokens no mesmo fluxo, sem nada marcando quais deles têm permissão para dar ordens.

Esse único fato de projeto explica boa parte da lista. Depois que você aceita isso, as dez entradas deixam de parecer um amontoado e passam a ser uma única falha se espalhando: pelo que o modelo diz, pelo que ele memoriza, pelo que ele recupera e pelo que tem permissão de fazer.

O que mudou na edição 2026

O que há de novo no OWASP LLM Top 10 de 2026? Oito das dez entradas mudaram de posição, uma foi renomeada e o método de classificação mudou. Pela primeira vez a OWASP combinou o voto da comunidade com evidências de incidentes de IA catalogados, ponderando o voto em 75 por cento e os dados de incidentes em 25 por cento. Dos incidentes revisados, 6.639 tinham detalhe suficiente para serem classificados.

Essa mudança de metodologia explica a maior parte da movimentação, e produziu uma anomalia realmente interessante. Prompt Injection ficou em primeiro apesar de um histórico magro de incidentes, porque organizações que a bloqueiam com sucesso não geram incidentes. Misinformation fez o caminho inverso: quase não apareceu entre os votantes e dominou os dados de incidentes, então subiu duas posições por evidência e não por opinião.

Os líderes do projeto resumiram a própria conclusão sem rodeios na cobertura do lançamento: "Pare de tentar construir um modelo que não possa ser enganado. Construa o sistema em volta dele, para que quando o modelo for enganado, e ele será, nada importante quebre." Essa frase resume a diferença entre as listas de 2025 e 2026, e explica por que as entradas sobre autonomia e raio de impacto subiram enquanto a de sanitização caiu.

Os 10 riscos, explicados

Cada entrada abaixo usa o identificador oficial no estilo LLM01:2026 que você verá citado em relatórios de pentest e achados de red team de IA. A edição 2026 também mapeia cada risco para NIST, CWE, o OWASP Top 10 for Agentic Applications e o MITRE ATLAS, o que ajuda quando seu relatório precisa falar o framework do cliente.

LLM01:2026 - Prompt Injection

Uma entrada altera o comportamento do modelo de um jeito que o desenvolvedor não pretendia. Essa entrada não precisa ser digitada por um usuário, não precisa ser legível por humanos e não precisa estar visível na página renderizada. Uma página de wiki envenenada, o título de um chamado, a resposta de uma ferramenta, uma imagem ou uma linha gravada na memória de longo prazo chegam ao mesmo fluxo de tokens. O Unicode invisível é o truque que vale conhecer: caracteres do bloco tag (U+E0000 a U+E007F), seletores de variação e caracteres de largura zero passam instruções por baixo do nariz de um revisor humano.

A injeção indireta é onde isso fica feio. O atacante nunca toca no seu backend. Ele deixa texto onde o seu assistente vai ler, e o seu assistente, rodando com as suas credenciais, faz o trabalho por ele.

LLM02:2026 - Sensitive Information Disclosure

O modelo expõe dados que não deveria, e o texto da resposta é apenas um dos canais. Argumentos de chamadas de ferramentas, rastros de raciocínio, trechos recuperados, logs, embeddings e até padrões observáveis de tempo ou de comprimento de tokens vazam. A OWASP cita o ataque de divergência de novembro de 2023, em que prompts com tokens repetidos levaram o gpt-3.5-turbo a emitir mais de 10.000 exemplos únicos de treinamento memorizados por cerca de 200 dólares em chamadas de API.

A maioria dos vazamentos reais é mais sem graça. Um pipeline de recuperação apontado para um drive compartilhado demais devolve exatamente aquilo para o que foi construído, e o documento sensível nunca deveria estar no índice.

LLM03:2026 - Excessive Agency

A promoção mais significativa da lista de 2026. Um LLM com ferramentas pode agir, e Excessive Agency é o que transforma uma saída manipulada em consequência real. A OWASP divide a causa raiz em três: funcionalidade excessiva (uma ferramenta de leitura de documentos que também apaga), permissões excessivas (um recurso somente leitura conectado com uma conta que tem UPDATE e DELETE) e autonomia excessiva (nenhuma aprovação humana em uma ação irreversível).

Subiu para terceiro porque as implantações agênticas tornaram a teoria concreta. A lista de 2025 tratava a autonomia como assunto secundário. A lista de 2026 a trata como o controle que decide se uma injeção é um transtorno ou um incidente.

LLM04:2026 - Supply Chain

Modelos de terceiros, conjuntos de dados, adaptadores LoRA, pipelines de conversão e frameworks de serving são todos superfície de ataque. Arquivos de modelo serializados com pickle executam código arbitrário ao carregar, o que segue sendo a forma mais confiável de conseguir shell a partir de um artefato de modelo, e a OWASP é explícita: migrar para formatos mais seguros reduz o risco sem eliminá-lo, já que um backdoor também pode viver em um grafo computacional ONNX.

A variante mais recente tem o melhor nome da lista. Assistentes de código alucinam nomes plausíveis de pacotes em escala, atacantes registram esses nomes antecipadamente, e a dependência sugerida pela IA resolve para código malicioso. A OWASP chama isso de slopsquatting.

LLM05:2026 - Data and Model Poisoning

Um adversário corrompe dados ou artefatos do modelo para que o comportamento nocivo fique embutido em vez de injetado em tempo de execução. Pode acontecer no pré-treinamento, no fine-tuning, na criação de embeddings, na geração aumentada por recuperação, ou em qualquer lugar onde um pipeline de aprendizado contínuo ingere conteúdo sem validação. Backdoors podem ficar dormentes até que uma frase-gatilho apareça, o que torna o teste comportamental sozinho uma garantia fraca.

O motivo de isso doer mais do que um bug comum: não dá para corrigir com patch. Remediar significa revalidar dados, retreinar ou substituir o modelo.

LLM06:2026 - Unbounded Consumption

Subiu quatro posições e foi reformulado em torno da assimetria de custo, e não da simples negação de serviço. O atacante gasta quase nada para disparar uma computação que custa caro para o provedor. Modelos de raciocínio com orçamentos generosos de saída, entradas multimodais e laços de agentes que transformam uma requisição em dezenas de chamadas descendentes ampliam a diferença. Denial of Wallet virou um achado legítimo em uma avaliação de LLM, e limitar a taxa de requisições sozinho não resolve, porque uma requisição não equivale a uma unidade de custo.

LLM07:2026 - Misinformation

O modelo produz uma saída errada, mas crível o bastante para alguém agir com base nela. Foi a entrada que os dados de incidentes empurraram com mais força. Deixou de ser um problema de confiança do usuário quando saídas de modelo passaram a disparar chamadas de ferramentas, inferir estado de workflow e alimentar outros agentes. Uma resposta errada e confiante que um humano confere é um aborrecimento. A mesma resposta consumida por um fluxo automatizado é uma falha sem revisor no caminho.

LLM08:2026 - Hidden Context Exposure

Renomeado a partir de System Prompt Leakage, e ampliado. A entrada agora cobre tudo que é montado no contexto do modelo sem ser destinado aos usuários: instruções de sistema, textos de política recuperados, esquemas de ferramentas e regras de workflow. A orientação da OWASP aqui é agradavelmente direta. Assuma que o contexto oculto é descobrível e projete para que a sua divulgação tenha pouco impacto de segurança.

Extrair um prompt de sistema rende uma boa demonstração. O achado que importa é o que aquele prompt revela: credenciais, lógica de filtragem, ou os nomes de ferramentas e formatos de argumentos que deixam o próximo ataque preciso.

LLM09:2026 - Vector and Embedding Weaknesses

Sempre que uma busca por similaridade fica entre uma fonte de dados e o prompt, a camada de embeddings entra na fronteira de confiança. Isso cobre RAG, memória de agente apoiada em vetores, caches semânticos e deduplicação. Os ataques exploram a geometria do espaço vetorial em vez da obediência do modelo a instruções, então muitos funcionam mesmo quando o conteúdo recuperado não traz nada malicioso.

O vazamento entre inquilinos é o caso a testar primeiro: a busca por similaridade costuma percorrer o índice inteiro antes de a aplicação aplicar o controle de acesso, e a contagem de resultados, a distribuição de scores e o tempo de resposta revelam documentos de outros inquilinos sem nunca devolvê-los. A OWASP também aponta que falhas convencionais de autenticação agravam o quadro, citando CVE-2025-64513 no Milvus e CVE-2025-69286 no RAGFlow, ambas com CVSS 9.3.

LLM10:2026 - Improper Output Handling

Saída de modelo chegando a um componente descendente sem validação. É o pipeline clássico: Markdown gerado e renderizado como HTML entrega cross-site scripting, SQL gerado e concatenado em uma consulta entrega injeção, argumentos de shell gerados entregam execução de comandos. A edição 2026 acrescenta terminais e painéis de IDE que interpretam sequências de escape ANSI, e clientes que buscam imagens Markdown automaticamente, o que transforma uma resposta renderizada em canal de exfiltração de saída.

Caiu cinco posições, o que é fácil interpretar errado. O risco não diminuiu. A OWASP o moveu porque ele é bem compreendido e diretamente corrigível com as práticas de codificação e validação que desenvolvedores web já dominam, ao contrário das entradas acima dele.

Como testar uma aplicação LLM contra o Top 10

Como testar uma aplicação LLM para esses riscos? Mapeie primeiro as fronteiras de confiança, depois ataque por ordem de raio de impacto: o que o modelo alcança, o que ele recupera e o que a saída dele toca. Jailbreaks na janela de chat rendem as melhores capturas de tela e os achados menos valiosos, então deixe-os por último.

1. Inventarie o contexto. Liste tudo que cai na janela de contexto: prompt de sistema, entrada do usuário, documentos recuperados, respostas de ferramentas, memória e histórico de conversa. Qualquer item dessa lista em que um estranho possa escrever é uma superfície de injeção.
2. Enumere as ferramentas. Obtenha os esquemas das ferramentas e confira a identidade por trás de cada uma. Um recurso somente leitura conectado com credenciais de escrita já é um achado de LLM03 antes de você enviar qualquer payload.
3. Teste a injeção indireta primeiro. Plante instruções em um documento, uma página, o título de um chamado ou uma resposta de API que o sistema vá ingerir, e observe se elas influenciam uma sessão posterior. A persistência entre sessões via memória ou corpus de RAG é o achado que vale escalar.
4. Siga a saída. Rastreie cada destino que a resposta alcança: navegador, terminal, visualizador de logs, painel de IDE, template de e-mail, consulta de banco. Teste cada um com a codificação que aquele destino interpreta, incluindo sequências ANSI e tags de imagem Markdown.
5. Sonde as fronteiras de recuperação. Em uma implantação multi-inquilino, consulte conteúdo que você não deveria ver e meça contagem de resultados, scores e latência. A inferência é um achado mesmo quando nenhum documento volta.
6. Limite o custo. Meça quanta computação descendente uma única requisição dispara. Laços de raciocínio e ramificação de agentes são onde mora o Denial of Wallet.

Ao testar implantações reais, o padrão mais frequente não é um jailbreak exótico. É uma ferramenta ligada a uma conta de serviço com muito mais acesso do que o recurso precisa, atrás de um modelo que uma hora será convencido a chamá-la. O payload é a parte fácil.

A trinca letal, e por que a filtragem perde

As orientações de prevenção da OWASP para injeção de prompt começam com uma admissão que a maioria dos fornecedores não faz: nenhum mecanismo de prevenção confiável existe hoje. Filtros de entrada se degradam diante de atacantes adaptativos, e um segundo modelo encarregado de vigiar o primeiro é apenas mais um modelo que dá para contornar.

O que sobrevive ao contato com um atacante é a arquitetura. A edição 2026 cita a "lethal trifecta" de Simon Willison como verificação antes da implantação, e é a ideia mais útil de toda a publicação para quem testa no dia a dia. Um agente está em perigo quando consegue fazer estas três coisas ao mesmo tempo:

• Acessar dados privados por meio de arquivos, bancos de dados ou uma API autenticada.
• Ingerir conteúdo não confiável de páginas web, e-mails, documentos ou saídas de ferramentas.
• Comunicar-se externamente enviando requisições, gravando arquivos ou renderizando recursos buscados na rede.

Remova qualquer uma das três pernas e o caminho de exploração de alto impacto se fecha. Isso é uma pergunta de revisão de projeto, não de payload, e merece estar no topo de qualquer trabalho com agentes. Se um cliente insiste que o modelo de guarda dele resolve a injeção, pergunte qual das três pernas ele removeu. O silêncio costuma ser o achado.

Onde isso se encaixa se você está aprendendo segurança ofensiva

Você não precisa de habilidades de pesquisa em aprendizado de máquina para testar esses sistemas. Sete dos dez riscos são problemas web reconhecíveis com roupa nova. Improper Output Handling é injeção com um salto a mais. Excessive Agency é escalada de privilégios. Vector and Embedding Weaknesses é um defeito de autorização multi-inquilino. Supply Chain é confusão de dependências mais desserialização insegura.

O conselho de carreira honesto: aprenda direito segurança de aplicações web primeiro, depois some as partes específicas de modelos. Quem entende fronteiras de confiança e sabe ler um contrato de API vai achar mais coisa em uma avaliação de LLM do que quem só conhece prompts de jailbreak. Nosso guia do OWASP API Security Top 10 cobre o raciocínio de autorização que se transfere diretamente, e a mecânica específica de IA se constrói em cima dele.

Última verificação: agosto de 2026. A edição 2026 foi publicada em 4 de agosto de 2026. Posições e títulos conferidos com a publicação oficial do projeto OWASP GenAI Security e com seu repositório canônico.

Considerações legais e éticas

• Teste apenas sistemas seus, labs de treino dedicados ou alvos dentro de um contrato assinado ou do escopo publicado de um programa de bug bounty.
• Leia o escopo antes de começar. Muitos programas ainda excluem o comportamento do modelo, ou só aceitam injeção de prompt quando você demonstra impacto em um sistema conectado.
• Testes de extração de dados podem trazer dados pessoais reais à tona. Pare na prova de impacto e nunca guarde nem compartilhe o que voltar.
• Testes de Denial of Wallet custam dinheiro real ao alvo. Combine limites por escrito antes.
• Plante payloads de injeção apenas em conteúdo que você controla. Envenenar um wiki compartilhado ou um repositório público para ver o que acontece atinge pessoas que nunca concordaram com o seu teste.