A Agulha no Palheiro: Como LLMs Ajudam na Busca por Vulnerabilidades

64K+ Alcance em 30 dias Bastion 241,84 Classificação 27 097 Assinantes Assinar srzybnev Há 59 minutos A Agulha no Palheiro: Como LLMs Ajudam na Busca por Vulnerabilidades Média 21 min 2.4K Blog da empresa Bastion Segurança da Informação * Aprendizado de Máquina * Tradução Autor original: devansh Observação: originalmente, eu queria escrever um artigo grande que cobrisse toda a metodologia e os detalhes técnicos das técnicas que uso: fuzzing diferencial baseado em IA, fuzzing baseado em gramática, geração automática de harness e os fluxos de trabalho associados. Mas percebi que, se colocasse tudo em um texto, ele se tornaria excessivamente denso e difícil de ler. Portanto, esta é a primeira parte. Aqui, dou uma visão geral de alto nível da metodologia e das ideias-chave em que minha abordagem para usar LLMs se baseia. Nas próximas publicações, analisarei os detalhes técnicos e a implementação de cada componente com mais detalhes. Tudo o que é descrito abaixo é estritamente para fins de treinamento e pesquisa. Qualquer uso inadequado ou atividade maliciosa com base nele é de responsabilidade de quem o faz. Conteúdo Introdução Por que a solicitação "encontre todas as vulnerabilidades" não funciona A estrutura mínima que realmente ajuda Caso: Claude Opus 4.6 e Firefox O que a Anthropic realmente fez Minha metodologia Aproximação Parse Server HonoJS ElysiaJS harden-runner BullFrog Better-Hub Vulnerabilidades encontradas Por que funcionou O meio termo Prompt Injection Fontes Introdução Nas últimas semanas, enviei muitos relatórios de vulnerabilidade. Uma pequena parte deles já foi corrigida e divulgada por meio de boletins de segurança. Todos eles foram encontrados exclusivamente usando LLMs, sem qualquer revisão manual do código-fonte. Os projetos nos quais encontrei esses problemas são bem conhecidos e amplamente utilizados. Entre eles estão os conhecidos como Parse Server , HonoJS , ElysiaJS , Harden Runner e cerca de uma dúzia de outros projetos notáveis. Em minha opinião, isso prova: ferramentas CLI/TUI baseadas em agentes como OpenAI Codex podem, sem dúvida, ajudar a encontrar vulnerabilidades sérias. Mas como usá-las para identificar problemas não óbvios? Após experimentos e milhares e milhares de prompts enviados na tentativa de encontrar vulnerabilidades, cheguei a várias conclusões. Talvez não sejam perfeitas do ponto de vista teórico, mas são as conclusões mais práticas que consegui chegar. Descobri que a maneira mais fácil de perder uma vulnerabilidade importante é:

