LLM2SQLi, LLM2XSS, LLM2SSRF: pesquisa sistematiza como LLMs reintroduzem vulnerabilidades web clássicas
Um novo estudo sistematiza a classe de "LLM-mediated web attacks", em que entrada controlada por um atacante é transformada por um LLM integrado a uma aplicação web e, a partir daí, alcança pontos sensíveis tradicionais como consultas SQL, templates, comandos de shell ou chamadas HTTP internas — reproduzindo injeção SQL, XSS, SSTI, injeção de comando, IDOR, CSRF, XXE e SSRF através de um novo vetor de mediação por IA. Usando uma aplicação de teste (TicketOracle) contra sete LLMs diferentes, os autores mostram que a suscetibilidade a esse tipo de exploração varia fortemente conforme o modelo, não apenas conforme a arquitetura da aplicação.
O trabalho parte de uma observação simples, mas com implicações grandes: quando um LLM está integrado a uma aplicação web — respondendo a chatbots, orquestrando chamadas de ferramentas, gerando consultas ou renderizando conteúdo — a entrada do usuário deixa de influenciar apenas o texto gerado e passa a poder influenciar ações de backend: queries de banco, requisições HTTP, operações de arquivo, renderização de templates, chamadas de API. Os autores argumentam que isso reabre uma classe inteira de vulnerabilidades web clássicas que a indústria já sabia mitigar, agora através de um caminho novo e frequentemente não tratado pelas defesas existentes.
A contribuição central é a taxonomia: LLM2SQLi, LLM2XSS, LLM2SSTI, LLM2CommandInjection, LLM2IDOR, LLM2CSRF, LLM2XXE e LLM2SSRF descrevem, cada um, como o mesmo padrão de vulnerabilidade tradicional pode ser alcançado com o LLM atuando como camada de mediação entre a entrada do atacante e o sink vulnerável. O ponto técnico mais importante do artigo é que, na maioria dos casos, o LLM não cria a vulnerabilidade — ela já existiria na aplicação se a mesma entrada chegasse diretamente ao sink —, mas atua como um confused deputy: um componente com mais confiança e mais permissões do que o usuário original, que repassa ou amplifica a influência do atacante para dentro do sistema.
Como estudo de caso, os pesquisadores implementaram o TicketOracle, uma aplicação Flask real com integração LLM, e avaliaram especificamente LLM2SSRF (o LLM sendo induzido a fazer a aplicação emitir requisições para endereços internos ou não autorizados) em cinco cenários de ataque contra sete modelos distintos. A variação de suscetibilidade entre os modelos foi substancial — alguns bloqueiam consistentemente o padrão de entrada malicioso, outros o repassam sem hesitação —, o que os autores atribuem a uma combinação de arquitetura insegura da aplicação e comportamento específico de cada modelo, e não a um fator isolado.
A implicação prática para quem constrói aplicações com LLM é que revisar apenas o prompt ou a política de conteúdo do modelo não é suficiente: como em qualquer aplicação web, a saída do LLM ainda precisa ser tratada como entrada não confiável no momento em que chega a um sink sensível (parametrização de queries, escaping de templates, allowlist de destinos de rede, etc.). O artigo prescreve mitigação em múltiplas camadas — prompt, modelo, aplicação e rede —, reforçando que a segurança de aplicações LLM-integradas deve herdar, não substituir, as práticas de segurança web tradicionais.