Desde 2027, cada versión menor de Drupal tendrá 8 meses de soporte de seguridad: 6 de correcciones y 2 solo de parches.
Traducido a calendario: cuando sale la versión menor siguiente, la anterior tiene unos 2 meses de vida, no los 6 que daba la regla vieja. Ese cambio reordena el mantenimiento de cualquier sitio en Drupal, incluido el que hoy está al día.
Qué cambió con el PSA-2026-11-02
El 2 de noviembre de 2026 el Drupal Security Team publicó el PSA-2026-11-02. La regla anterior venía de Drupal 8.6, en 2018: cada menor tenía 12 meses de cobertura. La nueva, que aplica desde 2027, la deja en 8, repartidos en seis meses de corrección de errores y dos de soporte solo de seguridad.
Ese reparto es lo que cambia el trabajo, no el número. Las menores salen cada seis meses, en junio y diciembre. Con 12 meses de cobertura, la rama anterior seguía recibiendo parches medio año después de que apareciera la nueva; por eso actualizar una vez al año era una práctica defendible. Con 8 meses, el solapamiento queda en dos.
Hay dos matices que se pierden en los resúmenes:
- La última menor de cada versión mayor conserva seis meses de correcciones y seis de seguridad.
- Las mayores no cambian: al menos cuatro años de soporte. Drupal 11 llega a diciembre de 2028 y Drupal 12 a diciembre de 2030.
Nada de esto significa que Drupal sea menos seguro hoy. Significa que el compromiso de mantener ramas viejas es más corto, y que la fecha que importa ya no es cuándo salió tu versión, sino cuándo salió la siguiente.
Por qué lo hicieron
La PSA lo dice sin rodeos: la avalancha de reportes impulsada por herramientas de IA desborda al equipo, y recortar la ventana reduce cerca del 30 % el trabajo de backport de advisories de core. El anuncio también advierte que los parches pueden tardar más en salir, justo cuando los atacantes usan LLM para buscar fallas. Un sitio fuera de soporte no está "un poco atrasado": espera a que la falla se conozca sin ruta de parche.
El calendario, rama por rama
Con el calendario oficial de lanzamientos sobre la mesa, estas son las fechas de fin de soporte que hay que tener escritas:
- Drupal 10.6: 9 de diciembre de 2026. Es fin de vida, no solo fin de seguridad: después de esa fecha no habrá más lanzamientos de Drupal 10.
- Drupal 11.3: semana del 7 de diciembre de 2026.
- Drupal 11.4: 21 de abril de 2027.
- Drupal 11.5: agosto de 2027.
- Drupal 11.6: febrero de 2028.
La semana del 7 de diciembre concentra tres cosas: salida de 12.0.0 y 11.5.0, fin de soporte de 11.3 y fin de soporte de 10.6. Si tu plan de mantenimiento no tiene esa semana marcada, no es un plan, es una intención.
Ojo: las notas de lanzamiento viejas quedaron desactualizadas. Las de 11.4 decían junio de 2027; las de 11.4.12, del 6 de noviembre, ya dicen 21 de abril de 2027. Si hay discrepancia, mandan la PSA y el calendario.
Cómo saber qué ventana te queda
Primero, la rama exacta. "Estamos en Drupal 11" no sirve: 11.3 y 11.4 tienen fechas distintas.
composer show drupal/core-recommended | grep -E "^versions"
# versions : * 11.4.12
O desde el propio sitio:
drush status --fields=drupal-version,php-version
Segundo, la restricción en composer.json. Aquí se esconde la causa más común de un sitio que dejó de actualizarse sin que nadie lo notara:
jq -r '.require["drupal/core-recommended"]' composer.json
^11.4permite 11.5 y 11.6 sin tocar nada:composer updatelos instala.~11.4.0o11.4.*fija la rama. Recibes los parches de 11.4, pero nunca vas a saltar a 11.5 sin editar el archivo.11.4.12exacto es peor: ni siquiera recibes los parches de 11.4.
Tercero, qué te impide subir. Cuando la versión objetivo ya exista:
composer why-not drupal/core-recommended 11.5.0
Eso lista los paquetes que bloquean el salto: un módulo contrib sin compatibilidad, una librería PHP vieja, un tema. Sale más barato saberlo en noviembre que en abril.
Plan de mantenimiento con ventanas de 8 meses
La regla práctica cabe en una línea: tienes dos meses desde el lanzamiento de la menor siguiente para dejar la anterior. No ocho. Los ocho son la vida total de la rama nueva.
Un ritmo que funciona en equipos pequeños:
- Semana 0, en copia.
composer update "drupal/core-*" --with-all-dependencies,drush updatedb -y,drush cache:rebuild. Revisar el reporte de estado, las pruebas de regresión y los módulos que tocan la base. - Semana 2 a 4, a producción. Con ventana anunciada y plan de reversa. Si el sitio vende, evita el cierre de mes y las temporadas altas.
- Semana 8, fecha límite. Si no desplegaste, la rama anterior ya está fuera de soporte y cualquier falla que aparezca te deja sin parche.
Dos advertencias:
- Cambiar de menor dentro de la misma mayor es barato. 11.4 a 11.5 comparte PHP soportado: 8.3, 8.4 y 8.5. El salto es de dependencias y de código deprecado, no de plataforma.
- Cambiar de mayor no es barato. Drupal 12 exige PHP 8.5, Symfony 8.1 y mínimos de base de datos más altos, y su sistema de actualización rechaza sitios que vengan de 11.2 o antes (requisitos de PHP). Si tu hosting no puede con PHP 8.5 antes de abril de 2027, la decisión sensata es seguir en 11.5 y 11.6 —que te llevan hasta febrero de 2028— y planear 12 con tiempo, no forzarlo en el peor momento.
Por eso un plan serio agenda el corte de la rama anterior, no el lanzamiento de la nueva: esa fecha es la que obliga a mover el sitio.
Automatiza la vigilancia
Tres capas, de menor a mayor cobertura.
1. Composer audit. Es el reemplazo moderno de drush pm:security, que quedó marcado como legacy en la documentación de Drupal. Audita los paquetes instalados y también las librerías PHP que no son de Drupal:
composer audit
composer audit --locked # audita composer.lock, útil en CI
La diferencia importa: --locked revisa el repositorio; sin la bandera, revisa lo instalado. Un lockfile limpio no prueba que producción recibió la actualización.
2. Un cron que falle en voz alta. El error típico no es no tener monitor, es tener uno que reporta "todo bien" cuando no pudo conectarse:
#!/usr/bin/env bash
set -euo pipefail
cd /var/www/mi-sitio
composer audit --format=json > /tmp/audit.json || true
total=$(jq '.advisories | length' /tmp/audit.json)
if [ "$total" -gt 0 ]; then
jq -r '.advisories | to_entries[] | "\(.key): \(.value[0].title)"' /tmp/audit.json
exit 1
fi
Con set -euo pipefail, si composer o jq fallan, el script termina con error y tu sistema de alertas lo ve. Vigila también que el cron haya corrido: la ausencia de alerta no es lo mismo que la ausencia de problemas.
3. Las fuentes oficiales. updates.drupal.org/psa.json publica los PSA críticos en JSON, y drupal.org/security/rss.xml y drupal.org/security/psa/rss.xml sirven para enganchar un feed a Slack o a un tablero. El módulo Update de cada sitio sigue siendo la red de seguridad, pero solo funciona si el cron del sitio corre y si alguien lee el correo.
composer audit solo ve lo que Composer administra: un módulo copiado a mano, un parche aplicado con patch o código propio con una falla no aparecen ahí. La auditoría de dependencias no sustituye la revisión de código.
Preguntas frecuentes
¿Cuánto dura el soporte de seguridad de Drupal 11?
La versión mayor, hasta diciembre de 2028. Pero cada menor dentro de 11 tiene ocho meses: 11.4 termina el 21 de abril de 2027, 11.5 en agosto de 2027 y 11.6 en febrero de 2028. Estar en Drupal 11 no garantiza nada si la rama puntual ya venció.
¿Puedo saltarme una versión menor?
Sí, pero cada salto acumula dependencias y código deprecado que probarás de una vez. Drupal 12 exige al menos 11.3 para actualizar, así que un sitio muy atrasado primero debe llegar a una rama intermedia. Saltar rara vez ahorra tiempo.
¿El cambio afecta a Drupal 10?
No en la forma de la PSA: Drupal 10 tiene fecha de fin de vida el 9 de diciembre de 2026 y después no habrá más lanzamientos. Si tienes un sitio en 10.6, el problema no es la ventana de ocho meses, es que se te acabó el plazo para migrar a 11.
¿Basta con tener activo el módulo Update?
No. Update te dice si hay versiones nuevas, no si tu rama sigue soportada, y depende de que el cron del sitio corra. Úsalo como red de seguridad por sitio, pero lleva el calendario de ramas aparte y automatiza la consulta de advisories con composer audit.
¿Qué pasa si el sitio queda fuera de soporte?
No recibirá parches de seguridad de core para esa rama, y los módulos contrib que dependan de versiones nuevas pueden volverse incompatibles. La salida es actualizar a una rama soportada, con más pruebas y más riesgo que si lo hubieras hecho dentro de la ventana. Cuanto más tiempo pase, más caro sale.
Qué hacer esta semana
Abre composer.json y confirma la restricción de drupal/core-recommended. Si dice ^11.4 o ~11.4.0, agenda el salto a 11.5 antes del 7 de diciembre; si el sitio sigue en Drupal 10.6, la prioridad es migrar, porque esa rama deja de recibir lanzamientos el 9 de diciembre de 2026. Anota ambas fechas y ejecuta composer why-not drupal/core-recommended 11.5.0 para ver qué falta destrabar.
