PHP2Shell: qué hacer ahora para proteger tus servidores y sitios web

Actualización al 22 de octubre de 2026. Saber qué hacer ante PHP2Shell exige dos trabajos paralelos: cerrar la vulnerabilidad y comprobar si alguien pudo aprovecharla antes de la corrección. Actualizar PHP es imprescindible, pero no demuestra por sí solo que el servidor permanezca íntegro.

Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 afectan al núcleo de PHP y pueden permitir ejecución remota de código sin autenticación o exposición de memoria. El NCSC de Nueva Zelanda afirma estar al tanto de reportes de explotación activa. Por eso, los sitios PHP expuestos a Internet deben tratarse como una prioridad inmediata.

Antes de comenzar: define la prioridad

Atiende primero los sitios públicos que ejecutan una versión vulnerable o desconocida, especialmente Apache con mod_php. Después revisa PHP-FPM, Nginx, LiteSpeed, PHP-CGI, FrankenPHP, contenedores y servicios internos. Un WordPress actualizado sigue expuesto si debajo utiliza un intérprete PHP vulnerable.

No asumas que todo servidor con interfaz web está afectado. Un sistema Node.js o una instalación de Proxmox no queda expuesto por estas CVE solo por existir en la misma infraestructura. Sí debes revisar cualquier panel, complemento, aplicación o contenedor adicional que ejecute PHP.

1. Construye un inventario real

Registra cada dominio, subdominio, API, tienda, panel administrativo y tarea programada que dependa de PHP. Para cada elemento anota propietario, entorno, exposición a Internet, proveedor, sistema operativo, método de ejecución, versión observada, paquete instalado y responsable de la actualización.

Incluye WordPress, WooCommerce, Drupal, Joomla, Laravel, aplicaciones a medida, imágenes Docker, funciones y máquinas que quizá ya no estén documentadas. Busca también entornos de pruebas y sitios heredados: suelen quedar fuera de los ciclos normales de mantenimiento, pero continúan accesibles.

2. Identifica la versión que atiende cada sitio

En un servidor Linux, estos comandos ayudan a reconocer el intérprete de consola, los paquetes y los servicios disponibles:

php -v
command -v php
whereis php
systemctl list-units --type=service --all | grep -Ei 'php|apache|httpd|lsws'

En Debian o Ubuntu puedes revisar paquetes con:

dpkg -l 'php*'
apt-cache policy php php-fpm

En AlmaLinux, Rocky Linux o RHEL, utiliza las herramientas del proveedor:

rpm -qa | grep -i php
dnf updateinfo list --security

Advertencia: php -v muestra normalmente la interfaz de línea de comandos. El sitio puede usar otro binario, otra rama o un pool PHP-FPM distinto. Comprueba cada host virtual desde su configuración y desde el contexto web, sin publicar información sensible.

cPanel, HostGator y alojamiento compartido

Abre MultiPHP Manager y revisa dominio por dominio. cPanel permite que cada host virtual use una versión instalada diferente, o que herede la versión global. Si la rama corregida no aparece, el proveedor debe instalarla mediante EasyApache o confirmar por escrito un backport de seguridad.

No publiques un archivo phpinfo() abierto para hacer la prueba: revela demasiados detalles del entorno. Si el soporte te pide usarlo, restríngelo, consulta el resultado y elimínalo inmediatamente. También puedes revisar Salud del sitio en WordPress, aunque la confirmación final debe provenir del proveedor o del servidor.

3. Respalda y conserva evidencia

Antes de hacer cambios amplios, crea respaldos verificables de archivos y bases de datos. Conserva por separado registros web, eventos del sistema, configuración, lista de procesos y, cuando sea posible, una instantánea del volumen o de la máquina. Registra la hora y quién realizó cada acción.

Un respaldo facilita la recuperación, pero no prueba que esté limpio. Si ya existen señales de intrusión, evita borrar archivos sospechosos o rotar registros antes de copiarlos. La preservación de evidencia ayuda a determinar el alcance y evita perder pistas relevantes.

4. Actualiza a una versión corregida

El proyecto PHP publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Debes instalar al menos la versión corregida de la rama utilizada. PHP 8.1 y anteriores ya no reciben mantenimiento ordinario del proyecto; migra a una rama compatible o exige documentación precisa del parche retroportado por tu proveedor.

Haz primero una prueba breve de compatibilidad cuando sea viable, especialmente en sitios antiguos. Verifica inicio de sesión, formularios, pagos, correos, tareas programadas y extensiones críticas. La posibilidad de una incompatibilidad no justifica aplazar indefinidamente el parche: requiere preparar respaldo, ventana de cambio y reversión controlada.

Contenedores y servicios cloud

