Um conjunto de vulnerabilidades críticas atribuídas ao SQLite — o motor de base de dados presente em milhares de milhões de dispositivos e aplicações — revelou-se completamente fabricado. Segundo a equipa de investigação da JFrog, um repositório recente e obscuro do GitHub publicou 55 avisos de segurança em apenas quatro dias, dos quais 54 eram inventados, aparentemente gerados por modelos de linguagem (LLM). O caso é especialmente preocupante porque estes “CVE fantasma” chegaram a bases de dados de referência como a National Vulnerability Database (NVD), com enriquecimento da agência norte-americana CISA, expondo fragilidades estruturais na cadeia de publicação de vulnerabilidades da qual dependem equipas de segurança em todo o mundo.
Resposta rápida: A JFrog identificou 54 CVE falsos de SQLite, gerados por IA, que se infiltraram na NVD e em outras bases de dados. Não descreviam vulnerabilidades reproduzíveis: código citado que não existe e provas de conceito (PoC) que não funcionam. Antes de agir sobre um CVE recém-publicado, confirme se o fornecedor o reconhece, se há referência a um commit ou pull request e se a PoC é reproduzível. Não priorize nem corrija com base apenas na pontuação CVSS.
O que a JFrog descobriu
A empresa de segurança da cadeia de fornecimento de software JFrog analisou seis alegadas vulnerabilidades do SQLite que faziam parte de um lote maior publicado por um repositório recente do GitHub. A JFrog reportou que seis supostas vulnerabilidades do SQLite, publicadas num lote maior por um repositório novo e obscuro do GitHub, eram completo lixo. Ao submeter os avisos a um verificador de conteúdo gerado por IA, os resultados apontaram para geração automática, e os testes técnicos confirmaram as suspeitas.
Ao testar, a JFrog verificou que nenhum dos seis relatórios do SQLite, que apresentavam pontuações CVSS entre 9.8 e 7.5, descrevia uma vulnerabilidade reproduzível. Um dos casos mais flagrantes envolveu uma alegada vulnerabilidade de use-after-free: o Red Hat atribuiu-lhe inicialmente a pontuação máxima de 10.0 CVSS antes de a baixar, e o problema baseava-se numa função que não existia na versão afetada do SQLite. Noutro caso, uma vulnerabilidade UAF com pontuação 9.1 citava linhas de código que nem sequer estavam relacionadas com a suposta falha.
A amostra inicial não era um incidente isolado. Uma auditoria mais alargada a 55 avisos publicados pela mesma conta do GitHub revelou que 54 eram completamente fabricados, enquanto um continha um bug real embrulhado em metadados CVE não verificados. A JFrog resumiu o problema no essencial: a mesma conta publicou 54 de 55 CVE em apenas quatro dias, com provas de conceito que não se reproduzem e código-fonte que não corresponde às alegações.
O caso CVE-2026-51302
O exemplo emblemático é o CVE-2026-51302. Enquanto investigava este CVE, a JFrog observou que o Red Hat lhe tinha atribuído inicialmente uma severidade crítica de 10.0, mas que a pontuação foi posteriormente reduzida para 7.6 (High). O ciclo de validação demonstra a fragilidade do processo: a NVD sinalizou rapidamente estes casos como críticos e a ADP da CISA concordou, mas quando os investigadores da JFrog aprofundaram a verificação, as alegações desmoronaram — o código citado não existia nessas versões ou referenciava lógica não relacionada, as PoC não funcionavam, e nenhum destes CVE constava da página oficial de avisos do SQLite.
Este ponto é decisivo. Os próprios criadores do SQLite alertam há muito para a fiabilidade duvidosa de CVE atribuídos a terceiros: os programadores do SQLite não escrevem CVE — qualquer CVE que encontre sobre SQLite é gerado por terceiros, muitas vezes sem qualquer contributo dos programadores principais. O projeto acrescenta ainda que os hackers grey-hat são recompensados com base no número e severidade dos CVE que escrevem, o que resulta numa proliferação de CVE com impacto mínimo ou nulo, mas com alegações de impacto exageradas.
Porque é que estes CVE conseguiram passar
A raiz do problema está na ausência de um ponto de controlo obrigatório na cadeia de publicação. O processo de submissão de CVE através do formulário público da MITRE não tem qualquer verificação real de identidade, o que significa que praticamente qualquer pessoa pode submeter uma descrição de vulnerabilidade e propor uma pontuação CVSS. A rede de segurança que existia foi enfraquecida: historicamente, o NIST atuava como salvaguarda fiável, com especialistas da NVD a analisar, validar e enriquecer manualmente os CVE recebidos, mas essa rede de segurança quebrou em fevereiro de 2024, quando o NIST, atingido por uma vaga massiva de relatórios, praticamente suspendeu a análise aprofundada — a CISA e outros Authorized Data Publishers tentaram intervir, mas o pipeline global ficou fragmentado e afogado num enorme atraso.
O resultado é uma cadeia sem verificação técnica obrigatória. Como nenhum passo do sistema atual exige uma prova de conceito ou reprodução do bug, um aviso falso com aparência plausível pode passar diretamente pelo pipeline e acabar em GitHub Security Advisories, bases de dados a jusante e scanners empresariais. A assimetria é o coração do problema, segundo o investigador da JFrog Afek Berger: a IA generativa reduziu para perto de zero o esforço necessário para produzir um aviso com aparência plausível, enquanto o esforço para o verificar — rever o código-fonte, compilar a versão afetada, reproduzir a PoC — permanece inalterado.
Sinais de alerta: como reconhecer “AI slop”
A JFrog recomendou várias verificações antes de qualquer defensor agir sobre um CVE recém-publicado:
- Se o fornecedor não corroborou o problema (os mantenedores do SQLite não listam os CVE falsos, por exemplo), provavelmente não é legítimo.
- A ausência de um
commit hashou pull request nos campos de referência do repositório também é indicativa de “AI slop”, assim como metadados suspeitos (por exemplo, definições de produto CPE em falta). - Se as referências de código não parecerem corresponder a funções reais ou apontarem para partes do código que nada têm a ver com o suposto problema, é bom sinal de que se trata apenas de uma alucinação da IA.
Cronologia e resposta das entidades
| Momento | Acontecimento |
|---|---|
| Fevereiro 2024 | O NIST suspende a análise aprofundada da NVD devido ao volume de submissões |
| Julho 2026 (4 dias) | Repositório do GitHub publica 55 avisos; 54 revelam-se fabricados |
| 30 de julho de 2026 | A JFrog publica a investigação “SQLite Critical CVEs or LLM Slop?” |
| Dias seguintes | Red Hat reduz o CVSS do CVE-2026-51302 de 10.0 para 7.6 |
Quanto à resposta institucional, a JFrog reportou as suas conclusões à equipa do GitHub Security Advisory, ao Red Hat e à NVD, tendo a empresa indicado que todos sinalizaram ou removeram os CVE. Há, porém, uma exceção: o GitHub ainda não o fez, segundo a JFrog, e o repositório permanecia ativo sem resposta ao pedido de esclarecimento. Sobre a motivação por detrás da campanha, a JFrog especula que possa ser uma tentativa de alguém inflacionar a sua experiência de investigação com relatórios falsos, ou de influenciar o que as ferramentas automáticas de identificação de CVE sinalizam como vulnerabilidades reais — mas ressalva que, em ambos os casos, se trata apenas de especulação.
O risco real para quem automatiza a triagem
Além do desperdício de tempo, o perigo cresce nos ambientes automatizados. Em ambientes onde as vulnerabilidades críticas são priorizadas automaticamente ou onde se abrem tickets com base nas pontuações, estes CVE fabricados podem tornar-se um fardo real; e onde a IA é usada para automatizar a triagem e a remediação, um agente de IA que encontre um CVE fabricado pode tentar localizar a função vulnerável, gerar um patch ou recomendar alterações com base em código que nem sequer existe. Berger sublinhou a dimensão do desafio: essa assimetria significa que mesmo defensores e mantenedores bem preparados não conseguem validar manualmente cada relatório recebido — é um desafio que toda a indústria enfrenta na era da IA.
Porque é que isto importa em Portugal
Para PME e organizações em Portugal, a lição é operacional: a pontuação CVSS deixou de poder ser tratada como sinónimo de verdade absoluta. Muitas equipas de TI e segurança dependem de scanners que ingerem dados da NVD e do GitHub Security Advisories; se um CVE falso entrar nesse fluxo, pode desencadear correções desnecessárias, alarmes injustificados e a diluição da atenção sobre ameaças genuínas. A gestão de vulnerabilidades e a análise crítica dos avisos ganham peso acrescido no âmbito do novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), que exige às entidades abrangidas medidas de gestão de risco proporcionais e processos robustos de tratamento de vulnerabilidades. O CNCS e o CERT.PT recomendam, de forma consistente, a validação das fontes e a priorização baseada em risco real, e não apenas em métricas isoladas.
Para os responsáveis de proteção de dados, importa recordar que decisões automatizadas mal fundamentadas — incluindo remediações erradas despoletadas por falsos positivos — podem afetar a disponibilidade e a integridade de sistemas que processam dados pessoais, matéria relevante à luz do RGPD. A recomendação prática mantém-se: confirmar sempre o aviso, a prova de conceito e o código-fonte antes de priorizar ou aplicar correções.
Perguntas frequentes
O que é “AI slop” no contexto das vulnerabilidades?
É um termo usado para relatórios de vulnerabilidades gerados automaticamente por modelos de linguagem que têm aparência técnica plausível, mas não têm base no comportamento real do software nem no código. Citam funções inexistentes, provas de conceito que não funcionam e referências de código que não correspondem à alegada falha.
Os CVE falsos do SQLite representam algum perigo real para os meus sistemas?
As vulnerabilidades em si não são reais e não podem ser exploradas, porque descrevem código que não existe. O risco real é operacional: desperdício de tempo em investigação e correções desnecessárias, especialmente em ambientes que priorizam ou remedeiam automaticamente com base na pontuação CVSS.
Como posso saber se um CVE recém-publicado é fiável?
Verifique se o fornecedor reconhece oficialmente o problema, se existe referência a um commit ou pull request, se os metadados estão completos e se a prova de conceito é reproduzível. Se as referências de código não corresponderem a funções reais, é provável tratar-se de uma alucinação de IA.
Porque é que estes CVE chegaram à NVD e à CISA?
Porque o processo de submissão via formulário público da MITRE não verifica a identidade de quem submete, e a análise manual aprofundada da NVD foi reduzida desde fevereiro de 2024. Sem um passo obrigatório de reprodução da vulnerabilidade, avisos falsos com aparência credível conseguem propagar-se pelas bases de dados.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela JFrog Security Research, pela página oficial de vulnerabilidades do SQLite, pelo Red Hat e pela NVD/NIST.