CVE-2024-42005 no Django: uma injeção SQL oculta atrás do JSONField

Publicado em 2026-10-27 por frfrand

Como surgiu uma falha de SQL injection no Django QuerySet, a quais versões afetou, quando há exposição e o que corrigir.

O ORM do Django evita todas as injeções SQL?

Um ORM ajuda muito, mas não torna qualquer entrada externa segura. CVE-2024-42005, corrigida pelo Django em agosto de 2024, mostra um caso concreto: certas chamadas a QuerySet.values() e values_list() sobre modelos com JSONField podiam produzir injeção SQL quando chaves JSON preparadas maliciosamente eram usadas como argumentos de coluna.

O que faz o JSONField?

Permite salvar e consultar dados com estrutura JSON em uma coluna. É útil para configurações e atributos variáveis; por exemplo, o perfil de um produto com características distintas. O problema aparece quando se usa o nome de um campo ou uma chave JSON como parte da estrutura de uma consulta, em vez de tratá-lo apenas como dado validado.

Quem o detectou?

O Django documentou a vulnerabilidade em suas notas oficiais de 6 de agosto de 2024. Para investigar esse tipo de defeito, inspeciona-se como o SQL é gerado a partir de métodos do ORM e testam-se identificadores especiais, aliases e entradas inesperadas. Se precisar conhecer a autoria exata da descoberta, consulte o registro oficial; não convém inventar créditos de pesquisa.

Como isso poderia ser explorado?

Imagine um endpoint que permite ao usuário escolher campos de uma resposta e passa esses nomes diretamente para values(). Se o modelo usar JSONField e os nomes puderem manipular aliases SQL, o usuário poderia influenciar a consulta. Não é ativado pelo simples fato de ter o Django e o PostgreSQL instalados: são necessárias as funções e o fluxo de entrada pertinentes.

Por que isso importa tanto se o Django costuma parametrizar?

Consultas parametrizadas protegem valores, mas identificadores e aliases podem exigir outro tipo de validação. Confiar em uma função segura para valores quando, na verdade, está se construindo a estrutura SQL é um erro comum. O impacto depende das permissões do usuário do banco de dados e de quais operações a consulta afetada permite.

Quais versões foram corrigidas?

As notas do Django apontam as correções em 5.0.8 e 4.2.15. São versões de referência do boletim de 2024. Para 2026, escolha um ramo ainda mantido e revise seus avisos; não congele um aplicativo em uma versão antiga.

Como revisar se seu projeto Django está exposto?

Busque usos de values(), values_list() e modelos com JSONField. Investigue especialmente endpoints que aceitam da API nomes de campos, ordenamentos ou seleções dinâmicas. Confirme que há uma lista permitida de nomes definidos pelo desenvolvedor em vez de passar strings do cliente para a consulta. Os testes devem cobrir entradas estranhas e permissões de papel SQL.

Como corrigir?

Atualize o Django; valide os campos que um cliente pode solicitar; use permissões mínimas no banco de dados; adicione testes de regressão e revise funções auxiliares que geram consultas dinâmicas. Se houver suspeita de abuso, conserve logs e analise as operações realmente executadas antes de determinar o escopo.

Perguntas rápidas

Afecta a todos os modelos? Não: o cenário documentado envolve modelos com JSONField e argumentos específicos.

Basta escapar manualmente a string? Não. É mais seguro validar um conjunto fechado de identificadores e atualizar o framework.

Ter DRF muda algo? Depende de como a view transforma parâmetros do usuário em operações QuerySet.

Fontes: Notas Django 5.0.8 · Notas Django 4.2.15 · Registro CVE.

Onde acompanhar alertas CVE e receber orientação?

Em ArduMaker CVE e suporte publicamos atualizações e centralizamos consultas sobre vulnerabilidades, começando pelo WordPress e suas tecnologias relacionadas. Se o seu caso envolver outro runtime ou um banco de dados, especifique componente, versão, sistema operacional e exposição do serviço para contextualizá-lo. O aviso de uma CVE não prova que seu servidor esteja comprometido: a avaliação requer inventário, configuração e evidência.

Nota editorial — outubro de 2026: estas versões corrigidas são os marcos do aviso original. Ao atualizar hoje, escolha um ramo com suporte vigente e verifique o comunicado atual do fabricante.

Exemplo prático: escolher campos dinâmicos do Django sem confiar no usuário

Situação: uma API de produtos admite ?campo=id&campo=nome e transforma cada parâmetro diretamente em argumentos de QuerySet.values(). Se esses nomes vierem de usuários, devem ser validados, especialmente quando combinados com JSONField.

Exemplo simplificado com lista permitida:

CAMPOS_PERMITIDOS = {"id", "nombre", "estado"}

solicitados = request.GET.getlist("campo")
if not solicitados or any(c not in CAMPOS_PERMITIDOS for c in solicitados):
    return JsonResponse({"error": "Campo no permitido"}, status=400)

filas = list(Producto.objects.values(*solicitados))
return JsonResponse({"resultados": filas})

Antes: passar sem controle nomes enviados pelo cliente ao ORM. Depois: atualizar o Django, validar identificadores contra uma lista fechada e usar um papel SQL sem privilégios de administração.

Importante: o exemplo ilustra uma defesa em nível de aplicação; o fix oficial do CVE-2024-42005 continua sendo necessário. Teste também o que acontece com solicitações vazias, campos repetidos e chaves JSON arbitrárias.