• Simplificar demais a auditoria de segurança com uma estrutura excessiva e cadeias de prompts;
• Inflar arquivos AGENT.md e SKILLS.md ;
• Superlotar o modelo com contexto - documentos ou planejamento detalhado de cada etapa do processo;
• Tentar orquestrar muita coisa ao mesmo tempo. Soa contraintuitivo, certo? Pessoas sensatas dirão: quanto mais instruções de orientação, melhor o resultado. Mas os sistemas com contexto longo têm um problema real e bem estudado. Quanto mais tokens você preenche na janela de contexto, pior o modelo seleciona os detalhes necessários. Trabalhos recentes chamam isso de context rot : a qualidade está se tornando cada vez menos estável à medida que o comprimento do contexto aumenta, mesmo quando o conteúdo adicionado é formalmente relevante. A auditoria de segurança é quase o pior ambiente para esse problema. A "agulha" aqui geralmente representa uma única violação sutil da propriedade esperada do sistema, enterrada entre milhares de linhas corretas. De acordo com minhas observações, em muitos casos, os modelos se comportam de acordo com o princípio da primazia e da recência: eles se saem melhor quando a "agulha" está no início ou no final do contexto, e pior quando está escondida no meio. Este é o problema da agulha no palheiro em sua forma pura. Então, o que fazer? Descartar AGENTS.md e deixar o LLM vagar livremente pelo código sem qualquer estrutura? Isso leva a problemas ainda mais sérios, mas esse é o tema de outro artigo. Por enquanto, com base em testes e na experiência de encontrar mais de uma dúzia de CVEs em projetos de código aberto populares, fixei a seguinte abordagem para mim: uma estrutura mínima constante, pesquisa e verificação o mais pontuais possível, bem como um fluxo de trabalho que mantém a atenção do modelo no principal. Por que a solicitação "encontre todas as vulnerabilidades" não funciona Digamos que você tenha uma pasta grande com código-fonte monolítico ou acabou de clonar um repositório do GitHub e deseja encontrar vulnerabilidades nele. A primeira coisa que você faz: executa o Codex e escreve o prompt "encontre todas as vulnerabilidades nesta base de código". Este prompt não funciona por duas razões específicas. Quando você escreveu tal prompt, você não especificou um modelo de ameaças. Como resultado, o LLM não entende o impacto de suas descobertas. Ele pode derivar algum modelo de ameaças por conta própria, mas, como mostram meus experimentos, geralmente não o faz, ou o faz mal. Sem um modelo de ameaças normal, limites de confiança, capacidades do invasor e pré-condições, você obterá uma longa lista de hipóteses genéricas semelhantes a CWE sem priorização. Você não terá como distinguir achados interessantes do ruído. A segunda razão é que tal prompt empurra o modelo para a hallucination

