Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Plesk: entender los handlers de PHP (FPM, FastCGI, módulo de Apache)

El handler de PHP que Plesk usa para un sitio web decide el aislamiento, la configuración y el riesgo. Una comparación pensando en PHP2Shell.

Actualizado 6 min de lecturaHosting y distribuciones

En resumen: El handler de PHP de Plesk determina cómo funciona PHP para un sitio web: como aplicación FPM con pool compartido, como Dedicated FPM con un pool propio por sitio, como aplicación FastCGI o como módulo de Apache (mod_php). Desde el punto de vista de la seguridad, Dedicated FPM suele ser la mejor opción en Linux y el módulo de Apache la peor. El propio Plesk lo califica de obsoleto o inseguro, y en PHP2Shell el equipo de PHP ve el mayor riesgo precisamente en mod_php.

Por qué el handler es más que una cuestión de rendimiento

En Plesk se elige para cada sitio web una versión de PHP y un handler. Muchos tratan el handler como un detalle de rendimiento y memoria. Pero también decide el grado de separación entre sitios web, dónde surten efecto los ajustes de seguridad y qué procesos hay que reiniciar tras una actualización.

Tras PHP2Shell, esta elección se vuelve concreta. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan a todos los modos de funcionamiento habituales, pero el equipo de PHP clasifica el riesgo como el más alto con mod_php. Quien aún opere en su servidor Plesk dominios con el módulo de Apache debería cambiarlo ahora. Cómo comprobar y parchear versiones lo describe la página Servidor Plesk: comprobar y parchear versiones de PHP; aquí se trata de la elección del modo de funcionamiento.

Los handlers de PHP de Plesk de un vistazo

La siguiente tabla se basa en la documentación de Plesk para Plesk Obsidian, completada con la perspectiva de seguridad. En Linux, según Plesk, los handlers FPM pueden servirse a elección a través de Apache o nginx, y FastCGI siempre a través de Apache.

Handler Servido a través de Aislamiento Recomendación según Plesk Perspectiva de seguridad
Dedicated FPM application Apache o nginx pool propio por sitio web Linux con alojamiento compartido mejor separación, valores propios por pool
FPM application Apache o nginx pool compartido por versión de PHP servidores Linux dedicados un sitio web defectuoso puede perturbar a otros con la misma versión
FastCGI application Apache (Linux) procesos permanentes, buena separación servidores Windows sólido, en Linux suele estar sustituido por FPM
Apache module (mod_php) Apache PHP en el proceso del servidor web no recomendado mayor riesgo de PHP2Shell según el equipo de PHP
CGI application Apache proceso nuevo por petición no recomendado obsoleto

Los antecedentes de los propios modos de funcionamiento los explican las páginas PHP-FPM explicado y Por qué mod_php soporta el mayor riesgo.

¿Pool compartido o propio?

La diferencia entre FPM y Dedicated FPM suele subestimarse. Con el handler FPM normal, según Plesk, todos los sitios web con la misma versión de PHP comparten un pool de procesos. Eso ahorra memoria, pero también significa que un sitio web que da problemas puede arrastrar a todos los demás con la misma versión, y que se comparte la caché.

Dedicated FPM da a cada sitio web un pool propio. Según Plesk, eso mejora el aislamiento y el rendimiento, pero cuesta más memoria. Desde la seguridad, el pool propio es la base para fijar por separado en cada sitio web ajustes como open_basedir, límites de memoria o límites de subida. Cómo separar los pools de forma consecuente lo describe el artículo Aislar los pools de PHP-FPM por sitio web.

nginx o Apache: la trampa de .htaccess

Si elige un handler que se sirve a través de nginx, cambia algo fundamental: según Plesk, estos handlers ignoran el archivo .htaccess. Lo que figura allí deja de surtir efecto.

Eso es un asunto de seguridad. Muchas aplicaciones y administradores colocan reglas de protección en .htaccess, por ejemplo la prohibición de ejecutar archivos PHP en carpetas de subida o bloqueos de archivos de configuración. Tras pasar a nginx, esas reglas quedan sin efecto en silencio. Por ello, antes del cambio compruebe qué reglas de protección figuran en .htaccess y trasládelas a la configuración de nginx del dominio.

Importante

Un cambio de handler es una modificación de la configuración de seguridad. Después, compruebe de forma específica si las rutas bloqueadas siguen bloqueadas, y no solo si carga la página de inicio.

