Vaccari's Code

SQLite: CVEs Críticas ou Erro de LLM?

8/4/2026

Nos últimos dias, a comunidade de segurança da informação foi sacudida por uma série de alertas sobre vulnerabilidades críticas no SQLite – a espinha dorsal de inúmeros softwares e dispositivos. Um repositório recém-criado no GitHub (programmervuln/cveadvisory-) publicou dezenas de avisos de CVEs (Common Vulnerabilities and Exposures, uma lista de vulnerabilidades de segurança de software publicamente conhecidas), muitos deles com pontuações de severidade altíssimas. O NVD (National Vulnerability Database, um repositório do governo dos EUA de dados de vulnerabilidades) rapidamente classificou-os como críticos, e o ADP da CISA (o programa de divulgação de vulnerabilidades da agência de segurança cibernética dos EUA) concordou.

O cenário era alarmante. Mas, como um bom engenheiro sabe, nem tudo que brilha é ouro, e nem todo alerta é real. Pesquisadores de segurança da JFrog decidiram investigar a fundo, e o que encontraram foi, no mínimo, preocupante: a maioria das alegações parecia ser "slop de LLM" – ou seja, conteúdo gerado por modelos de linguagem grandes, como o ChatGPT, sem qualquer base na realidade.

O Alarme Falso e a Dúvida Inicial

A desconfiança começou a surgir quando a JFrog notou que esses CVEs não estavam listados na página oficial de avisos do SQLite, que é um padrão ouro para o rastreamento de vulnerabilidades reais. Além disso, ao testar os PoCs (Proof of Concept, um código que demonstra a vulnerabilidade), eles simplesmente não funcionavam, não provocando nenhum crash ou comportamento inesperado. Para completar, ferramentas como o Gptzero detectaram que os avisos do repositório pareciam ser gerados por IA.

Um exemplo notável foi o CVE-2026-51302. Inicialmente, a Red Hat atribuiu a ele uma pontuação de severidade crítica de 10.0. No dia seguinte, essa pontuação já havia sido rebaixada para 7.6 (Alta). Essa volatilidade já era um sinal de alerta.

A facilidade com que esses avisos foram aceitos por instituições de renome destaca uma falha no processo de submissão de CVEs via formulário público do MITRE, que carece de qualquer verificação de identidade real. Isso significa que praticamente qualquer pessoa pode enviar uma descrição de vulnerabilidade e propor uma pontuação CVSS, com o risco de criar pânico e gastar recursos valiosos em investigações desnecessárias.

O Processo de Desmistificação: Como Verificar a Verdade

Para verificar a fundo cada um desses relatórios, a equipe da JFrog estabeleceu um fluxo de trabalho de teste isolado e rigoroso, um modelo que todo builder e líder técnico deveria adotar ao lidar com avisos de segurança:

  1. Inspeção do Código-Fonte: Eles clonaram o repositório oficial do SQLite (sqlite/sqlite) e verificaram as tags das versões-alvo (3.41.0, 3.51.2 e 3.51.3). As mecânicas de vulnerabilidade reportadas foram comparadas diretamente com o código-fonte real.
  2. Construção em Ambiente Limpo: As releases oficiais do SQLite foram compiladas dentro de containers Docker isolados, prevenindo qualquer contaminação ambiental que pudesse mascarar ou criar falsos positivos.
  3. Execução do PoC: As declarações SQL dos PoCs de cada aviso foram inseridas verbatim nos binários do SQLite compilados, sob instrumentação do AddressSanitizer (ASan), uma ferramenta de detecção de erros de memória. Isso permite identificar bugs de memória, como o Use-After-Free (UAF), com alta precisão.
  4. Auditoria de NVD e Metadados: Os padrões CPE (Common Platform Enumeration, um esquema de nomenclatura padronizado para sistemas de software) e os metadados dos avisos foram avaliados através dos feeds NVD e GHSA (GitHub Security Advisories) para verificar a precisão do rastreamento.

Exemplos Clássicos de Fabricação por IA

