Cómo mantener la seguridad una vez que Django llegue al final de su ciclo de vida

Principales conclusiones

• El fin de la vida útil de Django te deja expuesto a vulnerabilidades CVE sin parchear, no solo en Django, sino también en dependencias como sqlparse, lo que puede comprometer el cumplimiento de las normas PCI DSS, HIPAA y SOC 2.
• Pasar de Django 3.2 o 4.2 a la versión 5.2 obliga a actualizar el entorno de ejecución de Python y conlleva cambios que pueden provocar incompatibilidades, por lo que requiere una planificación minuciosa en lugar de una implementación apresurada para cumplir con un plazo.
• TuxCare ELS para Django mantiene actualizada y conforme a las normas tu versión obsoleta mientras realizas la migración a tu propio ritmo.

Si tu pila de aplicaciones de Python incluye Django para el desarrollo web —y es muy probable que así sea—, conviene informarse sobre el fin de la vida útil (EOL) de Django antes de que un escáner de seguridad o una auditoría de cumplimiento te obligue a abordar el tema.

Durante casi dos décadas, Django ha sido uno de los marcos de trabajo de referencia para desarrollar aplicaciones web en Python. Su modelo «batteries-included» integra el ORM, la autenticación, la interfaz de administración, la gestión de formularios, el middleware de seguridad y otras funciones esenciales de las aplicaciones web en un único marco, lo que explica precisamente por qué tantos equipos empresariales siguen confiando en él en entornos de producción. Sin embargo, esa estabilidad a largo plazo también conlleva riesgos relacionados con el ciclo de vida. Django 3.2 LTS llegó al final de su vida útil en abril de 2024, Django 4.2 LTS lo hizo en abril de 2026, y las versiones no LTS como 4.0, 4.1, 5.0 y 5.1 ya no reciben soporte. Para todas ellas, se han dejado de publicar parches de seguridad.

En este artículo se explica qué significa en la práctica el fin de la vida útil (EOL) de Django, por qué el historial de vulnerabilidades hace que ese riesgo sea real y cómo TuxCare ELS para Django ayuda a las organizaciones a mantenerse al día con los parches y cumplir con la normativa sin obligarlas a realizar una migración precipitada antes de que sus equipos estén preparados.

¿Qué es Django y por qué sigue siendo tan utilizado?

Django es un marco web de alto nivel escrito en Python y mantenido por la Fundación de Software Django. Su arquitectura «modelo-vista-plantilla» (MVT) separa la lógica de negocio, el acceso a los datos y la presentación, lo que permite a los equipos crear aplicaciones web fáciles de mantener sin tener que volver a implementar la infraestructura que toda aplicación web necesita. El marco incluye un ORM integrado, un sistema de migraciones, un backend de autenticación, una interfaz de administración, validación de formularios, protección contra la falsificación de solicitudes entre sitios y middleware de seguridad, una pila completa que ha convertido a Django en el marco web de Python estándar para las organizaciones que priorizan la fiabilidad y la exhaustividad.

La adopción de Django está muy arraigada en las pilas de Python de las empresas. Sirve de base para plataformas de gestión de contenidos, portales de servicios financieros, sistemas gubernamentales y backends de comercio electrónico en sectores que llevan una década o más desarrollando con Python. La misma estabilidad y exhaustividad que hicieron atractivo a Django también contribuyen a su persistencia en producción: las aplicaciones construidas sobre una versión de Django bien conocida rara vez se plantean como candidatas a una actualización hasta que un escáner de CVE o una auditoría de cumplimiento crea esa presión. Esa es precisamente la trampa del fin de vida útil (EOL) de Django.

¿En qué consiste el ciclo de vida de los productos de Django?

Django utiliza un ciclo de lanzamiento predecible y basado en plazos. Las versiones con nuevas funcionalidades se publican aproximadamente cada ocho meses. Cada versión recibe parches de seguridad durante un total de dieciséis meses: ocho meses de soporte completo, seguidos de ocho meses de mantenimiento dedicado exclusivamente a la seguridad. La excepción es la designación de soporte a largo plazo (LTS): la versión final de cada rama de versión principal recibe tres años completos de soporte de seguridad. Comprender qué versiones tienen el estatus LTS es esencial para evaluar con precisión el riesgo de fin de vida útil (EOL) de Django en toda tu pila, ya que las versiones que no son LTS llegan al fin de su vida útil mucho más rápido de lo que los equipos suelen esperar.

