7 de abril de 2026
Django 4.2.30 resuelve un problema de seguridad con severidad «moderada» y cuatro problemas de seguridad con severidad «baja» en la versión 4.2.29.
ASGIRequest normaliza nombres de encabezados siguiendo las convenciones WSGI, mapeando guiones a subrayados. Como resultado, incluso en configuraciones donde los proxies inversos eliminan cuidadosamente los encabezados sensibles a la seguridad nombrados con guiones, un tal encabezado podría ser spoofeado suministrando un encabezado nombrado con subrayados.
Bajo WSGI, es responsabilidad del servidor o proxy evitar las mapeaciones ambiguas. (El comando runserver de Django se parchó en CVE 2015-0219. ) Pero bajo ASGI, no hay la misma expectativa uniforme, incluso si muchos proxies protegen contra esto por defecto (incluyendo nginx mediante underscores_in_headers off;).
Los encabezados que contienen subrayados se ignoran ahora por ASGIRequest, coincidiendo con el comportamiento de Daphne, el servidor de referencia para ASGI.
Este problema tiene una severidad de «baja» según la póliza de seguridad de Django.
GenericInlineModelAdmin¶No se validaban las permisos en instancias de modelos inline al enviar datos falsificados de POST en GenericInlineModelAdmin.
Este problema tiene una severidad de «baja» según la póliza de seguridad de Django.
ModelAdmin.list_editable¶Las formas de cambio de administrador utilizando list_editable permitían incorrectamente la creación de nuevas instancias mediante datos falsificados de POST.
Este problema tiene una severidad de «baja» según la póliza de seguridad de Django.
MultiPartParser a través de archivo de carga base64 codificado¶When utilizando django.http.multipartparser.MultiPartParser, las subidas multipart con Content-Transfer-Encoding: base64 que incluyen espacios en blanco excesivos pueden desencadenar copias repetidas de memoria, lo que potencialmente puede degradar el rendimiento.
Este problema tiene severidad «moderada» según la política de seguridad de Django.
Las solicitudes ASGI con un encabezado Content-Length faltante o subestimado podrían bypassar el límite DATA_UPLOAD_MAX_MEMORY_SIZE al leer HttpRequest.body, lo que potencialmente podría cargar en la memoria un cuerpo de solicitud no limitado y causar una degradación del servicio.
Este problema tiene una severidad de «baja» según la póliza de seguridad de Django.
may 31, 2026