4 de octubre de 2023
Django 4.2.6 soluciona un problema de seguridad con severidad «moderada» y varios errores en 4.2.5.
django.utils.text.Truncator¶A raíz de la corrección para CVE 2019-14232, las expresiones regulares utilizadas en la implementación de los métodos chars() y words() de django.utils.text.Truncator (con html=True) fueron revisadas e mejoradas. Sin embargo, estas expresiones regulares aún exhibían complejidad de retroalimentación lineal, por lo que cuando se le presentaba una entrada HTML muy larga y potencialmente malformada, la evaluación seguiría siendo lenta, lo que llevaría a una vulnerabilidad potencial de denegación de servicio.
Los métodos chars() y words() se utilizan para implementar los filtros de plantilla truncatechars_html y truncatewords_html, que también estaban así vulnerables.
El input procesado por Truncator, cuando opera en modo HTML, ha sido limitado a los primeros cinco millones de caracteres con el fin de evitar problemas potenciales de rendimiento y memoria.
Se ha corregido una regresión en Django 4.2.5 donde sobreescribir las configuraciones de almacenamiento de archivos y archivos estáticos desaconsejadas DEFAULT_FILE_STORAGE y STATICFILES_STORAGE en pruebas causaba que el conjunto principal de STORAGES se modificara (#34821).
Se ha corregido una regresión en Django 4.2 que causaba la conversión innecesaria de campos basados en cadenas (CharField, EmailField, TextField, CICharField, CIEmailField y CITextField) utilizados con el lookup __isnull en PostgreSQL. Como consecuencia, los índices que utilizan una expresión o condición __isnull creados antes de Django 4.2 no se utilizarían por el planificador de consultas, lo que provocaría una regresión de rendimiento (#34840).
Es posible que deba recrear los índices creados en su base de datos con Django 4.2 a 4.2.5, ya que contienen conversión ::text innecesaria. Encuentra índices candidatos con esta consulta:
SELECT indexname, indexdef
FROM pg_indexes
WHERE indexdef LIKE '%::text IS %NULL';
may 31, 2026