Comprobar y cambiar el handler

Primero obtenga una visión de qué dominios usan qué handler. Los comandos son de solo lectura.

# Todos los handlers registrados con ID, versión y tipo
plesk bin php_handler --list

# Dominios que usan un handler determinado (ID de la lista)
plesk bin php_handler --get-usage -id <handler-id>

# ¿Funciona PHP dentro del proceso de Apache? (Debian/Ubuntu: apache2ctl, familia RHEL: httpd)
apache2ctl -M 2>/dev/null | grep -i php

Para el cambio, proceda dominio por dominio:

  1. Registrar las reglas de protección de .htaccess, si el nuevo handler se sirve a través de nginx.
  2. Fijar para el nuevo handler los valores provisionales contra PHP2Shell, por ejemplo session.upload_progress.enabled=0. En FPM se incluyen como php_admin_value en las directivas adicionales del pool; en FastCGI actúan otros caminos.
  3. Cambiar el handler en los ajustes de PHP del dominio, si es posible primero en una copia.
  4. Probar las funciones y comprobar si el dominio es atendido por procesos con el código actual.
  5. Si ningún dominio usa ya el módulo de Apache, desactivar el handler.

¿En qué orden cambiar?

En un servidor Plesk con años de historia rara vez se puede cambiar todo en un día. Un orden según el riesgo ayuda a emplear con sentido el poco tiempo disponible:

  • Primero, los dominios con el módulo de Apache, porque allí el riesgo por PHP2Shell es el más alto según el equipo de PHP y Plesk lo desaconseja de todos modos.
  • Después, los dominios con datos sensibles, como tiendas, portales de clientes o formularios con datos de salud o contractuales. Aquí el pool propio compensa especialmente.
  • A continuación, los dominios con versiones antiguas de PHP, que de todos modos hay que cambiar. Handler y versión se pueden cambiar juntos en una ventana de mantenimiento.
  • Por último, el paso del pool compartido al propio para los demás dominios, siempre que la memoria del servidor lo permita.

Antes del último escalón, compruebe la ocupación de memoria. Plesk advierte de que Dedicated FPM necesita más memoria y aconseja vigilar cuando hay muchos sitios web. Un servidor que tras el cambio empieza a paginar se vuelve lento, y la memoria escasa no es una buena situación precisamente con PHP2Shell.

¿Cómo ayuda PHP SOS en concreto?

  • Registramos qué dominios de su servidor Plesk usan qué handler y marcamos los dominios con módulo de Apache.
  • Cambiamos a Dedicated FPM y trasladamos las reglas de protección de .htaccess a la configuración de nginx donde haga falta.
  • Fijamos valores provisionales y límites por pool y comprobamos que surten efecto en el contexto web.
  • En el marco del refuerzo del servidor desactivamos los handlers obsoletos y documentamos la configuración.

Preguntas frecuentes

¿Qué handler de PHP recomienda Plesk?

Según la documentación de Plesk, FPM es el handler recomendado en servidores Linux dedicados, Dedicated FPM en servidores Linux de alojamiento compartido y FastCGI en servidores Windows. Plesk califica el módulo de Apache, CGI e ISAPI de muy obsoletos o inseguros, respectivamente.

¿Por qué el handler módulo de Apache es especialmente crítico tras PHP2Shell?

El handler equivale a mod_php. El equipo de PHP clasifica el riesgo de PHP2Shell como el más alto con mod_php, porque allí se demostró un exploit antes de que se ejecute el código de la aplicación. Además, el propio Plesk desaconseja este handler.

¿Qué cambia si PHP se sirve a través de nginx en lugar de Apache?

Según Plesk, los handlers servidos a través de nginx ignoran el archivo .htaccess. Las reglas de seguridad que figuran allí, por ejemplo los bloqueos de PHP en carpetas de subida, dejan entonces de aplicarse y hay que trasladarlas a reglas de nginx.

¿Debo reiniciar PHP tras cambiar de handler?

Tras el cambio, compruebe qué procesos de PHP se ejecutan para el dominio y desde cuándo. Con Dedicated FPM, el dominio recibe su propio pool. Un proceso antiguo con código obsoleto no debería seguir trabajando para el dominio después.

¿Es Dedicated FPM siempre la mejor opción?

Para el aislamiento, sí, porque cada sitio web recibe su propio pool. El precio es una mayor necesidad de memoria. Plesk aconseja vigilar los servidores con muchos sitios web.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata