# Servidor Plesk: comprobar y parchear las versiones de PHP

> Actualizar PHP en Plesk tras PHP2Shell: compruebe manejadores, paquetes y backports, reinicie todos los servicios PHP-FPM y documente el parche con pruebas.

Fuente: https://phpsos.de/es/server/plesk/  
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:** una actualización de PHP en Plesk solo está terminada cuando cada versión de PHP instalada está en un estado corregido, todos los servicios PHP-FPM se han reiniciado y usted puede demostrarlo con el estado de los paquetes y la hora de inicio de los procesos. El número de versión que muestra el panel no basta, porque los backports suelen dejarlo sin cambios.

## De qué trata PHP2Shell en los servidores Plesk

PHP2Shell designa dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 de 9,2). Permiten a los atacantes ejecutar código en el servidor sin autenticarse. Afectan, entre otros, a PHP-FPM y a Apache con mod_php, es decir, justo los modos de funcionamiento que Plesk configura para los sitios web.

El 21/10/2026, el proyecto PHP publicó las versiones corregidas 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales. Los servidores Plesk tienen una particularidad: en ellos suelen funcionar varias versiones de PHP a la vez, unas instaladas por Plesk y otras por el sistema operativo. Cada una de ellas necesita su propia comprobación.

> **Importante:**
> Una actualización desde el panel sustituye archivos en el disco. Mientras sigan en memoria procesos PHP antiguos, la vulnerabilidad sigue abierta. Sin reiniciar todos los procesos de trabajo, el parche no es efectivo.

## Actualizar PHP en Plesk: primero, el inventario

Antes de actualizar nada, haga una lista de todos los manejadores de PHP y de los dominios que los usan. Puede hacerlo desde el panel (Herramientas y configuración, Configuración de PHP) o por línea de comandos. Los comandos siguientes no modifican nada, solo leen.

```bash
# Todos los manejadores de PHP registrados, con versión y ruta
plesk bin php_handler --list

# Versión de cada PHP instalado por Plesk (ruta a modo de ejemplo)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
```

Anote para cada manejador: versión, modo de funcionamiento (FPM, FastCGI, módulo de Apache) y número de dominios. Que un manejador no tenga dominios no es motivo para bajar la guardia: puede asignarse más adelante o estar funcionando en subdominios de prueba.

## Comprobar el estado de los paquetes, no la indicación en pantalla

Plesk muestra el número de versión que informa el propio PHP. Si Plesk o la distribución entregan la corrección como backport, puede seguir apareciendo, por ejemplo, 8.2.34 aunque la corrección esté incluida. Al revés, un número aparentemente actual puede engañar si un paquete aún no se ha actualizado. Lo decisivo son el estado de los paquetes instalados y la confirmación escrita del proveedor.

```bash
# Debian/Ubuntu (nombres de paquetes a modo de ejemplo)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (nombres de paquetes a modo de ejemplo)
rpm -qa | grep -E 'plesk-php|^php' | sort
```

