CVE
CVE-2026-6907
CWE
CWE-524
Sistemas afectados
- Django 6.0 anterior a 6.0.5
- Django 5.2 anterior a 5.2.14
- aplicaciones Django que utilizan UpdateCacheMiddleware
El middleware de caché de Django está diseñado para no almacenar respuestas que no se puedan reutilizar de forma segura. CVE-2026-6907 es un fallo sutil en ese límite, notificado por el investigador de Corgea Ahmad Sadeddin: django.middleware.cache.UpdateCacheMiddleware almacenaba respuestas aunque incluyeran la cabecera Vary: *. Para consultar recomendaciones generales sobre el refuerzo del framework, visita nuestra guía de buenas prácticas de seguridad en Django.
Ese valor de cabecera tiene un significado especial. Indica a las cachés compartidas que la respuesta varía según factores que no se pueden expresar mediante cabeceras de solicitud normales y que, por tanto, no debe reutilizarse para otra solicitud. Si el código de una aplicación generaba una respuesta privada con Vary: *, las versiones afectadas de Django podían almacenarla y servirla más adelante desde la caché.
Impacto
El principal riesgo es la exposición de datos privados a través de una caché compartida. Las aplicaciones afectadas presentan un mayor riesgo cuando se cumplen todas estas condiciones:
- El middleware de caché global de Django está habilitado.
- Una vista puede devolver contenido específico de un usuario o cualquier otro contenido sensible.
- La respuesta contiene
Vary: *. - Otro usuario o contexto de solicitud puede acceder a la respuesta almacenada.
La Django Software Foundation clasifica el problema como de gravedad baja según su política de seguridad, mientras que la puntuación CNA CVSS v3.1 es 4,3 (media) por su impacto bajo en la confidencialidad. La gravedad práctica depende del contenido que la vista afectada incluya en la respuesta y del alcance de la caché compartida.
Versiones afectadas
Las versiones compatibles afectadas son Django 6.0 anteriores a 6.0.5 y Django 5.2 anteriores a 5.2.14. El aviso de Django también señala que las ramas antiguas sin soporte, como 5.0.x, 4.1.x y 3.2.x, no se evaluaron y podrían estar afectadas.
Remediación
Actualiza Django a una versión corregida:
- Los usuarios de Django 6.0 deben actualizar a la versión 6.0.5 o posterior.
- Los usuarios de Django 5.2 deben actualizar a la versión 5.2.14 o posterior.
- Los equipos que utilicen una rama de Django sin soporte deben migrar a una versión compatible y corregida, en lugar de confiar en un comportamiento antiguo que no se ha evaluado.
Después de actualizar, revisa los endpoints que combinan respuestas específicas de usuario con el middleware de caché. Confirma que las páginas sensibles utilizan controles explícitos como Cache-Control: private o Cache-Control: no-store cuando corresponda y evita depender de Vary: * como única protección frente a la reutilización en cachés compartidas.
Detección y respuesta
Empieza por buscar Vary: *, patch_vary_headers(..., ["*"]) y cualquier lógica de control de caché personalizada alrededor de vistas autenticadas. Si un endpoint sensible pudo emitir Vary: * mientras la caché global estaba habilitada, invalida la caché compartida después de desplegar la versión corregida y rota los datos vinculados a sesiones que pudieran haber quedado expuestos. Los equipos pueden complementar esta revisión con Corgea AI SAST para detectar patrones vulnerables en frameworks durante la revisión de código.
En servicios de producción, combina esta revisión con el análisis de registros de acceso para localizar impactos repetidos de caché en rutas autenticadas o personalizadas. El indicador más claro es que el mismo cuerpo de respuesta o la misma clave de caché se sirva a usuarios o sesiones diferentes.
De la investigación a la remediación
Comprueba si este patrón existe en tu código
Convierte esta investigación en un flujo de remediación. Utiliza análisis estático con IA para encontrar problemas similares y generar correcciones listas para revisar.