IA Inventou Bugs no SQLite e o MITRE Deu CVEs Críticas para Todos

Imagine receber um alerta de segurança crítico. Você para tudo, reúne o time, começa a investigar. O bug é grave: corrupção de memória, execução remota de código. Aí, depois de horas analisando, descobre que a função mencionada no relatório simplesmente não existe no código-fonte. Nem existiu. O número da linha referenciado ultrapassa o tamanho do arquivo. O exploit de prova de conceito não faz absolutamente nada.

Isso aconteceu com o SQLite na última semana. E não foi um caso isolado: foram pelo menos nove CVEs registradas de uma vez, todas fabricadas por uma IA, todas aceitas pelo MITRE sem questionamento.

O que aconteceu exatamente

No dia 29 de julho de 2026, Richard Hipp, criador do SQLite, começou a receber e-mails de analistas de segurança perguntando sobre vulnerabilidades críticas recém-publicadas. Os CVEs iam do CVE-2026-51296 ao CVE-2026-51304, todos reportados por uma conta do GitHub chamada programmervuln/cveadvisory-.

O problema? Nenhuma dessas vulnerabilidades era real.

A equipe do JFrog Security foi uma das primeiras a investigar a fundo. O que encontraram foi surreal: os relatórios mencionavam funções que nunca existiram no código do SQLite, como exprComputeOperands(). Referenciavam linhas de código impossíveis, tipo a linha 3.555 de um arquivo que tem apenas 2.706 linhas. Os exploits de prova de conceito fornecidos não provocavam nenhum crash, nenhum comportamento anômalo, nada.

Quando o JFrog passou o texto combinado dos advisories por detectores de conteúdo gerado por IA, o resultado foi claro: tudo apontava para texto produzido por um modelo de linguagem.

Para deixar mais concreto, olha o nível de detalhe falso que esses relatórios continham:

// Função citada no CVE-2026-51302:
void exprComputeOperands(Expr *pExpr, int nOp) {
    // Esta função NÃO EXISTE no código do SQLite.
    // Nunca existiu. Em nenhuma versão.
    // O relatório cita ela como se fosse óbvia.
}

O advisory descrevia em linguagem técnica impecável como essa função alocava memória de forma insegura, causando um use-after-free explorável remotamente. O texto era convincente o suficiente para que analistas de segurança experientes o tratassem como legítimo antes de verificar o código-fonte.

Eu já vi relatórios de bugs ruins. Já vi pesquisadores exagerando impacto. Mas fabricar uma função inteira, com um fluxo de exploit detalhado, citando linhas de código que matematicamente não podem existir? Isso é um nível novo.

Como funciona o sistema de CVEs (e por que ele quebrou)

Para entender a gravidade do problema, precisa entender como o sistema CVE funciona. Ou melhor, como ele deveria funcionar.

O programa CVE (Common Vulnerabilities and Exposures) é mantido pelo MITRE com financiamento do governo americano. Ele serve como o registro central de vulnerabilidades de segurança conhecidas. Quando alguém descobre um bug de segurança, pode solicitar um identificador CVE, que depois é indexado pelo NVD (National Vulnerability Database) do NIST, recebe uma pontuação CVSS de severidade, e entra nos scanners de segurança que empresas do mundo inteiro usam.

O fluxo deveria ser: alguém descobre uma vulnerabilidade real, reporta ao mantenedor do software, o mantenedor confirma, e então um CVE é emitido. Na prática, o MITRE aceita submissões de praticamente qualquer pessoa, sem exigir prova de conceito funcional, sem confirmação do mantenedor, sem verificação técnica.

Richard Hipp resumiu a situação com uma frase que viralizou no fórum do SQLite:

“MITRE apparently takes a CVE from anybody at any time, without any kind of validation. But boy do they require validation to get one taken down!”

Traduzindo: criar um CVE falso é fácil. Remover é uma batalha burocrática.

O que acontece quando CVEs falsas entram no sistema

O estrago vai muito além de um incômodo para os mantenedores do SQLite. Pense na cadeia de consequências:

O SQLite roda em literalmente bilhões de dispositivos. Está dentro do Android, iOS, Chrome, Firefox, Python, PHP e praticamente todo sistema embarcado que existe. Um CVE crítico falso no SQLite gera um efeito cascata absurdo.