Django 4.2 LTS, la versión anterior con soporte a largo plazo, llegó al final de su ciclo de vida el 7 de abril de 2026. Django 3.2 LTS llegó al final de su ciclo de vida en abril de 2024. Las versiones no LTS intermedias (4.0, 4.1, 5.0, 5.1) llegaron al final de su ciclo de vida antes, y varias de ellas llevan años sin recibir parches del desarrollador original. Cualquier organización que siga utilizando alguna de estas versiones está utilizando software para el que la Fundación de Software Django no publicará ninguna corrección, independientemente de lo que se descubra.

El fin de vida útil (EOL) de Django es incondicional. El proyecto Django no ofrece soporte comercial ampliado, modos de mantenimiento exclusivos de seguridad ni retroportación de parches para versiones anteriores. Cuando una versión de Django llega al final de su vida útil, el soporte del desarrollador original cesa por completo, y ese es precisamente el vacío que TuxCare ELS para Django está diseñado para cubrir. Esto significa que cada CVE divulgada después de la fecha de fin de vida útil supone una vulnerabilidad permanente sin parchear, a menos que un proveedor como TuxCare realice la retroportación de las correcciones.

Historial de CVE: lo que revela el registro de vulnerabilidades

El fin de la vida útil (EOL) de Django no significa que dejen de detectarse vulnerabilidades en las versiones que han llegado al final de su ciclo de vida, sino que dejan de corregirse. El ORM de Django es expresivo y potente, lo que también implica que los fallos en la forma en que gestiona los datos introducidos por el usuario pueden traducirse directamente en inyecciones SQL. Las dos CVE que se indican a continuación están confirmadas en el NVD y definen el principal riesgo de seguridad directo que el EOL de Django supone para las organizaciones que ejecutan versiones sin soporte en producción. Puede realizar un seguimiento del estado de los CVE que afectan a las versiones de Django al final de su vida útil y de las correcciones disponibles a través del rastreador de CVE de TuxCare.

CVE-2022-28346: Inyección SQL en los alias de columna de QuerySet

CVE-2022-28346 (NVD CVSS 3.1: 9,8 Crítico) es una vulnerabilidad de inyección SQL en el ORM de Django que afecta a los métodos QuerySet.annotate(), aggregate() y extra(). Cuando se definen alias de columna mediante la expansión de diccionarios, al pasar un diccionario manipulado como **kwargs, Django no valida ni escapa adecuadamente los valores de los alias de columna antes de interpolarlos en la consulta SQL generada. Un atacante que pueda influir en el contenido del diccionario puede inyectar SQL arbitrario en la parte de alias de columna de la consulta, eludiendo las protecciones normales de Django para consultas parametrizadas.

La vulnerabilidad CVE-2022-28346 se dio a conocer el 11 de abril de 2022, y se publicaron parches para las versiones 2.2.28, 3.2.13 y 4.0.4 de Django. Las organizaciones que utilizaban versiones que ya habían superado su ciclo de vida en el momento de la divulgación no recibieron ningún parche del desarrollador original. La vulnerabilidad cuenta con una prueba de concepto disponible públicamente y sigue siendo una vulnerabilidad concreta y explotable en cualquier instalación de Django sin parches.

CVE-2024-42005: Inyección SQL a través de JSONField en QuerySet.values()

CVE-2024-42005 (CVSS 3.1: 9,8 Crítico según el aviso de seguridad de Django) es una vulnerabilidad de inyección SQL en el ORM de Django que afecta a los métodos QuerySet.values() y values_list() en modelos que incluyen un JSONField. Al crear claves de objetos JSON específicas y pasarlas como parámetros *arg a estos métodos, un atacante puede hacer que Django utilice la clave maliciosa como alias de columna sin la debida sanitización, inyectando SQL arbitrario en la consulta generada. El ataque es de tipo red, no requiere autenticación y tiene una complejidad baja.

La vulnerabilidad CVE-2024-42005 se dio a conocer el 6 de agosto de 2024, y se publicaron parches para Django 4.2.15 y 5.0.8. Django 3.2 LTS ya había superado su fecha de fin de vida útil (EOL) en abril de 2024 en el momento de la divulgación, y Django 4.0 y 4.1 llevaban fuera de servicio desde abril de 2023 y diciembre de 2023, respectivamente. Django no probó ni parcheó esas versiones fuera de servicio. Las organizaciones que utilizan estas versiones de Django fuera de ciclo de vida (EOL) están expuestas a esta vulnerabilidad crítica de inyección SQL con un CVSS de 9,8 sin que el proyecto Django ofrezca una solución oficial.