Actualizar el sistema anfitrión no reemplaza PHP dentro de una imagen. Actualiza la imagen base o las dependencias, reconstruye sin reutilizar capas vulnerables, publica una nueva imagen y vuelve a desplegar las instancias o pods. Después confirma el identificador de la imagen realmente ejecutada.

Google Cloud indica que los runtimes compatibles de App Engine Standard reciben correcciones automáticas. App Engine Flexible, imágenes personalizadas, determinados servicios de Cloud Run sin actualizaciones automáticas y cargas de GKE requieren reconstrucción o redespliegue. Revisa la guía de tu plataforma: no extrapoles el comportamiento de un producto a otro.

5. Reinicia o reemplaza los procesos afectados

Tras instalar los paquetes, reinicia de forma controlada Apache, PHP-FPM, LiteSpeed o el servicio correspondiente. En infraestructura inmutable, sustituye las instancias. Esto asegura que los trabajadores activos carguen el binario corregido y elimina estados de memoria previos; reiniciar sin parchear solo ofrece un alivio temporal.

Comprueba que los servicios volvieron a levantarse, revisa sus registros y ejecuta pruebas básicas de cada aplicación. En sistemas con balanceo, confirma todos los nodos: basta uno sin actualizar para conservar la exposición.

6. Verifica la corrección desde el contexto correcto

No cierres la incidencia al terminar la instalación. Documenta la versión de PHP que responde en cada dominio, el paquete exacto del proveedor, la fecha del cambio y el estado de los procesos. Si existe un backport, el número principal puede parecer anterior: solicita el boletín y la revisión concreta que contiene el arreglo.

• Confirma que cada sitio carga y usa el runtime esperado.
• Verifica que ningún pool, contenedor o nodo conserve la versión anterior.
• Revisa tareas CLI y workers de colas por separado.
• Comprueba que monitoreo, respaldos y registros sigan funcionando.
• Guarda evidencia del resultado y asigna una nueva revisión.

7. Busca indicios de explotación

Wiz recomienda correlacionar solicitudes multipart inusuales, errores de memoria, incrementos de respuestas HTTP 500, cookies PHPSESSID grandes o malformadas y reinicios anormales de trabajadores PHP. Una señal aislada no confirma un ataque, y la ausencia de estas señales tampoco lo descarta.

Amplía la revisión a archivos PHP nuevos o modificados, usuarios administradores inesperados, tareas cron desconocidas, cambios de configuración, procesos extraños, conexiones salientes y accesos anómalos a la base de datos. En WordPress, compara el núcleo con una copia legítima y examina plugins, temas, mu-plugins y directorios de carga.

8. Si encuentras señales, trata el caso como incidente

Aísla el sistema afectado de forma que limite el daño sin destruir evidencia. Conserva registros e instantáneas, determina qué cuentas y secretos estuvieron disponibles para el proceso PHP y solicita apoyo especializado si el alcance no es claro. No confíes solamente en borrar una puerta trasera visible.

Desde un equipo limpio, rota credenciales de base de datos, panel, WordPress, API, correo, almacenamiento y despliegue que pudieron quedar expuestas. Invalida sesiones y tokens cuando corresponda. Reconstruye desde una base conocida y corregida, o restaura un respaldo cuya fecha e integridad puedas justificar.

También revisa sistemas vecinos a los que la aplicación podía acceder. El atacante normalmente obtiene los permisos del proceso PHP, no privilegios root de manera automática; aun así, esos permisos pueden bastar para leer credenciales, modificar el sitio y desplazarse hacia otros servicios.

9. Si todavía no puedes actualizar

La única solución completa es aplicar la corrección. El equipo de PHP describe controles temporales: fijar administrativamente memory_limit=-1, reducir post_max_size, limitar cuerpos y encabezados HTTP en el frontal, desactivar el progreso de carga de sesiones y reiniciar trabajadores. En PHP 8.5 también propone desactivar trazas de errores fatales.

Estas medidas pueden reducir algunas rutas, pero no eliminan todas las variantes. Evalúa bloquear el acceso público, limitarlo por red o retirar temporalmente el servicio. Un WAF es defensa en profundidad, no sustituto de actualizar PHP.

Lista de cierre

1. Inventariaste todos los sitios, runtimes, nodos y contenedores PHP.
2. Confirmaste la versión web real de cada aplicación, no solo la CLI.
3. Creaste respaldos comprobados y preservaste registros relevantes.
4. Instalaste una versión corregida o un backport documentado.
5. Reiniciaste servicios o redesplegaste imágenes y verificaste cada nodo.
6. Buscaste indicios de explotación y documentaste el resultado.
7. Rotaste secretos y reconstruiste desde una base confiable si hubo compromiso.

Actuar con orden es tan importante como actuar rápido. El resultado esperado no es simplemente “el sitio abre”, sino una matriz donde cada activo tenga versión verificada, evidencia de corrección, revisión de seguridad y un responsable claramente asignado.