# Varias versiones de PHP en un servidor: parchear cada una por separado > Varias versiones de PHP en un servidor: localice todas las instalaciones, aclare origen y responsable, parchee cada una, reinicie y deje constancia. Fuente: https://phpsos.de/es/blog/mehrere-php-versionen-server/ 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:** Si en un servidor conviven varias versiones de PHP, tras PHP2Shell hay que comprobar, actualizar y reiniciar cada una por separado. Las fuentes típicas son el sistema operativo, paneles de alojamiento como Plesk o cPanel, fuentes de terceros como sury.org o Remi, CloudLinux, LiteSpeed y versiones compiladas a mano. Solo una lista completa elaborada a partir de paquetes, archivos y procesos en ejecución muestra si realmente no se ha pasado por alto ninguna versión. ## La versión olvidada Un servidor que lleva varios años en marcha acumula versiones de PHP como un desván muebles viejos. El panel trajo tres ramas, para un cliente se añadió una versión más antigua de una fuente de terceros y el sistema operativo tiene la suya. Cada una se instaló un día por una buena razón. Pero hoy nadie sabe ya cuál sigue haciendo falta. Tras PHP2Shell, eso es precisamente un problema. Las correcciones aparecieron el 21 de octubre de 2026 para PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Pero cada instalación del servidor las recibe por su propio camino, de su propio responsable del paquete y en su propio momento. Para PHP 8.1 y anteriores solo hay backports mínimos del código fuente. Quien actualiza solo la versión principal deja abiertas las demás. ## De dónde salen tantas versiones La siguiente tabla recoge las fuentes típicas y rutas de ejemplo. Las rutas exactas varían según la versión y la distribución. | Fuente | Ruta de ejemplo | Quién entrega el parche | |---|---|---| | Sistema operativo Debian/Ubuntu | `/usr/bin/php8.3`, `/etc/php/8.3/` | Distribución | | Sistema operativo familia RHEL | `/usr/bin/php`, `/etc/php-fpm.d/` | Distribución | | Plesk | `/opt/plesk/php/8.3/` | Plesk | | cPanel (EasyApache 4) | `/opt/cpanel/ea-php83/` | cPanel | | CloudLinux alt-php | `/opt/alt/php83/` | CloudLinux | | Remi Software Collection | `/opt/remi/php83/` | Remi | | sury.org | `/usr/bin/php8.3` como en el sistema | sury.org | | LiteSpeed | `/usr/local/lsws/lsphp83/` | LiteSpeed o la fuente del paquete | | Compilado a mano | a menudo `/usr/local/bin/php` | Usted mismo | | Contenedor | dentro de la imagen | Editor de la imagen; reconstrucción por su parte | Los paquetes de sury.org son especialmente traicioneros, porque usan las mismas rutas que la distribución. Si un `php8.3` procede de Debian o de sury.org solo lo muestra la fuente del paquete. Las particularidades las describen los artículos [El repositorio sury.org](https://phpsos.de/es/blog/sury-repository-php/) y [El repositorio Remi](https://phpsos.de/es/blog/remi-repository-php/). Cómo gestiona Plesk sus versiones lo describe la página [Servidor Plesk: comprobar y parchear versiones de PHP](https://phpsos.de/es/server/plesk/). ## Localizar todas las instalaciones de PHP Una lista fiable surge de tres perspectivas. Los comandos son de solo lectura y, según el servidor, pueden tardar un rato. ```bash # 1. Paquetes: lo que conoce la gestión de paquetes dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp" rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort # 2. Archivos: binarios de PHP ejecutables, también fuera de la gestión de paquetes find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null # 3. Procesos: lo que se está ejecutando de verdad, con hora de inicio ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp" ``` Contraste las tres listas. Un archivo sin paquete apunta a una versión compilada a mano o copiada manualmente. Un proceso sin archivo correspondiente puede indicar una instalación borrada pero todavía en ejecución. En Apache, compruebe además si hay un módulo de PHP cargado, por ejemplo con `apache2ctl -M` o `httpd -M`. Los contenedores y los pods de Kubernetes solo aparecen en parte en estas listas y requieren una revisión propia de las imágenes. ## Parchear cada versión por separado Cuando cada instalación tiene una línea en su lista, para cada una sigue el mismo procedimiento: 1. **Aclarar la responsabilidad:** ¿el parche viene de la distribución, del panel, de una fuente de terceros o de usted mismo? 2. **Valorar el nivel:** versión corregida oficial, backport confirmado, sin aclarar o abierto. 3. **Actualizar:** por el camino de la fuente correspondiente, no por otro. 4. **Reiniciar:** el servicio de esa versión, no solo el servicio principal. Con mod_php, el servidor web. Los detalles figuran en [Reiniciar PHP-FPM y todos los workers](https://phpsos.de/es/php2shell/php-fpm-neustart/). 5. **Comprobar:** comparar la hora de inicio de los procesos con el momento de la actualización. 6. **Documentar:** versión, nivel del paquete, justificante, hora del reinicio. Para las versiones sin parche, hasta la migración valen las medidas provisionales de php.net. Aplíquelas por separado en cada versión, porque cada instalación tiene su propio php.ini y sus propios pools. > **Importante:** > No olvide la línea de comandos. Las tareas cron y los scripts suelen ejecutarse con una versión de PHP distinta de la del sitio web. También esa versión debe estar en un nivel corregido, aunque no procese peticiones web. ## ¿Qué versión usa la línea de comandos y cuál el contenedor? Hay dos ámbitos que con especial frecuencia se escapan a la búsqueda. El primero es la línea de comandos. En Debian y Ubuntu, el sistema de alternativas decide qué binario hay detrás del comando `php`. `update-alternatives --display php` muestra qué versiones están registradas y cuál rige en este momento. Las tareas cron que llaman a una ruta fija como `/usr/bin/php7.4`, sin embargo, eluden este ajuste. Por eso merece la pena echar un vistazo a los crontabs de todos los usuarios y a la configuración de los paneles que crean sus propias tareas cron. El segundo ámbito son los contenedores. Un contenedor Docker en el servidor trae su propia versión de PHP, que no aparece en ninguna lista de paquetes del host. `docker ps` muestra los contenedores en ejecución; si contienen PHP y en qué versión lo revela un vistazo a la imagen o un `php -v` dentro del contenedor. El parche no se aplica allí en el host, sino reconstruyendo la imagen y sustituyendo el contenedor. ## Menos es más seguro La mejor comprobación es la que no hace falta hacer. Cada versión de PHP instalada duplica el esfuerzo ante la siguiente vulnerabilidad. Tras PHP2Shell conviene por ello una regla clara: cada versión del servidor necesita un propósito y un responsable. Lo que no los tiene se desactiva primero y, tras un período de observación, se elimina. Más información en el artículo [Desactivar versiones antiguas de PHP en el panel de alojamiento](https://phpsos.de/es/blog/alte-php-versionen-abschalten/). ## ¿Cómo ayuda PHP SOS en concreto? - Elaboramos para sus servidores una lista completa de todas las instalaciones de PHP a partir de paquetes, archivos, procesos y contenedores. - Aclaramos para cada versión el origen, la responsabilidad y el nivel de parcheo. - En el marco del [servicio de parcheo de PHP](https://phpsos.de/es/leistungen/php-patch-service/) actualizamos cada versión, reiniciamos cada servicio y dejamos constancia del nivel. - Junto con usted decidimos qué versiones se quedan y eliminamos las demás de forma controlada. ## Preguntas frecuentes **¿Por qué hay varias versiones de PHP en mi servidor?** Los motivos más habituales son los paneles de alojamiento, que traen sus propias compilaciones de PHP, fuentes de terceros como sury.org o Remi para versiones más recientes y aplicaciones antiguas que necesitan una versión concreta. A menudo se suma la versión de PHP del sistema operativo. **¿Es peligrosa una versión de PHP que ningún sitio web utiliza?** Mientras esté instalada y activa como servicio, puede ser accesible, por ejemplo a través de un dominio de prueba, un pool olvidado o una tarea cron. Además, más adelante puede asignarse por error a un sitio web. Debería eliminar las versiones que no necesite. **¿Cómo encuentro todas las instalaciones de PHP en un servidor Linux?** Combine tres perspectivas: paquetes instalados, archivos ejecutables de PHP en el sistema de archivos y procesos en ejecución. Solo cuando las tres ofrecen la misma imagen, la lista está completa. **¿Debo reiniciar cada versión por separado tras la actualización?** Sí. Por lo general, cada versión tiene su propio servicio FPM, LiteSpeed tiene sus propios procesos lsphp y mod_php vive dentro del proceso de Apache. Reiniciar el servicio principal no renueva los demás. ## Fuentes - [php.net: avisos de seguridad](https://www.php.net/) - [php.net: versiones compatibles](https://www.php.net/supported-versions.php) - [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)