Compare las versiones de los paquetes con las indicaciones de los registros de cambios de Plesk y con los avisos de su distribución. Si no consta de forma inequívoca que CVE-2026-109618 y CVE-2026-109619 están corregidas, pregunte al proveedor. Encontrará una plantilla en [Preguntar al hosting por el estado del parche](https://phpsos.de/es/ratgeber/hoster-patch-status-erfragen/).

## Instalar la actualización y reiniciar todos los procesos de trabajo

La actualización propiamente dicha se hace con el instalador de Plesk o con el gestor de paquetes del sistema. Después viene el paso que más se olvida: el reinicio. En Plesk, cada versión de PHP tiene su propio servicio FPM. Reinicie todos, no solo el del dominio principal.

```bash
# Listar todos los servicios PHP-FPM (nombres de servicio a modo de ejemplo)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Reiniciar cada servicio, por ejemplo:
systemctl restart plesk-php84-fpm

# Comprobar la hora de inicio de los procesos PHP en ejecución
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
```

Si un dominio funciona con Apache y mod_php, reinicie Apache por completo. Si la hora de inicio de un proceso PHP es anterior a la actualización, ese proceso aún no se ha renovado. Encontrará más sobre este paso en [Reiniciar PHP-FPM y todos los procesos de trabajo](https://phpsos.de/es/php2shell/php-fpm-neustart/).

## Protección provisional mientras falta la actualización

Si para una versión todavía no hay parche, php.net recomienda medidas provisionales. No son una protección completa. En Plesk, los valores que las aplicaciones no deben sobrescribir se fijan como `php_admin_value` en las directivas FPM adicionales del dominio o, para todo el servidor, en el php.ini de la versión correspondiente.

```ini
; Ejemplo de directivas PHP-FPM adicionales en Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
```

Con cargas de archivos, según php.net está previsto `post_max_size = 32M`, con `upload_max_filesize` por debajo. En PHP 8.5 se añade `fatal_error_backtraces=0`. El límite de memoria mediante `memory_limit=-1` solo debe usarse junto con un límite a nivel de contenedor o de cgroup. Después hay que volver a reiniciar todos los procesos de trabajo. Los detalles están en [Medidas inmediatas sin parche](https://phpsos.de/es/php2shell/sofortmassnahmen-ohne-patch/). El BSI recomienda desconectar temporalmente de la red los servidores web si la actualización no es posible de inmediato.

## Después del parche: conservar los registros y buscar rastros

Un parche cierra la vulnerabilidad de cara al futuro. No elimina el software malicioso que se haya introducido antes ni demuestra que no haya pasado nada. Por eso conserve los registros del servidor web desde el 20/10/2026. Plesk los guarda por dominio en el directorio `logs`; en esta situación, no acorte el periodo de conservación.

Preste atención a archivos PHP nuevos o modificados en los directorios de cargas, a tareas programadas desconocidas y a nuevas cuentas de administrador. Hasta ahora no hay indicadores de compromiso (IoC) publicados y confirmados; la detección se basa en el análisis de comportamiento. Si encuentra anomalías, no siga trabajando por su cuenta: asegure primero el estado del sistema.

## ¿Cómo ayuda PHP SOS en concreto?

- Registramos todos los manejadores de PHP de su servidor Plesk, asignamos los dominios y comprobamos el estado real de los paquetes de cada versión.
- Dentro de nuestro [servicio de parcheo de PHP](https://phpsos.de/es/leistungen/php-patch-service/) instalamos las actualizaciones, reiniciamos todos los servicios y documentamos las horas de inicio de los procesos como prueba.
- Donde falta un parche, aplicamos las medidas provisionales de php.net para todo el servidor y sin posibilidad de sobrescribirlas.
- Conservamos los registros y buscamos rastros de un compromiso; si hay hallazgos, con [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/).
- Después reforzamos el servidor de forma duradera y eliminamos las versiones de PHP que no se necesitan.


## Preguntas frecuentes

**¿Por qué Plesk sigue mostrando PHP 8.2.34 después de la actualización?**  
Las distribuciones y los proveedores a veces instalan las correcciones de seguridad como backport sin cambiar el número de versión. Entonces lo determinante son el estado de los paquetes y la confirmación del proveedor. La indicación en pantalla, por sí sola, no prueba ni que el parche esté aplicado ni que falte.

**¿Basta con hacer clic en Actualizar en el panel de Plesk?**  
La actualización deja archivos nuevos, pero los procesos PHP en ejecución siguen trabajando en memoria con el código antiguo. Solo tras reiniciar todos los servicios PHP-FPM y el servidor web queda activo el nuevo estado. Después compruebe la hora de inicio de los procesos.

**¿También tengo que parchear las versiones de PHP que no usa ningún dominio?**  
Sí, mientras sigan instaladas. Un manejador sin uso puede asignarse por error más adelante o ser accesible a través de entornos de prueba. Lo mejor es desinstalar por completo las versiones que no se necesiten.

**¿Sirve una actualización de WordPress en el Toolkit de Plesk contra PHP2Shell?**  
No. PHP2Shell afecta a PHP en sí, no al CMS. Actualizar el CMS sigue siendo recomendable, pero no cierra esta vulnerabilidad.

## Fuentes

- [php.net: avisos de seguridad](https://www.php.net/)
- [Registro de cambios de PHP 8](https://www.php.net/ChangeLog-8.php)
- [php.net: versiones compatibles](https://www.php.net/supported-versions.php)
- [BSI (Oficina Federal Alemana de Seguridad de la Información)](https://www.bsi.bund.de/)