Os resultados dessa investigação foram claros: as alegações simplesmente não se sustentavam. Vejamos alguns exemplos dos "achados" da JFrog:

  • Vulnerabilidade Reportada: Um UAF (Use-After-Free, um tipo de vulnerabilidade de memória onde um programa tenta usar memória que já foi liberada) ocorreria quando sqlite3ReleaseTempReg() deixasse um ponteiro pendente (dangling pointer) em regFree1, que seria posteriormente desreferenciado por exprComputeOperands().
    • Achado Real: A função exprComputeOperands() não existia no SQLite 3.41.0; foi adicionada apenas em meados de 2025. Além disso, a mecânica de sqlite3ReleaseTempReg() não envolve desalocação de heap (uma área da memória do computador usada para alocação dinâmica); ela apenas recicla índices de registro, tornando um UAF impossível por design. O PoC rodou sem crash.
  • Vulnerabilidade Reportada: ExprListDelete() falharia ao limpar referências inversas em estruturas pai ao liberar nós filhos, supostamente corrigido na versão 3.51.3.
    • Achado Real: Não há evidência de ponteiros de referência inversa nas estruturas Expr, Select ou Window que pudessem levar a tal estado. Mais revelador, um diff entre 3.51.2 e 3.51.3 mostrou nenhuma alteração em src/expr.c. O "patch" foi completamente fabricado. O PoC era um SQL inválido e falhou na fase de parsing.
  • Vulnerabilidade Reportada: jsonParseFree() deixaria referências pendentes que seriam acessadas posteriormente por jsonBlobEdit().
    • Achado Real: Similar ao primeiro caso, jsonBlobEdit() não estava presente na versão 3.41.0. Ela foi introduzida posteriormente como parte da implementação do JSONB. Na versão-alvo, jsonParseFree() é usada estritamente em destrutores onde a estrutura envolvente é descartada imediatamente. O PoC falhou imediatamente com um erro de JSON malformado.
  • Vulnerabilidade Reportada: Um UAF em jsonRemoveFunc, especificamente nas linhas 3555 e 3575 de json.c.
    • Achado Real: Na versão 3.41.0, src/json.c tem apenas 2706 linhas de comprimento. Os números de linha citados simplesmente não existem. A implementação real da função foi encontrada cerca de 2000 linhas antes, e uma auditoria desse código não mostrou falhas de gerenciamento de memória.

Por Que Isso Importa para Você

Este episódio com as falsas CVEs do SQLite é um lembrete contundente em nossa era de IA:

  1. A ascensão do "Slop de LLM": Modelos de linguagem, embora poderosos, podem gerar informações plausíveis, mas completamente falsas. No contexto da segurança, isso pode levar a falsos positivos caros, desperdiçando tempo e recursos de equipes de segurança e desenvolvimento.
  2. A necessidade de verificação independente: Confiar cegamente em avisos de fontes não verificadas ou em processos de submissão falhos é perigoso. É crucial que builders e líderes técnicos desenvolvam e sigam seus próprios processos de validação rigorosos, como o da JFrog.
  3. O valor do conhecimento técnico profundo: A capacidade de mergulhar no código-fonte, entender a lógica subjacente e depurar com ferramentas como ASan é insubstituível. Essa é a base para distinguir a realidade da ficção, especialmente quando a IA começa a borrar as linhas.
  4. Impacto na confiança: A proliferação de avisos falsos pode erodir a confiança em sistemas legítimos de alerta de vulnerabilidades, tornando mais difícil para as equipes reagir quando uma ameaça real surgir.

Em um mundo onde a informação é abundante e, por vezes, fabricada, a vigilância, o ceticismo saudável e o compromisso com a verdade técnica são mais importantes do que nunca. Não confie apenas no que você lê; verifique.

Fontes

📬 Gostou? Assine a newsletter do Vaccari's Code e receba as próximas tendências em software e IA direto no seu e-mail: Assinar aqui

← todos os posts · ouça o episódio →