breadth-first . Sabemos que prompts amplos provocam respostas amplas. Prompts amplos geram respostas amplas. O modelo começa a mapear o código para classes comuns de bugs, mesmo onde eles são impossíveis em seu contexto específico. Como resultado, você revisará vulnerabilidades teóricas em fragmentos de código que um invasor nunca alcançará. A estrutura mínima que realmente ajuda Como entendemos o que um prompt vago leva, vamos fazer tudo certo. Antes de pedir ao LLM para auditar o código em busca de vulnerabilidades, tente fazer o que as equipes de segurança da informação fazem: defina um modelo de ameaças. A propósito, ele também pode ser gerado usando um LLM. Normalmente, procuro CVEs divulgadas anteriormente no projeto e, com base em suas descrições, peço ao LLM para construir um modelo de ameaças para classes plausíveis de bugs. Por exemplo, se os CVEs divulgados anteriormente estavam relacionados a heap overflow , stack overflow , integer overflow e memory corruption , o LLM tentará construir um modelo de ameaças em torno de tais vulnerabilidades, porque elas já foram reconhecidas como problemas reais. Em seguida, você pega o documento recém-criado com o modelo de ameaças, o alimenta no Codex e pede ao LLM para procurar regras de segurança relacionadas. Ou, por exemplo, encontrar commits que corrigiram essas vulnerabilidades e, em seguida, procurar desvios dessas correções. Com alta probabilidade, isso trará mais vulnerabilidades do que um prompt vago. Nesse caso, toda a estrutura se resume à criação de um modelo de ameaças. Você não escreve nenhum skills.md ou agents.md , não tenta orquestrar nada. Você acabou de criar um modelo de ameaças, entregou-o ao LLM, e agora o modelo está pesquisando a base de código em busca de vulnerabilidades que se enquadram nesse modelo. Quando terminar de procurar vulnerabilidades das mesmas categorias que os CVEs divulgados anteriormente, tente identificar pontos de entrada: rotas HTTP, manipuladores RPC, consumidores de mensagens, pontos de entrada CLI e tarefas agendadas. Defina limites de confiança: navegador ↔ servidor, serviço ↔ serviço, plugin ↔ host, sandbox ↔ parte privilegiada. Destaque operações de alto risco: desserialização, modelagem de templates, vinculações nativas, verificações de autorização e análise de dados não confiáveis. E registre explicitamente o modelo "invasor - vítima": por exemplo, você está interessado em vulnerabilidades que podem ser causadas por um usuário remoto não autenticado, um usuário remoto autenticado com baixa permissão ou um usuário entre locatários. É essa estrutura leve que melhora a qualidade da saída do modelo, sem inflar a janela de contexto. A modelagem de ameaças é o algoritmo de compressão final para sua auditoria de segurança. O mais importante, talvez, a única coisa realmente importante, é primeiro coletar o contexto do sistema. Em seguida, crie um modelo de ameaças editável e continue a expandi-lo durante a auditoria de segurança. Adicione coisas novas a ele e confie no modelo para priorizar as descobertas e, em última análise, validá-las. Caso: Claude Opus 4.6 e Firefox Na publicação da Anthropic de 6 de março de 2026, é descrita a colaboração com a Mozilla, durante a qual o Claude Opus 4.6 encontrou 22 vulnerabilidades em cerca de duas semanas, com a Mozilla avaliando 14 delas como de alta severidade. A postagem da própria Mozilla confirma o resultado e enfatiza por que isso funcionou na prática. Os relatórios vieram com exemplos de teste mínimos, o que acelerou a reprodução e a correção de bugs, e a equipe expandiu a técnica além do mecanismo JS para outras partes do navegador. O que a Anthropic realmente fez A descrição da pesquisa da Anthropic não se resume a "escrevemos um mega-prompt". Eles começaram com um pequeno fragmento da base de código - o mecanismo JavaScript, porque é crítico e pode ser analisado isoladamente. Em seguida, a equipe trabalhou em iterações curtas. Claude descobriu uma vulnerabilidade use-after-free em cerca de 20 minutos de pesquisa, as pessoas confirmaram a descoberta e a equipe enviou um relatório ao Bugzilla com um patch candidato. Assim que o fluxo de trabalho provou sua eficácia, ele foi dimensionado. Como resultado, cerca de 6.000 arquivos C++ foram digitalizados e 112 relatórios exclusivos foram enviados. A maioria das correções foi incluída no Firefox 148.0 (lançado em 24 de fevereiro de 2026). Essa é a abordagem correta? Talvez sim, talvez não. O fato é que muitas das vulnerabilidades descobertas pela Anthropic provavelmente eram inválidas. A equipe precisava relatar vulnerabilidades exploráveis, e para chegar aos vetores exploráveis, você precisa passar do potencial de vulnerabilidade para sua validação e, em seguida, para confirmar a explorabilidade. Essa cadeia é muito cara. A Anthropic gastou cerca de US$ 4.000 em créditos de API. Podemos nos dar ao luxo de gastar tanto em uma auditoria de código? Muito provavelmente, não. Mas estamos trabalhando com a mesma escala de código que no Firefox? Também não. A Anthropic fez isso quase sem estrutura. Mas defendo uma abordagem diferente: usar uma estrutura mínima na forma de um modelo de ameaças e primeiro descrever os limites de confiança. Agora estou falando apenas sobre a busca por vulnerabilidades. Não me aprofundo em sua avaliação e triagem de falsos positivos. Existem maneiras de se mover nessa direção, mas esse é provavelmente o tema de outro post. Por enquanto, você pode fazer o seguinte: se, após criar um modelo de ameaças, o LLM encontrar algumas vulnerabilidades, você pode instruir o Codex a coletar o código-fonte, executar uma instância local ou escrever testes que comprovem a existência de vulnerabilidades. Na maioria dos casos, isso funciona. Minha metodologia A estrutura mínima funciona muito bem e traz muito mais vulnerabilidades, bem como efeitos de "footgun" e limites separados, que prompts vagos nunca darão. Quero mostrar isso em meu trabalho recente, como resultado do qual encontrei mais de 30 vulnerabilidades em vários projetos diferentes em cerca de dois meses. Aproximação Cada auditoria começou da mesma forma. Escolher uma fatia fina e entender seu modelo de confiança antes de pedir ao LLM para procurar vulnerabilidades na base de código. Parse Server Análise detalhada: Four Vulnerabilities in Parse Server Parse Server é um framework de backend de código aberto que fornece API REST, solicitações em tempo real, notificações push e funções de nuvem. Ele suporta vários mecanismos de autenticação, incluindo readOnlyMasterKey. A documentação promete que essa chave dá leitura no nível mestre, mas proíbe qualquer gravação. Antes de pedir ao LLM para procurar alguma coisa, coletei CVEs divulgadas anteriormente para o Parse Server. Os boletins anteriores demonstraram um padrão repetitivo de erros de aplicação de políticas de autorização: as verificações de privilégios existiam, mas eram incompletas ou aplicadas de forma inconsistente em diferentes manipuladores de rotas. Alimentei as descrições desses CVEs no LLM e pedi que gerasse um modelo de ameaças para classes plausíveis de bugs com base nessas informações. O modelo identificou o controle de limites de autorização como a categoria de risco dominante, o que é lógico para a arquitetura do Parse Server com vários tipos de chaves e diferentes níveis de privilégios. Esse modelo de ameaças destacou o readOnlyMasterKey como um limite de confiança interessante. A afirmação aqui é simples: um tipo de chave deve ter estritamente menos recursos do que outro. Direcionei o LLM para essa fronteira e pedi que examinasse como diferentes tipos de chaves interagem com a camada de autorização, quais suposições o código faz sobre a separação de privilégios e onde essas suposições podem ser quebradas. O LLM retornou um mapa de superfície de ataque que destacou um padrão: vários manipuladores de rotas restringiam o acesso por isMaster, mas nunca se referiam a isReadOnly. Esse foi o sinal. Restringi o prompt: pedi para listar todos os manipuladores com esse padrão e rastrear se uma credencial somente leitura pode, por meio de qualquer um deles, chegar a operações de gravação ou alteração de estado. Três das quatro vulnerabilidades (CVE-2026-29182, CVE-2026-30228, CVE-2026-30229) tinham as mesmas premissas. Quando foram confirmadas, abri uma seção separada sobre adaptadores de autenticação social com a mesma abordagem direcionada. Direcionei o LLM para a camada de adaptadores de autenticação e pedi que examinasse o fluxo de verificação do token: quais declarações são verificadas, o que acontece com uma configuração parcial ou ausente e onde a validação pode degradar imperceptivelmente. O LLM apontou o caminho de validação do JWT audience como um ponto fraco, e um prompt de esclarecimento confirmou a quarta descoberta - CVE-2026-30863, um desvio independente da validação do JWT audience, onde o adaptador silenciosamente ignorava a verificação aud se a configuração estivesse incompleta. Outra seção, mas a mesma abordagem. HonoJS Análise detalhada: HonoJS JWT/JWKS Algorithm Confusion HonoJS é um framework web leve e de alto desempenho para JavaScript e TypeScript, que funciona em vários tempos de execução, incluindo Cloudflare Workers, Deno, Bun e Node.js. Ele tem middleware embutido para autenticação JWT e JWKS. Comecei revisando os boletins de segurança do Hono e problemas divulgados anteriormente no middleware de autenticação. Havia poucos CVEs públicos, mas se você adicionar a eles o padrão geral de erros de implementação JWT em projetos vizinhos, a imagem se forma. Quando pedi ao LLM para construir um modelo de ameaças, ele esperadamente atribuiu o trabalho com algoritmos à zona de alto risco e destacou duas classes plausíveis de bugs: confusão de algoritmo e fallback inseguro. Então eu tinha um foco claro - os caminhos de verificação JWT e JWKS. Com esse modelo de ameaças, direcionei o LLM para estudar a lógica de seleção de algoritmo no middleware JWT. Em vez de perguntar sobre vulnerabilidades específicas, pedi para percorrer as configurações incorretas: quais configurações padrão inseguras são esquecidas de serem alteradas, quais caminhos de fallback existem e como o middleware decide em qual algoritmo confiar. O objetivo era que o LLM construísse uma árvore de decisão de seleção de algoritmo e marcasse os ramos onde o middleware pode fazer suposições inseguras. Na análise, o LLM destacou dois padrões potencialmente vulneráveis. Primeiro, ele descobriu um fallback para HS256 quando o algoritmo não está explicitamente fixado. Em segundo lugar, ele observou o comportamento do middleware JWKS, que confiava no valor header.alg do token se o campo alg estivesse ausente no objeto JWK key. Para cada caso, continuei com prompts pontuais: pedi ao LLM para rastrear as condições exatas sob as quais um invasor pode explorar esses fallbacks. Como resultado, foram encontrados dois problemas da classe de confusão de algoritmo. CVE-2026-22817 foi que o middleware JWT por padrão mudou para HS256 se o algoritmo não fosse fixado, o que permitiu que um invasor assinasse tokens com uma chave pública como um segredo HMAC. CVE-2026-22818 foi que o middleware JWKS fez fallback para um valor header.alg não confiável quando não havia campo alg no JWK, permitindo que o invasor ditasse qual algoritmo o servidor usa para verificação. ElysiaJS Análise detalhada: ElysiaJS Cookie Signature Validation Bypass ElysiaJS é um framework web TypeScript para Bun, focado na segurança de tipos e na conveniência do desenvolvedor. Ele tem processamento de cookies embutido com verificação de integridade por meio de assinatura e suporte para rotação de segredos. A geração do modelo de ameaças seguiu o mesmo cenário. Olhei para a documentação do ElysiaJS. Quando passei esse contexto para o LLM e pedi para identificar classes plausíveis de bugs, o modelo observou a lógica de verificação de assinatura como uma zona de alto risco, especialmente o caminho de rotação de segredos, onde vários signing-keys podem ser válidos ao mesmo tempo, e a lógica de verificação deve rejeitar corretamente os cookies que não corresponderam a nenhum deles. Isso me deu uma seção estreita. Direcionei o LLM para a camada de assinatura e verificação de cookies e pedi para raciocinar sobre o gerenciamento de estado durante a verificação: como o código rastreia que a assinatura foi verificada com sucesso, o que acontece ao percorrer vários segredos rotativos, quando nenhum deles corresponde, se há suposições na inicialização, devido às quais a lógica pode aceitar silenciosamente uma assinatura inválida. O LLM apontou a variável de status decoded como suspeita e chamou a atenção para sua inicialização. Seguindo esse sinal, pedi para rastrear o fluxo de controle quando nenhum segredo dá uma assinatura correspondente. Isso confirmou o bug: um erro de inicialização da variável booleana let decoded = true em vez de let decoded = false significava que, ao usar a rotação de segredos, a verificação da assinatura não poderia falhar. O CVE ainda está aguardando publicação. harden-runner Análise detalhada: Bypassing Outbound Connections Detection in harden-runner harden-runner é uma ferramenta de segurança da StepSecurity para GitHub Actions. Ele monitora as conexões de rede de saída dos runners CI/CD por meio de chamadas de sistema de instrumentação e detecta egress não autorizado. Funciona em dois modos: o modo de auditoria registra as conexões, o modo de bloqueio as impede ativamente. Examinei os boletins anteriores do harden-runner e seu modelo de segurança documentado. Todo o valor da ferramenta depende da visibilidade total da atividade de rede de saída, portanto, o modelo de ameaças que pedi ao LLM para gerar se resumiu a uma pergunta: "Um invasor com a capacidade de executar código no GitHub Actions runner pode gerar dados contornando os controles de egress?". O LLM apontou lacunas na cobertura de chamadas de sistema como a classe mais provável de desvio: a ferramenta depende da interceptação de chamadas de sistema específicas, e qualquer chamada fora desse conjunto permanecerá invisível. Com esse modelo de ameaças, direcionei o LLM para a camada de monitoramento de chamadas de sistema e pedi para investigar a superfície de cobertura. Quais famílias de chamadas de sistema são interceptadas, de que maneiras um processo no Linux pode enviar dados pela rede e há uma lacuna entre um e outro? A ideia era que o LLM listasse o conjunto completo de chamadas de sistema de rede e, em seguida, o comparasse com o que o harden-runner realmente instrumenta. O LLM voltou com uma análise de lacunas, onde as chamadas de sistema da família UDP send foram marcadas como potencialmente não cobertas pelo monitoramento. E pedi para verificar especificamente se sendto, sendmsg e sendmmsg estão cobertos. O desvio acabou sendo exatamente como o modelo de ameaças previu: essas chamadas de sistema caíram da área de monitoramento no modo de auditoria (CVE-2026-25598). BullFrog Análises detalhadas: Bypassing egress filtering in BullFrog GitHub Action , sudo restriction bypass in BullFrog GitHub Action , Bypassing egress filtering in BullFrog using shared IP BullFrog é outra ferramenta de segurança para GitHub Actions que aplica filtragem de egress no nível do firewall com regras com reconhecimento de DNS. Ao contrário da abordagem harden-runner com chamadas de sistema de instrumentação, o BullFrog funciona no nível da rede: resolve nomes de domínio em endereços IP e aplica regras de firewall com base nessas resoluções. Novamente, segui o mesmo caminho. Examinei a documentação do BullFrog e o modelo de segurança, depois pedi ao LLM para gerar um modelo de ameaças com base na abordagem arquitetônica. A pergunta geral foi a mesma que para o harden-runner: "Um invasor com execução de código no GitHub Actions runner pode gerar dados contornando os controles de egress?". Mas o LLM destacou um conjunto diferente de classes plausíveis de desvio, porque o mecanismo de aplicação do BullFrog é fundamentalmente diferente. O modelo de ameaças observou casos limite de análise de DNS, a lógica de vinculação de IP ao domínio e a elevação de privilégios como as três superfícies de ataque mais prováveis. Dividi a auditoria em três seções separadas, cada uma com sua própria pesquisa direcionada. Para a seção DNS, direcionei o LLM para a camada de análise de DNS e pedi para examinar como o agente lida com o tráfego DNS no nível do protocolo, quais suposições ele faz sobre os limites das mensagens e o que acontece com casos limite como mensagens multiplexadas ou canalizadas. Para a seção IP, pedi ao LLM para examinar como as regras de firewall são construídas após a resolução de DNS, se a conexão entre o domínio e seus IPs resolvidos é rastreada e o que acontece quando vários domínios são resolvidos em um endereço. Para a seção de privilégios, pedi ao LLM para descobrir como a ferramenta restringe a elevação de privilégios no runner e se existem caminhos alternativos para acesso elevado além daqueles que ela bloqueia explicitamente. O LLM levantou superfícies de ataque específicas para cada seção: o analisador de DNS verificou apenas a primeira mensagem no segmento TCP, o firewall adicionou o IP à lista de permissões sem vinculá-lo ao domínio que causou essa regra, e a associação ao grupo Docker foi preservada após a remoção do usuário do sudoers. Solicitações de esclarecimento em cada um desses itens confirmaram três desvios separados. Better-Hub Análise detalhada: Hacking Better-Hub Better-Hub é um front-end alternativo para o GitHub que espelha o conteúdo do GitHub dentro de sua própria origem, renderiza Markdown em HTML e armazena tokens OAuth do GitHub para funções autenticadas. Aqui, o modelo de ameaças não surgiu tanto de CVEs anteriores, que não existiam, mas da própria arquitetura. Quando descrevi o design do Better-Hub para o LLM, especialmente o fato de que o conteúdo do GitHub controlado pelo usuário é renderizado dentro da própria origem do Better-Hub, onde os tokens OAuth estão disponíveis no mesmo contexto, o modelo de ameaças surgiu por conta própria: "O que acontece se o conteúdo controlado pelo usuário for renderizado de forma insegura em um contexto que tenha acesso às credenciais armazenadas?". O LLM destacou três áreas de alto risco: o pipeline de renderização Markdown, a camada de cache e autorização, bem como a lógica de processamento de tokens OAuth. Auditei cada um deles como uma seção separada - por meio de pesquisa direcionada, em vez de caçar uma vulnerabilidade específica. Para a seção de renderização, direcionei o LLM para o pipeline de processamento Markdown e pedi para examinar o fluxo de dados: como o conteúdo bruto dos repositórios do GitHub é transformado antes de entrar no navegador, quais etapas de sanitização existem e onde a entrada não confiável pode sobreviver no pipeline. Para a seção de cache, pedi ao LLM para ver como as respostas são armazenadas em cache e entregues, se a camada de cache está ciente do contexto de autenticação e o que acontece quando uma resposta em cache de um repositório privado é solicitada por outro usuário. Para a seção OAuth, pedi para examinar como os tokens são armazenados e pontuados, se eles estão disponíveis no contexto do cliente e como é o ciclo de vida dos tokens. Cada seção trouxe descobertas separadas, correspondendo exatamente às superfícies de ataque definidas pelo LLM. O pipeline de renderização forneceu seis variantes de XSS, todas do mesmo caminho de renderização Markdown sem sanitização. A seção de cache revelou dois desvios de autorização baseados em cache, nos quais o conteúdo de repositórios privados vazava para usuários não autenticados. Outras descobertas incluíram vazamento de dados de prompt privado, divulgação de token OAuth no lado do cliente e redirecionamento aberto. Um total de onze vulnerabilidades em três seções. Vulnerabilidades encontradas Observação: esta é apenas uma pequena parte das vulnerabilidades que encontrei usando a metodologia deste artigo; muitas ainda aguardam correção ou divulgação. Objetivo Vulnerabilidades Faixa de gravidade de bugs CVE Parse Server 4 Crítico - Moderado CVE-2026-29182, CVE-2026-30228, CVE-2026-30229, CVE-2026-30863 HonoJS 2 Alto CVE-2026-22817, CVE-2026-22818 ElysiaJS 1 Alto Pendente (desvio de assinatura de cookie) harden-runner 1 Moderado CVE-2026-25598 BullFrog 3 Alto DNS pipelining, desvio sudo, desvio de IP compartilhado Better-Hub 11 Crítico - Baixo Cadeia XSS, decepção de cache, vazamento OAuth Por que funcionou Em nenhuma dessas auditorias foi usada uma lista de verificação gigante, uma estrutura de prompt de vinte páginas ou uma estrutura de segurança "abrangente". Cada um começou com um curto modelo de ameaças, geralmente contido em uma frase, e uma seção focada da base de código que correspondia diretamente a um limite de confiança ou a uma operação de segurança crítica. A estrutura era mínima, mas era a estrutura certa. Ele apontou o LLM exatamente para qual regra de segurança verificar e onde procurar. O meio termo Uma boa estrutura é um modelo de ameaças de uma página, uma curta lista de funções críticas do sistema e um pequeno conjunto de condições verificáveis, como "apenas os administradores têm o direito de chamar X" e "o emissor JWT deve ser igual a Y". Uma estrutura ruim é um Agent.md de vinte páginas com todas as políticas e guias de estilo, uma enorme biblioteca Skill.md que carrega previamente cada lista de verificação de segurança e a repetição das mesmas instruções de modelo em cada etapa. Se sua estrutura se transformar em um palheiro, a vulnerabilidade se transformará em uma agulha - e os dados sobre o trabalho de modelos com contexto longo mostram que as agulhas são perdidas com mais frequência quanto maior o palheiro. Divida a auditoria em seções finas correspondentes às superfícies de ataque reais. Selecione uma seção: autenticação, gerenciamento de sessão, análise de solicitação, upload de arquivos, desserialização, limite de sandbox ou limite de plugin.