El riesgo de dependencia: sqlparse

Django requiere dos dependencias directas en tiempo de ejecución: asgiref y sqlparse. sqlparse incluye CVE-2024-4340 (CVSS 7,5 Alta), una vulnerabilidad de denegación de servicio que se activa cuando sqlparse.parse() procesa una lista profundamente anidada, lo que provoca un error de recursión (RecursionError) que bloquea el analizador. La corrección se publicó en la versión 0.5.0 de sqlparse. Las organizaciones que utilizan versiones antiguas de Django que han llegado al final de su vida útil (EOL) también pueden estar limitadas a versiones de sqlparse anteriores a esa corrección, lo que agrava la superficie de exposición que cubre TuxCare ELS para Django.

Cumplimiento y exposición a la normativa

El requisito 6.3.3 de la norma PCI DSS exige que las vulnerabilidades con una puntuación CVSS de 7,0 o superior se corrijan en el plazo de un mes desde su divulgación pública. La vulnerabilidad CVE-2022-28346, con una puntuación CVSS de 9,8, es de dominio público desde abril de 2022, y la vulnerabilidad CVE-2024-42005, con una puntuación CVSS de 9,8, lo es desde agosto de 2024. Las organizaciones que ejecutan versiones de Django en fin de vida útil (EOL) sin un acuerdo de aplicación de parches llevan años incumpliendo esos plazos de corrección en algunos casos. Ejecutar componentes de marcos web con vulnerabilidades conocidas y sin parches en aplicaciones que manejan información médica protegida (PHI) no cumple los requisitos de la Norma de Seguridad de la HIPAA para la protección contra amenazas razonablemente previsibles. Los auditores de SOC 2 Tipo II señalan las versiones de bibliotecas sin soporte como debilidades de control. ELS para Django es la forma en que las organizaciones cumplen con estas obligaciones de cumplimiento mientras la migración se planifica y ejecuta según su propio calendario.

Los riesgos de precipitarse al realizar una migración en Django

La presión para dar respuesta a los hallazgos relacionados con el fin de vida útil de Django es real. Las herramientas de análisis de la composición del software generan hallazgos. Los auditores de seguridad plantean preguntas directas. Los plazos de cumplimiento no se modifican por las limitaciones de capacidad de ingeniería. Los equipos que gestionan adecuadamente el fin de vida útil de Django son aquellos que comprenden la diferencia entre responder al riesgo y crear un nuevo riesgo al actuar con precipitación.

¿Qué pasa si te precipitas?

Cuando los equipos se ven obligados a acelerar la migración de Django en un plazo poco realista debido a la presión derivada de los resultados de auditorías de cumplimiento o de seguridad, las cosas suelen salir mal de formas previsibles:

Aumento de la carga de asistencia técnica: Cada versión principal de Django elimina características obsoletas que pueden haberse ido acumulando silenciosamente en los códigos base durante años. Cuando se ignoraban las advertencias de obsolescencia, las eliminaciones se convertían en cambios que provocaban errores y que solo salían a la luz tras la implementación. Los equipos de soporte se ven inmediatamente desbordados con tickets sobre vistas que no funcionan, envíos de formularios fallidos y errores de consultas ORM que no se detectaron en las pruebas comprimidas.

Inestabilidad del sistema: El comportamiento del ORM de Django cambia entre versiones principales de formas sutiles que no siempre se detectan en las pruebas unitarias. Los resultados de las consultas que varían debido a diferencias en el orden, el comportamiento de la agregación o el manejo de campos JSON pueden introducir errores en la capa de datos que solo se manifiestan bajo carga de producción o con patrones de datos específicos, del tipo que son difíciles de reproducir y costosos de diagnosticar.

Acumulación de deuda técnica: En su prisa por cumplir con los requisitos, los equipos toman atajos. Los patrones obsoletos que deberían haberse refactorizado se parchean con soluciones de compatibilidad. Los ajustes que cambiaron su comportamiento entre versiones se anulan de formas que no están documentadas. El problema del fin de vida útil (EOL) de Django se aplaza con estas soluciones provisionales, no se resuelve, y la deuda acumulada encarece posteriormente una migración adecuada.

