Inteligência Artificial Pode Corrigir Vulnerabilidade Que Ajudou a se Espalhar por 15 Anos
Uma vulnerabilidade de path traversal, disseminada por meio de trechos de código inseguros em plataformas como Stack Overflow, pode ser corrigida por ferramentas de IA. Pesquisadores descobriram que modelos de linguagem como GPT-3.5 e Copilot frequentemente reproduzem essa falha, mas também podem ser usados para gerar patches eficazes.
MundiX News·13 de abril de 2026·7 min de leitura·👁 4 views
Inteligência Artificial Pode Corrigir Vulnerabilidade Que Ajudou a se Espalhar por 15 Anos
Uma ferramenta de inteligência artificial pode ajudar a eliminar um bug que inadvertidamente persistiu por uma década.
Em 2010, um desenvolvedor publicou um pequeno trecho de código como um GitHub Gist, demonstrando como criar um servidor de arquivos estáticos em Node.js. Ele incluía uma sutil vulnerabilidade de path traversal, permitindo que atacantes navegassem para fora do diretório especificado. Com o tempo, o padrão inseguro se espalhou por meio de respostas do Stack Overflow, postagens de blog, tutoriais universitários e até mesmo repositórios de produção de grandes empresas.
Ao longo dos anos, tornou-se tão enraizado na cultura dos desenvolvedores que entrou nos dados de treinamento dos modelos de IA atuais.
"Não temos 100% de certeza de que o Gist de 2010 é a fonte original, mas é a instância mais antiga que podemos rastrear", disse Jafar Akhoundali, candidato a doutorado na Universidade de Leiden e principal autor de um artigo pré-publicado que analisa o problema. "É provável que o trecho de código tenha se espalhado porque resolvia um problema comum – servir conteúdo estático – e podia ser facilmente reutilizado com copiar e colar."
Tutoriais e plataformas como o Stack Overflow provavelmente foram os principais contribuintes para a disseminação, pois são mais visíveis, confiáveis por desenvolvedores que buscam soluções rápidas e projetados para a reutilização de código. A cópia e colagem direta entre projetos é menos frequente, pois geralmente requer mais contexto e esforço para extrair código reutilizável da lógica de negócios, disse Akhoundali.
Para medir a profundidade com que essa vulnerabilidade se enraizou, Akhoundali e sua equipe pediram a grandes modelos de linguagem, incluindo GPT-3.5, GPT-4, Claude, Gemini e Copilot, para escrever código para um servidor de arquivos estáticos. Eles testaram prompts gerais e prompts que solicitavam explicitamente código seguro. Mesmo com instruções para priorizar a segurança, 70% das respostas continham lógica vulnerável. GPT-3.5 e Copilot no modo balanceado não conseguiram gerar código seguro em nenhum cenário de teste.
"Muitos LLMs são treinados em grandes bases de código público, como o GitHub", disse Akhoundali. Se os dados incluem padrões inseguros, os modelos inevitavelmente os reproduzirão, disse ele.
Este é um caso de "lixo entra, lixo sai", disse ele. "Não podemos simplesmente esperar que os modelos se comportem melhor quando os próprios dados carecem de qualidade... Nem os humanos nem a IA são os culpados", disse ele. Uma solução potencial para esses problemas são modelos de autoaperfeiçoamento que podem propor hipóteses, experimentar e raciocinar, em vez de apenas depender de dados não confiáveis disponíveis na internet, como agentes de IA.
Os pesquisadores não encontraram nenhuma diferença significativa na reprodução de vulnerabilidades entre os fornecedores de modelos como OpenAI, Gemini e Claude. A equipe também construiu um sistema para corrigi-lo. Ele escaneia repositórios públicos do GitHub em busca de padrões de vulnerabilidade de path traversal e tenta confirmar a explorabilidade usando testes em sandbox. Se bem-sucedido, a ferramenta usa o GPT-4 para gerar um patch. Ele evita falsos positivos, verificando se o código vulnerável pode ser acionado na prática, ao contrário da análise estática pura.
Projetar a etapa de patch provou ser tecnicamente desafiador. As primeiras tentativas pediam ao modelo para reescrever o arquivo inteiro, resultando em erros de sintaxe e alterações inesperadas. Mais tarde, a equipe melhorou sua abordagem anexando números de linha e solicitando diferenças. Mesmo assim, garantir a correção do patch exigia heurísticas e verificações processuais adicionais.
"Existem muitos programas, cada um exigindo diferentes funcionalidades e lógicas. Mesmo com testes personalizados para cada programa, ainda não é possível cobrir todos os casos extremos, o que exige uma verificação final pelos mantenedores", disse Akhoundali.
De uma varredura inicial de 40.546 repositórios, a ferramenta verificou que 1.756 tinham falhas de path traversal exploráveis. Ele gerou 1.600 patches válidos. Apenas 63 projetos aceitaram as correções.
Akhoundali atribui a baixa taxa de aceitação a vários fatores. Alguns repositórios foram abandonados, outros usavam o código apenas em ambientes de teste ou desenvolvimento e, em alguns casos, eles não conseguiram obter um canal seguro para alcançar os mantenedores.
Para evitar atores maliciosos, a equipe ocultou os detalhes técnicos completos. Eles entraram em contato por canais privados sempre que possível. "Tentamos equilibrar os benefícios de notificar a comunidade sobre a vulnerabilidade com o risco de que um potencial invasor a encontrasse e a explorasse", disse Akhoundali.
A pesquisa da equipe se concentrou em vulnerabilidades de path traversal em projetos JavaScript, mas o pipeline é extensível. Em princípio, o método pode ser aplicado a outras classes de vulnerabilidades e até mesmo a outras linguagens de programação, disse ele.
Quanto ao papel dos fornecedores de IA, Akhoundali acredita que o treinamento padrão e o alinhamento do modelo podem ajudar. Mas isso seria desafiador, disse ele. Na maioria das vezes, o código seguro significa código mais complexo. Todos os desenvolvedores vão querer isso, ou eles estão apenas interessados na funcionalidade? E quanto ao desempenho – às vezes, executar código seguro o torna muito mais lento e requer várias verificações, disse ele.
A escolha de design final depende dos desenvolvedores, mas os fornecedores desempenham um papel fundamental de capacitação. As escolhas de design e as prioridades variam entre diferentes desenvolvedores e empresas", disse ele.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Inteligência Artificial Pode Corrigir Vulnerabilidade Que Ajudou a se Espalhar por 15 Anos
Uma ferramenta de inteligência artificial pode ajudar a eliminar um bug que inadvertidamente persistiu por uma década.
Em 2010, um desenvolvedor publicou um pequeno trecho de código como um GitHub Gist, demonstrando como criar um servidor de arquivos estáticos em Node.js. Ele incluía uma sutil vulnerabilidade de path traversal, permitindo que atacantes navegassem para fora do diretório especificado. Com o tempo, o padrão inseguro se espalhou por meio de respostas do Stack Overflow, postagens de blog, tutoriais universitários e até mesmo repositórios de produção de grandes empresas.
Ao longo dos anos, tornou-se tão enraizado na cultura dos desenvolvedores que entrou nos dados de treinamento dos modelos de IA atuais.
"Não temos 100% de certeza de que o Gist de 2010 é a fonte original, mas é a instância mais antiga que podemos rastrear", disse Jafar Akhoundali, candidato a doutorado na Universidade de Leiden e principal autor de um artigo pré-publicado que analisa o problema. "É provável que o trecho de código tenha se espalhado porque resolvia um problema comum – servir conteúdo estático – e podia ser facilmente reutilizado com copiar e colar."
Tutoriais e plataformas como o Stack Overflow provavelmente foram os principais contribuintes para a disseminação, pois são mais visíveis, confiáveis por desenvolvedores que buscam soluções rápidas e projetados para a reutilização de código. A cópia e colagem direta entre projetos é menos frequente, pois geralmente requer mais contexto e esforço para extrair código reutilizável da lógica de negócios, disse Akhoundali.
Para medir a profundidade com que essa vulnerabilidade se enraizou, Akhoundali e sua equipe pediram a grandes modelos de linguagem, incluindo GPT-3.5, GPT-4, Claude, Gemini e Copilot, para escrever código para um servidor de arquivos estáticos. Eles testaram prompts gerais e prompts que solicitavam explicitamente código seguro. Mesmo com instruções para priorizar a segurança, 70% das respostas continham lógica vulnerável. GPT-3.5 e Copilot no modo balanceado não conseguiram gerar código seguro em nenhum cenário de teste.
"Muitos LLMs são treinados em grandes bases de código público, como o GitHub", disse Akhoundali. Se os dados incluem padrões inseguros, os modelos inevitavelmente os reproduzirão, disse ele.
Este é um caso de "lixo entra, lixo sai", disse ele. "Não podemos simplesmente esperar que os modelos se comportem melhor quando os próprios dados carecem de qualidade... Nem os humanos nem a IA são os culpados", disse ele. Uma solução potencial para esses problemas são modelos de autoaperfeiçoamento que podem propor hipóteses, experimentar e raciocinar, em vez de apenas depender de dados não confiáveis disponíveis na internet, como agentes de IA.
Os pesquisadores não encontraram nenhuma diferença significativa na reprodução de vulnerabilidades entre os fornecedores de modelos como OpenAI, Gemini e Claude. A equipe também construiu um sistema para corrigi-lo. Ele escaneia repositórios públicos do GitHub em busca de padrões de vulnerabilidade de path traversal e tenta confirmar a explorabilidade usando testes em sandbox. Se bem-sucedido, a ferramenta usa o GPT-4 para gerar um patch. Ele evita falsos positivos, verificando se o código vulnerável pode ser acionado na prática, ao contrário da análise estática pura.
Projetar a etapa de patch provou ser tecnicamente desafiador. As primeiras tentativas pediam ao modelo para reescrever o arquivo inteiro, resultando em erros de sintaxe e alterações inesperadas. Mais tarde, a equipe melhorou sua abordagem anexando números de linha e solicitando diferenças. Mesmo assim, garantir a correção do patch exigia heurísticas e verificações processuais adicionais.
"Existem muitos programas, cada um exigindo diferentes funcionalidades e lógicas. Mesmo com testes personalizados para cada programa, ainda não é possível cobrir todos os casos extremos, o que exige uma verificação final pelos mantenedores", disse Akhoundali.
De uma varredura inicial de 40.546 repositórios, a ferramenta verificou que 1.756 tinham falhas de path traversal exploráveis. Ele gerou 1.600 patches válidos. Apenas 63 projetos aceitaram as correções.
Akhoundali atribui a baixa taxa de aceitação a vários fatores. Alguns repositórios foram abandonados, outros usavam o código apenas em ambientes de teste ou desenvolvimento e, em alguns casos, eles não conseguiram obter um canal seguro para alcançar os mantenedores.
Para evitar atores maliciosos, a equipe ocultou os detalhes técnicos completos. Eles entraram em contato por canais privados sempre que possível. "Tentamos equilibrar os benefícios de notificar a comunidade sobre a vulnerabilidade com o risco de que um potencial invasor a encontrasse e a explorasse", disse Akhoundali.
A pesquisa da equipe se concentrou em vulnerabilidades de path traversal em projetos JavaScript, mas o pipeline é extensível. Em princípio, o método pode ser aplicado a outras classes de vulnerabilidades e até mesmo a outras linguagens de programação, disse ele.
Quanto ao papel dos fornecedores de IA, Akhoundali acredita que o treinamento padrão e o alinhamento do modelo podem ajudar. Mas isso seria desafiador, disse ele. Na maioria das vezes, o código seguro significa código mais complexo. Todos os desenvolvedores vão querer isso, ou eles estão apenas interessados na funcionalidade? E quanto ao desempenho – às vezes, executar código seguro o torna muito mais lento e requer várias verificações, disse ele.
A escolha de design final depende dos desenvolvedores, mas os fornecedores desempenham um papel fundamental de capacitação. As escolhas de design e as prioridades variam entre diferentes desenvolvedores e empresas", disse ele.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
