En resumen: que PHP2Shell le afecte depende de tres cosas: la versión de PHP, el modo de ejecución y si se ha parcheado y cómo. Si no está seguro, póngase en contacto ahora. ¿Le afecta? Llame. Le ayudamos. Lo aclaramos en remoto en el propio servidor, no a ojo, y cerramos la vulnerabilidad si está abierta.
No borre nada ahora y no reinstale nada. Aunque solo quiera aclarar si le afecta: si el servidor ya pudo haber sido atacado, necesitamos los archivos y los registros sin modificar. Comunique la emergencia y haremos la revisión juntos.
¿Le afecta? Estos casos deben ir a la lista de revisión
PHP2Shell son dos vulnerabilidades críticas en el propio PHP (CVE-2026-109618 y CVE-2026-109619, ambas con la puntuación máxima de 9.2 según CVSS v4.0). Permiten ejecutar código malicioso en remoto sin autenticación. Pueden verse afectados todos los modos de ejecución: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Revise cada uno de estos sistemas:
- servidores propios, VPS y servidores dedicados con PHP
- paquetes de hosting y servidores gestionados, aunque usted no tenga acceso a la configuración
- contenedores y servicios de plataforma que incluyen una imagen de PHP
- sistemas de prueba, entornos de staging y sistemas antiguos olvidados accesibles desde internet
- NAS, appliances o software de proveedores de servicios que utilizan PHP internamente
Los sistemas olvidados son precisamente el riesgo. Según Unit 42 hay más de 22,6 millones de instancias expuestas y potencialmente vulnerables, y el BSI (Oficina Federal alemana de Seguridad de la Información) contaba con una explotación rápida y a gran escala.
Qué hacer ahora mismo
- Crear un inventario. Anote todos los servidores, dominios y contratos de hosting en los que se ejecuta PHP y quién es responsable de cada uno.
- Determinar la versión de PHP de cada sistema. En los servidores, con
php -v. Tenga en cuenta que la línea de comandos puede usar una versión distinta de la del servidor web. - Aclarar el modo de ejecución. ¿PHP se ejecuta como PHP-FPM, como mod_php o a través de LiteSpeed? Con mod_php es donde el equipo de PHP estima el riesgo más alto.
- Preguntar al proveedor de hosting y a los proveedores de servicios. Por escrito: ¿qué versión se ejecuta, se ha incorporado la corrección, se han reiniciado todos los procesos?
- Conservar los registros. La prensa especializada aconseja conservar los registros desde el 20/10/2026.
- No esperar demasiado. Si un sistema está abierto y no es posible aplicar el parche de inmediato, el BSI recomienda desconectar temporalmente el servidor web de la red.
¿Cómo ayuda PHP SOS en concreto?
Aclaramos si le afecta en remoto y con pruebas.
- Evaluar la situación: nos describe su inventario y clasificamos los sistemas según su accesibilidad y su riesgo.
- Asegurar y cerrar: donde esté abierto, primero aseguramos el estado y después cerramos la vulnerabilidad con la actualización y el reinicio. Donde no sea posible de inmediato, aplicamos medidas provisionales que no son una protección completa.
- Revisar y limpiar: comprobamos si la vulnerabilidad se explotó antes del parche y limpiamos si es necesario. Separamos con claridad si un servidor está afectado y si quizá ya ha sido atacado.
- Reforzar e informar: recibe una lista por sistema: versión, modo de ejecución, prueba del parche, puntos abiertos.
Cómo demostrar que le afecta
Un número de versión por sí solo no basta, porque los proveedores incorporan correcciones mediante backports. Ubuntu 24.04, por ejemplo, sigue mostrando según informes 8.3.6 incluso después de la actualización. Hay tres vías fiables:
| Vía | Qué muestra | Límite |
|---|---|---|
| Comparar la versión con las versiones corregidas | 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o superior, está corregida | solo vale para versiones originales, no para backports |
Prueba de memory_hard_limit_percent |
bool(false) significa: directiva desconocida, por tanto afectado |
ejecutar por separado para cada versión y modo de ejecución |
| Buscar los números CVE en el changelog del paquete | demuestra los backports en las distribuciones | la fuente es el archivo de seguridad del proveedor |
La prueba tiene este aspecto:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Cómo comprobar correctamente la versión y el estado del parche se explica en la página Comprobar bien la versión de PHP y el estado del parche. Una visión general de las ramas ofrece ¿Qué versiones de PHP están afectadas?. Por qué la indicación puede parecer antigua a pesar del parche lo explica el artículo php -v muestra un número antiguo.
Afectado y ya sin parche posible: PHP 8.1 y anteriores
Para PHP 8.1 y anteriores el proyecto PHP ya no publica actualizaciones oficiales, solo backports mínimos del código fuente para 7.4, 8.0 y 8.1. Quien utiliza una versión así suele tener dos vías: un proveedor con un backport demostrado o la migración a una versión mantenida. Existen ofertas comerciales de soporte a largo plazo, pero si cubren PHP2Shell y desde cuándo, debe confirmarlo por escrito el proveedor. Le ayudamos a valorarlo en PHP 8.1 y anteriores: qué se aplica ahora y con la ejecución en el servicio de parcheo de PHP.
Qué debería enviarnos
- Lista de sus servidores, dominios y proveedores de hosting
- Versión de PHP de cada sistema, en la medida en que se conozca
- Modo de ejecución y servidor web, en la medida en que se conozcan
- Indicación de si hay delante Cloudflare u otra protección y si el servidor de origen es accesible directamente
- Respuestas de su proveedor de hosting, si ya se las ha pedido
- Persona de contacto para autorizaciones y reinicios
Por qué PHP SOS
Trabajamos Made in Germany y llevamos más de 25 años especializados en seguridad informática junto con nuestra red de socios, profesionales de la ciberseguridad. Usted tiene un único interlocutor que repasa su inventario y respalda cada afirmación con pruebas, en lugar de limitarse a leer números de versión. Trabajamos en remoto, sin desplazamientos, y documentamos lo que hemos comprobado. Una afirmación como «seguro» solo la hacemos en la medida en que pueda demostrarse. Para entornos mayores puede resultar adecuada la ayuda urgente PHP2Shell.
¿Le afecta? Llame. Le ayudamos.
Si no sabe si le afecta, ya es motivo suficiente para ponerse en contacto ahora. Llame o escriba por WhatsApp. Nos hacemos cargo desde el primer mensaje y lo aclaramos con usted en el servidor. Comunicar la emergencia ahora.
Preguntas frecuentes
¿Me afecta PHP2Shell si solo uso WordPress o una tienda online?
Posiblemente sí. Las vulnerabilidades están en PHP, no en el CMS. Lo decisivo es qué versión y qué modo de ejecución de PHP sirven realmente su sitio; una actualización de WordPress no cambia nada.
¿Basta el número de versión para saber si estoy parcheado?
No siempre. Las distribuciones y los proveedores de hosting a veces incorporan las correcciones como backport y entonces el número no cambia. Lo concluyente es el changelog del paquete con los números CVE o la confirmación por escrito de su proveedor.
¿Hay una prueba rápida para saber si mi versión de PHP incluye la corrección?
Según el manual de PHP, una versión que no conoce la directiva memory_hard_limit_percent está afectada. La prueba debe ejecutarse por separado para cada versión y modo de ejecución de PHP, ya que la línea de comandos puede usar una versión distinta de la del servidor web.
¿Están afectadas también versiones antiguas de PHP como la 7.4 o la 8.0?
Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4. Para la 8.1 y anteriores el proyecto PHP ya no publica actualizaciones oficiales, solo backports mínimos del código fuente. Si un proveedor los ha incorporado, debe confirmarlo él.
¿Me protege Cloudflare si estoy afectado?
En parte. Cloudflare ha desplegado reglas de protección, pero advierte por sí mismo de que no sustituyen a la actualización. Si su servidor de origen es accesible directamente, la protección queda eludida.