En resumen: con unattended-upgrades en Debian y Ubuntu y dnf-automatic en la familia RHEL, los servidores Linux instalan por sí mismos las actualizaciones de seguridad. Para que una actualización surta efecto, los servicios afectados, como PHP-FPM, deben reiniciarse después; compruébelo con needrestart o con las horas de inicio de los procesos. Las fuentes de terceros como sury.org deben liberarse expresamente; los contenedores y los cambios de versión principal no los cubre la automatización.
Del parche al servidor: la automatización ahorra tiempo
Cuando php.net publicó el 21 de octubre de 2026 a las 16:00 (hora alemana) los parches contra PHP2Shell, empezó una carrera para los administradores. Según informes, las distribuciones entregaron sus backports en parte el mismo día. Los servidores con actualizaciones de seguridad automáticas pudieron instalar los paquetes nuevos en la siguiente ejecución programada, sin que nadie tuviera que intervenir.
Esa es la buena noticia. La menos buena: instalado no significa efectivo. Un servicio PHP-FPM que lleva semanas en marcha sigue trabajando con el código antiguo en memoria hasta que se reinicia. Y los paquetes de fuentes de terceros, los contenedores o los paneles de hosting con gestión propia de PHP suelen quedar al margen de la automatización.
Este artículo muestra cómo configurar actualizaciones de seguridad automáticas y complementarlas para que protejan de verdad en caso de emergencia.
unattended-upgrades en Debian y Ubuntu
En Ubuntu, el paquete unattended-upgrades viene instalado por defecto e instala las actualizaciones de seguridad. En Debian se instala si hace falta. Se controla mediante dos archivos en /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
El archivo 20auto-upgrades determina si se actualizan las listas de paquetes y se instalan actualizaciones, y con qué frecuencia. El valor es el número de días; "1" significa a diario:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
En 50unattended-upgrades figura de qué fuentes pueden venir las actualizaciones, si se reinicia después y quién recibe un aviso. Por defecto solo están liberadas las fuentes de seguridad oficiales de la distribución. Según la documentación de Ubuntu, no basta con incorporar otro repositorio: además debe figurar en esta lista; de lo contrario, la automatización lo ignora. Esto afecta, por ejemplo, al repositorio de terceros sury.org, que según informes ha proporcionado compilaciones de PHP para todas las ramas, de la 5.6 a la 8.5. Los antecedentes figuran en el artículo El repositorio sury.org.
Una ejecución de prueba que no cambia nada muestra si todo está bien:
sudo unattended-upgrade -v --dry-run
# Registros de las ejecuciones reales
ls -l /var/log/unattended-upgrades/
dnf-automatic en RHEL, AlmaLinux y Rocky Linux
En la familia RHEL, dnf-automatic asume la misma tarea. La configuración está en /etc/dnf/automatic.conf. Según la documentación, upgrade_type = security comprueba solo las actualizaciones con aviso de seguridad, y apply_updates está desactivado por defecto.
# /etc/dnf/automatic.conf (extracto)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Además de dnf-automatic.timer, que sigue el archivo de configuración, existen temporizadores que solo notifican, solo descargan o instalan siempre. Para empezar, el temporizador con archivo de configuración es el más fácil de seguir.
La parte infravalorada: reiniciar los servicios
El gestor de paquetes sustituye archivos en el disco. Los procesos en ejecución conservan el código antiguo en memoria. En PHP esto significa: mientras PHP-FPM, o Apache con mod_php, no se hayan reiniciado, la brecha sigue abierta.
| Herramienta | Sistema | Qué hace |
|---|---|---|
| needrestart | Debian, Ubuntu | detecta servicios con archivos obsoletos; en Ubuntu, desde 24.04, los reinicia automáticamente por defecto |
dnf needs-restarting -s |
familia RHEL | lista los servicios que deberían reiniciarse |
Automatic-Reboot |
unattended-upgrades | reinicia el servidor cuando una actualización lo exige; desactivado por defecto |
reboot |
dnf-automatic | never, when-changed o when-needed |
Según la documentación de Ubuntu, los servicios exceptuados por needrestart siguen funcionando con archivos antiguos hasta el reinicio manual. Por eso, tras cada actualización de PHP, compruebe la hora de inicio de los procesos, como se describe en Reiniciar PHP-FPM y todos los workers.
Con los backports, el número de versión de PHP mostrado suele seguir siendo el mismo. El parche se acredita mediante el changelog del paquete con los números CVE, por ejemplo con apt-get changelog o rpm -q --changelog. Cómo hacerlo en detalle lo muestra Debian y Ubuntu: ¿está parcheado mi paquete de PHP?.
Lo que la automatización no cubre
Las actualizaciones automáticas son una pieza, no una gestión de parches completa. Algunas áreas necesitan procesos propios:
- Contenedores: PHP en imágenes Docker no se actualiza con las actualizaciones del host. Reconstruir las imágenes y recrear los contenedores.
- Paneles de hosting: Plesk, cPanel y paneles similares gestionan PHP en parte mediante paquetes y mecanismos propios.
- Versiones principales: el paso, por ejemplo, de PHP 8.2, que alcanza el fin del soporte el 31/12/2026, a una versión más reciente no ocurre automáticamente.
- Aplicaciones: los CMS, plugins y dependencias de Composer tienen sus propios caminos de actualización.
- Control: alguien debe leer los registros y mensajes de error de la automatización. Una ejecución que falla en silencio es peor que ninguna, porque simula seguridad.
Cómo estas piezas se convierten en un proceso lo describe Gestión de parches como proceso en lugar de bomberos.
Conclusión: automatización sí, confianza ciega no
Las actualizaciones de seguridad automáticas pertenecen a todo servidor Linux accesible desde internet. PHP2Shell ha demostrado lo escaso que puede llegar a ser el tiempo: según informes de los medios, ya el 17 de octubre se observó un primer intento de ataque, cuatro días antes de los parches. Quien después sigue esperando a una ventana de mantenimiento manual pierde un tiempo valioso.
Pero la automatización solo le quita la instalación. El reinicio de los servicios, la acreditación del nivel de parcheo, los contenedores, los paneles y el cambio a tiempo a versiones con soporte siguen siendo tareas de las que alguien debe ser responsable. Fije esa responsabilidad por escrito y compruebe por muestreo si los registros de la automatización se leen realmente. Solo la combinación de automatización y control hace fiables las actualizaciones.
¿Cómo ayuda PHP SOS en concreto?
- Configurar: configuramos unattended-upgrades o dnf-automatic de acuerdo con sus servidores, incluidas las fuentes de terceros liberadas.
- Asegurar los reinicios: configuramos needrestart o comprobaciones equivalentes y, tras las actualizaciones de PHP, controlamos las horas de inicio de los procesos.
- Cerrar las lagunas: incorporamos contenedores, paneles y cambios de versión principal a un ciclo de mantenimiento fijo.
- Controlar: en el contrato de mantenimiento de seguridad revisamos los registros de la automatización y notificamos las anomalías.
Preguntas frecuentes
¿No son demasiado arriesgadas las actualizaciones automáticas en servidores de producción?
Limitadas a las actualizaciones de seguridad de la distribución, el riesgo suele ser menor que el de una vulnerabilidad abierta. Estas actualizaciones no deben traer funciones nuevas, sino corregir errores. Para sistemas críticos se añaden copias de seguridad, monitorización y un sistema de pruebas.
¿Reinicia unattended-upgrades PHP-FPM tras una actualización?
No necesariamente por sí mismo. En Ubuntu, desde la versión 24.04, la herramienta needrestart reinicia automáticamente por defecto los servicios afectados, pero los servicios exceptuados siguen funcionando con archivos antiguos. Tras cada actualización de PHP, compruebe la hora de inicio de todos los procesos de PHP.
¿Se actualizan automáticamente los paquetes de sury.org u otras fuentes de terceros?
Solo si libera expresamente la fuente. Según la documentación de Ubuntu, no basta con añadir un repositorio; además debe figurar en la lista de orígenes permitidos de unattended-upgrades.
¿Sube la automatización también de PHP 8.2 a 8.3?
No. Las actualizaciones de seguridad automáticas se mantienen dentro de las versiones de paquete instaladas. Un cambio de versión principal de PHP, por ejemplo antes del fin del soporte de PHP 8.2 el 31/12/2026, sigue siendo un proyecto planificado con pruebas.
¿Y los contenedores Docker?
Las actualizaciones en el host no actualizan la versión de PHP dentro de los contenedores. Las imágenes de contenedor deben reconstruirse o volver a descargarse y los contenedores recrearse.