Resumo
O projeto Django liberou correções para seis vulnerabilidades críticas e elevadas, incluindo três SQL injection que afetam funcionalidades amplamente usadas e vetores de negação de serviço.
O que foi divulgado
A equipe do Django publicou atualizações que corrigem diversas falhas em versões 4.2, 5.2, 6.0 e na branch principal. Entre os problemas corrigidos estão três vulnerabilidades de SQL injection classificadas como de alta severidade (CVE-2026-1207, CVE-2026-1287, CVE-2026-1312) e múltiplos vetores de negação de serviço que podem degradar ou derrubar aplicações.
Detalhes técnicos relevantes
- CVE-2026-1207 — Impacta usuários de PostGIS ao usar lookup em rasters: um índice de banda controlado por entrada não confiável pode resultar em SQL injection.
- CVE-2026-1287 — SQL injection em aliases de colunas via
FilteredRelationquando caracteres de controle são usados em dicionários passados para métodos de QuerySet (ex.:annotate(),aggregate(),values()). - CVE-2026-1312 — SQL injection no uso de
QuerySet.order_by()combinado comFilteredRelationem aliases que contenham pontos. - Denial-of-service — duas vulnerabilidades moderadas exploram concatenação exagerada por headers duplicados em ASGI (CVE-2025-14550) e parsing quadrático em truncator HTML (CVE-2026-1285), além de uma enumeração de usuários por diferenças de tempo na autenticação mod_wsgi (CVE-2025-13473).
Impacto prático
Aplicações web que usam Django e construções afetadas (PostGIS raster lookups, FilteredRelation, uso dinâmico de aliases em consultas) podem estar sujeitas a execução de comandos SQL arbitrários, exfiltração ou corrupção de dados. Implementações ASGI e filtros HTML podem ser alvos de ataques que degradam serviço, afetando disponibilidade.
Recomendações imediatas
- Atualizar para as versões liberadas: 6.0.2, 5.2.11 e 4.2.28 — aplicar patches em ambientes de produção imediatamente.
- Auditar uso de
FilteredRelation,order_by()dinâmico, e qualquer código que construa aliases SQL a partir de dados não confiáveis. - Para usuários de PostGIS, revisar implementações de raster lookup e garantir que índices de banda não sejam controláveis por input não validado.
- Harden ASGI servers contra headers duplicados e monitorar padrões de requisições que possam indicar ataques de concatenação superlinear.
- Validar e sanitizar toda entrada não confiável antes de incorporá-la a consultas ou aliases.
Evidências, assinaturas e verificação
O time do Django assinou as releases com PGP e publicou changelogs e patches por branch no GitHub. Equipes podem verificar versões dos pacotes via repositórios oficiais ou checar os pods/containers com comandos de inventário. Para confirmar correção, valide que a aplicação roda em uma das versões fixadas e execute testes de integração que cobrem as funcionalidades de QuerySet e PostGIS em uso.
Implicações para equipes de desenvolvimento e segurança
Desenvolvedores devem tratar запросs e dados que derivam nomes de colunas ou aliases com suspeita; padrões que geram SQL dinâmico a partir de dicionários ou entradas externas precisam de revisão. Equipes de segurança devem priorizar a atualização e planejar auditorias de código focadas nas APIs que constroem consultas dinamicamente.
Checklist de resposta
- Inventariar serviços que usam Django nas versões afetadas.
- Agendar patch imediato para 4.2.28 / 5.2.11 / 6.0.2 conforme aplicável.
- Auditar código que utiliza FilteredRelation, order_by dinâmico e chamadas a PostGIS raster lookups.
- Testar comportamento do sistema após atualização e monitorar logs por qualquer anomalia de consultas ou quedas de performance.
Fonte: Cyber Security News (resumo do advisory do Django)