# Tras la actualización: reiniciar PHP-FPM y todos los workers > Reiniciar PHP-FPM tras la actualización de PHP2Shell: por qué no bastan los archivos nuevos, qué servicios cuentan y cómo comprobar que no queda ningún worker antiguo. Fuente: https://phpsos.de/es/php2shell/php-fpm-neustart/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** Tras la actualización de PHP debe reiniciar PHP-FPM y todos los demás servicios que cargan PHP. Los archivos nuevos en el disco no bastan mientras haya procesos antiguos de PHP en memoria. Solo tras el reinicio trabaja el servidor con el código corregido de PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o con el backport de su proveedor. ## Por qué debe reiniciar PHP-FPM Una actualización de paquetes sustituye los archivos del disco. Pero los procesos que ya están en ejecución han cargado en memoria el código antiguo del programa y siguen trabajando con él. PHP-FPM, Apache con mod_php o LiteSpeed mantienen vivos sus workers a menudo durante días. Para PHP2Shell esto es especialmente importante. La vulnerabilidad [CVE-2026-109619](https://phpsos.de/es/php2shell/cve-2026-109619/) depende justamente del estado que persiste entre peticiones en el mismo worker. Un worker con código antiguo sigue siendo vulnerable, sea cual sea la versión que haya en el disco. Según php.net, por eso deben reiniciarse todos los workers y procesos. Algunos gestores de paquetes reinician los servicios automáticamente durante la actualización, otros no. No se fíe de ello, sino compruebe el resultado. Una imagen típica del día a día: el gestor de paquetes informa «PHP actualizado», la monitorización no muestra errores, el sitio web funciona. Y aun así, los workers antiguos siguen atendiendo cada petición, porque nadie ha reiniciado el servicio. Desde fuera, este estado no se reconoce. Por eso, la comprobación de las horas de inicio de los procesos forma parte de toda actualización. ## ¿Qué servicios cargan PHP? | Modo de ejecución | Qué reiniciar | Comando típico (los nombres varían según la distribución) | |---|---|---| | PHP-FPM | cada servicio FPM, por cada versión instalada | `systemctl restart php8.3-fpm` o `systemctl restart php-fpm` | | Apache con mod_php | Apache | `systemctl restart apache2` o `systemctl restart httpd` | | php-cgi | el servidor web que lo llama o el wrapper de FastCGI | según la configuración | | LiteSpeed | LiteSpeed y los procesos lsphp | mediante la administración de LiteSpeed o su servicio | | FrankenPHP | el servicio de FrankenPHP o el contenedor | `systemctl restart frankenphp` o volver a crear el contenedor | | Docker, Kubernetes | volver a crear los contenedores desde la imagen nueva | véase [Parchear PHP en contenedores Docker](https://phpsos.de/es/php2shell/docker-container-patchen/) | Con mod_php vale: la actualización afecta al propio Apache, porque PHP está en cada proceso de Apache. Por qué este modo de ejecución es especialmente delicado se explica en [Por qué mod_php soporta el mayor riesgo](https://phpsos.de/es/php2shell/mod-php-risiko/). Para LiteSpeed encontrará detalles en la página [LiteSpeed y LSAPI](https://phpsos.de/es/server/litespeed/). ## Reiniciar PHP-FPM: los comandos Primero localice todos los servicios de PHP del servidor. Plesk, cPanel y otras interfaces traen servicios de PHP propios con nombres propios; la lista también los muestra. ```bash systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd" ``` Después reinicie cada servicio de PHP encontrado, no solo el primero: ```bash sudo systemctl restart php8.3-fpm sudo systemctl restart php8.2-fpm # si hay instalada una segunda rama sudo systemctl restart apache2 # con mod_php; familia RHEL: httpd ``` Recomendamos `restart` en lugar de `reload`. Con reload, el proceso principal permanece; está pensado para cambios de configuración. Tras una actualización de seguridad, usted quiere estar seguro de que cada proceso es nuevo. > **Importante:** > Si ha aplicado además medidas provisionales como `session.upload_progress.enabled=0` o límites de memoria fijos, estas también surten efecto solo tras el reinicio. Un reinicio resuelve ambas cosas en un solo paso. ## Comprobar que ya no queda ningún worker antiguo Compare la hora de inicio de los procesos con el momento de la actualización. Todos los comandos son de solo lectura. ```bash ps -o pid,lstart,cmd -C php-fpm8.3 # en RHEL: -C php-fpm systemctl status php8.3-fpm # línea «Active: … since …» needrestart -r l # Debian/Ubuntu, si está instalado ``` Si un proceso es más antiguo que la actualización, no se ha reiniciado. Causas frecuentes son una segunda rama de PHP olvidada, un servicio de pool propio de un panel de hosting o un contenedor que solo se reinició en lugar de crearse desde la imagen nueva. Qué versión se está ejecutando lo muestra la página [Comprobar correctamente la versión de PHP y el estado del parche](https://phpsos.de/es/php2shell/php-version-pruefen/). ## Documentar el reinicio Anote para cada servidor el momento de la actualización y del reinicio. Ese instante separa el tiempo en que el servidor fue vulnerable del tiempo posterior. Para una posterior revisión de rastros, para las aseguradoras y para una posible notificación conforme al RGPD, es el punto de referencia más importante. Conserve además los registros del servidor desde el 20 de octubre, como recomienda la prensa especializada. En servidores con muchos sitios web merece la pena una tabla breve: servidor, servicio, versión de PHP, versión del paquete, momento del reinicio y persona que reinició. Así se detectan rápido las lagunas de cobertura, por ejemplo un pool que se pasó por alto o un sistema de pruebas que nadie tenía en la lista. ## ¿Cómo ayuda PHP SOS en concreto? En el marco del [servicio de parcheo de PHP](https://phpsos.de/es/leistungen/php-patch-service/) asumimos la actualización y el reinicio como un proceso unitario: - **Determinar los servicios:** encontramos todos los procesos que cargan PHP, también los de paneles de hosting y contenedores. - **Reiniciar de forma controlada,** de acuerdo con usted, en un momento adecuado y teniendo en cuenta los pedidos o formularios en curso. - **Comprobar después** que ningún proceso es más antiguo que la actualización y que el sitio web responde con normalidad. - **Documentar:** versiones, estados de paquete y momentos de reinicio de cada servidor. ## Preguntas frecuentes **¿Basta con systemctl reload en lugar de restart?** Para PHP2Shell recomendamos restart. Un reload suele reiniciar los workers, pero el proceso principal puede seguir en ejecución. Con restart se asegura de que no queda ningún proceso con código antiguo. A la breve interrupción se contrapone una prueba clara. **¿Tengo que reiniciar todo el servidor tras la actualización de PHP?** Por lo general, no. Basta con reiniciar todos los servicios que cargan PHP: PHP-FPM, Apache en el caso de mod_php, LiteSpeed, FrankenPHP o los contenedores afectados. Reiniciar todo el servidor es la variante sencilla si no está seguro de qué servicios usan PHP. **¿Reinicia mi proveedor de hosting PHP automáticamente tras la actualización?** Depende del proveedor. Pregunte de forma concreta si tras el parche se han reiniciado todos los procesos de PHP y pida que se lo confirmen por escrito. ## Fuentes - [php.net: avisos de seguridad](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)