Costes imprevistos: Las horas de ingeniería de emergencia, los retrasos en el lanzamiento de funciones y el coste de oportunidad que supone que sus mejores ingenieros dediquen su tiempo a solucionar problemas de compatibilidad de la migración en lugar de desarrollar nuevas capacidades se acumulan rápidamente, llegando normalmente a una cifra que supera lo que habrían costado los servicios de soporte ampliado durante todo el periodo de planificación de la migración.

Requisito previo: la versión de Python

La migración a Django 5.2 LTS requiere Python 3.10 o una versión superior. Las organizaciones que utilizan Django 3.2 pueden estar ejecutando Python 3.6, 3.7 o 3.8, versiones que, a su vez, ya han superado sus fechas de fin de vida útil establecidas por el desarrollador original. Las organizaciones que ejecutan Django 4.2 pueden estar utilizando Python 3.8 o 3.9. Esto significa que, para muchas organizaciones, la solución completa al fin de vida útil de Django consiste en una migración secuencial tanto del entorno de ejecución de Python como del marco Django, con toda la verificación de compatibilidad de dependencias que ello implica. Los equipos que plantean la migración como una «actualización de Django» y luego descubren el requisito previo de Python a mitad del proyecto son los que se enfrentan a los mayores retrasos inesperados en los plazos.

Opciones para garantizar la seguridad y el cumplimiento normativo

Las organizaciones que utilizan versiones de Django llegadas al final de su ciclo de vida tienen tres opciones. Dos de ellas implican un esfuerzo técnico considerable, riesgos operativos y plazos prolongados. La tercera resuelve el problema de inmediato, mientras tus equipos planifican la migración adecuadamente.

Opción 1: Migrar a Django 5.2 LTS

La solución a largo plazo consiste en migrar a Django 5.2 LTS, la versión actual con soporte a largo plazo que cuenta con cobertura de seguridad activa por parte del desarrollador original hasta abril de 2028. Esto elimina el riesgo de que Django llegue al final de su vida útil (EOL), al pasar a utilizar software del desarrollador original que se mantiene de forma activa. La migración supone un verdadero reto técnico. Django 5.2 requiere Python 3.10 o superior, por lo que las organizaciones que utilicen versiones anteriores de Python deben actualizar su entorno de ejecución antes de iniciar la migración a Django. Más allá del requisito previo del entorno de ejecución, cada versión principal entre tu versión actual y la 5.2 elimina características que quedaron obsoletas en versiones anteriores. Para un equipo que da el salto de la 3.2 a la 5.2, eso significa tener en cuenta tres generaciones de eliminaciones. Las aplicaciones con middleware personalizado, backends de plantillas personalizados o un uso no trivial de ORM deberían planificar esta migración en trimestres, no en semanas.

Opción 2: Sustituir Django por otro marco de trabajo

Algunas organizaciones consideran el fin de la vida útil (EOL) de Django como el motivo para evaluar alternativas. FastAPI, Flask y Starlette son marcos web de Python que reciben un mantenimiento activo y presentan diferentes modelos arquitectónicos. Si los requisitos de una aplicación han evolucionado hacia los microservicios o un diseño «API-first», un cambio de marco podría encajar con los objetivos arquitectónicos. Una migración completa de marco es más disruptiva que una actualización dentro del mismo marco; cada vista, formulario, llamada ORM y middleware debe reimplementarse en el modelo del nuevo marco. Ni la sustitución del marco ni una actualización estándar son soluciones rápidas para un hallazgo inmediato de incumplimiento del fin de vida útil de Django. Ambas son vías viables a largo plazo para equipos con la capacidad de ejecutarlas con cuidado.

Opción 3: Asistencia técnica de por vida de TuxCare (la opción recomendada)

El servicio «Endless Lifecycle Support» de TuxCare para Django es la opción que te permite mantener la seguridad sin tener que llevar a cabo una migración para la que tu equipo aún no está preparado. En lugar de forzar una actualización disruptiva en toda tu aplicación Django y sus dependencias, sigues ejecutando tu versión actual de Django con cobertura continua de parches de seguridad, que se entregan como actualizaciones de paquetes listas para usar a través de tu flujo de trabajo pip existente. Para eso está diseñado el ELS para Django: para cubrir el lapso entre el momento en que finaliza el soporte oficial y el momento en que tu organización ha completado realmente una migración planificada y controlada según su propio calendario.

La solución sencilla: TuxCare ELS para Django EOL

TuxCare ofrece soporte técnico de por vida para las versiones de Django que han dejado de recibir actualizaciones, lo que garantiza que tu implementación actual de Django siga estando protegida mediante parches de seguridad que se distribuyen a través de tu flujo de trabajo de pip existente. TuxCare ha distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto.