E o pior: empresas que usam IA para triagem automatizada de vulnerabilidades podem tentar aplicar patches para bugs que não existem, potencialmente introduzindo problemas reais no código ao tentar “consertar” algo que nunca esteve quebrado.

A posição oficial do SQLite sobre CVEs

A página oficial do SQLite sobre CVEs é uma das leituras mais ácidas que você vai encontrar em documentação técnica. Os desenvolvedores são diretos: eles não escrevem CVEs, não rastreiam CVEs e não reconhecem o sistema como confiável.

Os argumentos deles:

1. Incentivos perversos: hackers grey-hat são recompensados pela quantidade e severidade dos CVEs que produzem, gerando uma enxurrada de relatórios exagerados ou inventados
2. Controle de qualidade inexistente: o processo de revisão do MITRE não consegue lidar com o volume de submissões
3. Falta de editorial: os mantenedores do software não têm poder de editar ou contestar eficientemente o conteúdo dos CVEs

A recomendação oficial deles agora é simples: “Se você vir novos CVEs contra o SQLite, provavelmente pode assumir que são falsos.”

Forte, né? Mas quando você olha a lista de CVEs que eles catalogaram como problemáticos, fica difícil discordar. Além das alucinações de IA (CVE-2026-51296 até 51304), existem CVEs que na verdade são bugs em aplicações de terceiros usando SQLite (como o CVE-2023-39939, que é SQL injection no LuxCal Web Calendar), bugs em drivers JDBC que não têm nenhuma relação com o projeto SQLite (CVE-2023-32697), e vulnerabilidades em ferramentas de linha de comando que não afetam a biblioteca core.

A SuSE usou IA para desmascarar IA

Tem uma ironia deliciosa nessa história: a SuSE, distribuidora Linux, usou o Claude (modelo da Anthropic) para analisar os CVEs suspeitos. O Claude concluiu que as vulnerabilidades eram “fabricadas”.

Então estamos num ponto onde:

• Uma IA gera vulnerabilidades falsas
• Humanos registram no sistema oficial
• Outra IA é usada para verificar que são falsas
• Humanos precisam lutar com burocracia para remover

IA gera CVE falso → MITRE aceita → Scanner alerta →
Time investiga → Usa IA para verificar → Confirma que é falso →
Tenta remover do MITRE → Burocracia infinita → Repita

Parece um sketch de comédia, mas é a realidade da infraestrutura de segurança global em 2026.

Não é só o SQLite: curl, Rust e Linux já sofreram

O SQLite não está sozinho. Projetos como curl, Rust e o kernel Linux enfrentaram problemas similares com relatórios de vulnerabilidade gerados por IA ou de baixa qualidade.

Daniel Stenberg, criador do curl, já havia se manifestado em 2024 sobre o volume crescente de relatórios de bugs gerados por IA que sua equipe recebia. Reports que pareciam detalhados e técnicos à primeira vista, mas que desmoronavam em segundos quando alguém com conhecimento real do código-fonte olhava com atenção.

A resposta desses projetos foi se tornar CNAs (CVE Numbering Authorities). Quando um projeto é CNA, ele tem autonomia para emitir (e rejeitar) CVEs relacionados ao seu próprio software, eliminando o intermediário problemático que é o MITRE aceitando submissões sem validação.

O curl virou CNA em 2024. O Rust em 2025. O kernel Linux em 2026. O SQLite, até o momento desta publicação, ainda não deu esse passo. Talvez agora tenha motivo suficiente.

A timeline mostra uma tendência clara: quanto maior e mais visível o projeto, mais cedo ele precisa assumir controle sobre seus próprios CVEs. E o SQLite, que está embutido em mais dispositivos do que qualquer outro software do planeta, é talvez o candidato mais óbvio a CNA que ainda não é um.

O problema de fundo: grey-hat economics

Por que alguém fabricaria CVEs? Existem duas motivações principais:

1. Bug bounties e reputação

Plataformas de bug bounty e programas de recompensa avaliam pesquisadores, entre outros critérios, pelo número e severidade dos CVEs associados ao seu nome. Um CVE crítico no SQLite é um item de peso no currículo de qualquer pesquisador de segurança.

2. Automação sem supervisão

Com o acesso a modelos de linguagem cada vez mais baratos, é trivial gerar centenas de relatórios de vulnerabilidade que parecem legítimos. O custo de submissão é zero (MITRE não cobra e não verifica identidade robustamente), enquanto o custo de refutação recai inteiramente sobre os mantenedores do projeto alvo.

Essa assimetria é o cerne do problema. Fabricar um CVE custa minutos de prompt engineering. Refutar leva horas de análise técnica por pessoas que já estão sobrecarregadas mantendo software que bilhões de pessoas usam de graça.

É o mesmo padrão que vemos em spam, phishing e desinformação: o atacante tem vantagem de escala, e o defensor paga o custo unitário mais alto. Só que aqui o “spam” entra num banco de dados oficial que alimenta a infraestrutura de segurança de todas as empresas do Fortune 500.

E não pense que isso é um problema de nicho. Se alguém pode fabricar CVEs para o SQLite, pode fabricar para o OpenSSL, para o PostgreSQL, para o Node.js. Qualquer projeto que não seja seu próprio CNA está vulnerável a esse tipo de ataque de reputação automatizado.

Como se proteger na prática

Se você mantém projetos open source ou trabalha com segurança, aqui vão algumas recomendações concretas:

Para mantenedores de projetos

• Considere virar CNA: isso dá ao seu projeto controle sobre os CVEs emitidos em seu nome
• Documente publicamente sua posição: como o SQLite fez, mantenha uma página oficial sobre CVEs, explicando quais são válidos e quais não
• Automatize a verificação: use modelos de IA para fazer triagem inicial de relatórios de bugs (a ironia é real, mas funciona)

Para times de segurança corporativos

• Não confie cegamente em scanners: um CVE com score 9.8 pode ser completamente fabricado
• Verifique a fonte: cheque se o mantenedor do projeto confirmou a vulnerabilidade
• Monitore CNAs: projetos que são seus próprios CNAs tendem a ter CVEs mais confiáveis

Para devs no dia a dia

• Leia o advisory antes de entrar em pânico: funções que não existem, linhas impossíveis e PoCs que não funcionam são red flags óbvias
• Consulte o changelog do projeto: se o mantenedor não mencionou a correção, desconfie
• Use fontes primárias: a página de segurança do próprio projeto vale mais que agregadores de CVEs

O que precisa mudar no sistema CVE

O sistema CVE foi criado em 1999, numa época em que a web comercial estava engatinhando e a ideia de alguém usar IA para fabricar relatórios de vulnerabilidade era ficção científica. Quase três décadas depois, a infraestrutura não acompanhou.

Algumas mudanças que a comunidade de segurança vem discutindo:

1. Verificação de identidade obrigatória para quem submete CVEs
2. Prova de conceito funcional como pré-requisito, não item opcional
3. Confirmação do mantenedor antes da publicação no NVD
4. Processo expedito de remoção para CVEs contestados
5. Detecção de conteúdo gerado por IA nos advisories submetidos

O NIST já reduziu a validação manual de CVEs em fevereiro de 2024, piorando o problema. A infraestrutura está claramente subdimensionada para o volume atual de submissões, e a IA só vai aumentar esse volume.

O SQLite vai sobreviver (o sistema CVE talvez não)

O SQLite é um dos projetos de software mais resilientes da história. São mais de 23 anos de desenvolvimento, com uma suíte de testes que tem 100% de branch coverage e usa centenas de milhões de casos de teste. Umas CVEs falsas não vão derrubar o projeto.

Mas o sistema CVE como conhecemos está sob pressão real. Se os identificadores que deveriam representar vulnerabilidades verificadas podem ser criados por qualquer pessoa com acesso a um chatbot, o que exatamente eles significam? Quando um score CVSS 9.8 pode ser tanto um zero-day devastador quanto uma alucinação de uma IA, a confiança no sistema inteiro se erode.

A comunidade de segurança precisa decidir: ou reforma o CVE para a era da IA generativa, ou assiste o sistema perder relevância enquanto cada projeto grande cria seu próprio canal de advisories.

O Richard Hipp já deu sua resposta. A dele é: ignore o sistema.

Concordando ou não, é difícil argumentar que ele está errado.

—

Fonte de inspiração: Critical CVE issued for hallucinated SQLite vulnerability (JFrog Security Research) e discussão no fórum oficial do SQLite