Cobertura completa del árbol de dependencias: TuxCare ELS para Django no solo cubre el propio paquete Django, sino también toda su huella de dependencias en tiempo de ejecución, incluyendo sqlparse y su exposición conocida a CVE (CVE-2024-4340, CVSS 7.5 Alta). Los escáneres de vulnerabilidades no respetan los límites de los paquetes, y tampoco lo hace la cobertura de TuxCare. Se aborda toda la superficie de parches sin coste adicional.

Proceso de aplicación de parches optimizado y automatizado: TuxCare supervisa el NVD, los avisos de seguridad de Django, los feeds de seguridad de GitHub y los canales de divulgación de los proveedores, todas las fuentes en las que se revelan las vulnerabilidades de Django y sus dependencias. Cuando se identifica un CVE, las herramientas algorítmicas y la automatización asistida por IA se encargan de adaptar las correcciones de seguridad a la versión compatible, y los expertos en seguridad validan cada parche antes de su lanzamiento. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. Para obtener todos los detalles técnicos, consulte el .

Integración perfecta: Tanto si actualmente instalas Django directamente a través de pip como a través de un espejo de paquetes privado, puedes cambiar tu fuente de actualización al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo actual. No hay ningún cambio en tu canalización de CI/CD, ni en tu proceso de implementación, ni en la forma de trabajar de tus equipos. Los paquetes de Django parcheados son sustitutos directos con la misma API, la misma configuración y el mismo comportamiento en tiempo de ejecución, con correcciones de seguridad retrocompatibles.

Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades que afectan a versiones de Django en fin de vida útil, ya sea en el propio Django, en sqlparse o en asgiref, TuxCare proporciona parches respaldados por acuerdos de nivel de servicio. Las vulnerabilidades de gravedad alta y crítica (CVSS 7.0 y superior) se resuelven en un plazo de 14 días desde su divulgación pública.

Continuidad de la seguridad a un precio asequible: El coste de TuxCare ELS es una fracción de lo que cuesta una migración de emergencia cuando se ve obligada por un plazo de cumplimiento normativo. Usted planifica una migración deliberada a Django 5.2 LTS cuando se adapta a la capacidad de su equipo, incluyendo el tiempo necesario para resolver los requisitos previos del entorno de ejecución de Python, verificar la compatibilidad de los paquetes de terceros y validar el comportamiento en todas las rutas de la aplicación. O bien, utiliza ELS para mantener la seguridad y el cumplimiento normativo totales mientras toma esas decisiones según su propio calendario, y no el de un auditor de cumplimiento.

No dejes que el fin de la vida útil de Django ponga en riesgo tus aplicaciones

El hecho de que una versión de Django haya llegado al final de su ciclo de vida no significa que tu aplicación quede automáticamente en peligro. Significa que, si una vulnerabilidad crítica afecta a la versión que estás utilizando, el proyecto Django no te proporcionará un parche. Cada nuevo CVE que se publique tras el final del ciclo de vida amplía el periodo de exposición, y sin una corrección adaptada a versiones anteriores, ese periodo permanece abierto.

La respuesta adecuada depende del calendario, la tolerancia al riesgo y la capacidad técnica de tu organización. Si puedes pasar a Django 5.2 LTS ahora mismo —incluida cualquier actualización necesaria del entorno de ejecución de Python—, esa es la mejor opción a largo plazo. Pero si tu aplicación de Django es demasiado compleja para migrarla de forma segura bajo presión, TuxCare ELS para Django te ofrece una cobertura de seguridad continua mientras tu equipo planifica y lleva a cabo la actualización de forma adecuada.

Si el fin de la vida útil de Django te preocupa en estos momentos, visita Soporte de ciclo de vida ilimitado para Django para ver cómo el soporte ampliado puede proteger tus aplicaciones Python, o explora la oferta completa de TuxCare de TuxCare para software de código abierto de TuxCare para cubrir toda su pila de código abierto.

Resumen

Nombre del artículo

ELS para Django: mantén la seguridad tras el fin de la vida útil con TuxCare

Descripción

¿Utilizas una versión de Django que ha llegado al final de su ciclo de vida (EOL)? TuxCare ELS para Django mantiene tus aplicaciones de Python actualizadas y conformes con los requisitos sin obligarte a realizar una migración precipitada.

Autor

Muzzammil Hasann

Nombre del editor

TuxCare

Logotipo de la editorial