Vulnerabilidad crítica de PHP php2shell: qué hacer ahora

Según el anuncio oficial de PHP del 21 de octubre de 2026, las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos fallos críticos que pueden permitir la ejecución remota de código sin autenticación. Ambos obtuvieron 9,2 en la escala CVSS v4.0, una puntuación estándar de lo peligroso que se considera un fallo. Ejecución remota de código significa que un atacante puede lanzar comandos en el servidor con los privilegios de la cuenta del proceso web.

Está afectada toda instalación de PHP que atienda peticiones web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. Amazon Threat Intelligence escribió el 21 de octubre que su red de honeypots vio el primer intento de explotación el 17 de octubre, cuatro días antes de la divulgación. SecurityWeek informa de que, según watchTowr, las pruebas de concepto que circulan aún no han llegado a ejecutar código. Hay intentos, la prueba de éxito es limitada, y eso no es motivo para esperar.

Si su sitio funciona con PHP, dé por hecho que está afectado. Según la agencia Anadolu, el FBI calcula que PHP se usa en aproximadamente el 70 % de los sitios web, y según la CISA puede estar integrado en otro software sin que usted lo vea. Nuestra herramienta de detección de tecnologías ofrece desde fuera una primera idea de con qué funciona su sitio, pero no espere que confirme la versión.

Para conocer la versión exacta, siga el camino de WordPress.org: en el panel de WordPress abra Herramientas, Salud del sitio, Info, Servidor. Los paneles de hosting suelen mostrarla también, y en sitios que no son WordPress deben indicársela su desarrollador o su proveedor. Si es inferior al número de su rama (8.2.35, 8.3.36, 8.4.27 u 8.5.12), los avisos de seguridad de GitHub indican que está afectado.

En un hosting compartido el proveedor gestiona el servidor, así que su tarea es preguntarle por escrito: ¿se ha actualizado PHP para estos fallos y en qué versión estoy? Según WordPress.org, la posición de los proveedores cambió de hora en hora: unos habían corregido, otros decían estar protegidos por un WAF, otros seguían trabajando en ello. Un WAF es un cortafuegos que filtra las peticiones entrantes. Si la respuesta es «está usted protegido», pregunte a qué versión se le pasó.

Según las notas de versión de cPanel, EasyApache 4 25.91 corrige ambos fallos desde ea-php74 hasta ea-php85, y 25.92 vuelve a compilar los paquetes ea-php74, ea-php80 y ea-php81. Estos paquetes suelen llegar por actualización automática, pero es una interpretación nuestra; el administrador del servidor debe verificar las versiones en WHM. Con Plesk vale la misma pregunta: pida a su proveedor el nombre del paquete y el número de versión. Si tiene su propio servidor, la base de conocimiento de Laravel Forge indica que las actualizaciones de seguridad automáticas no parchean PHP; hay que actualizarlo aparte en cada servidor. El proyecto PHP añade que las distribuciones de Linux recibieron el parche con antelación y aconseja «revisar los paquetes de su proveedor».

PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Su equipo de seguridad proporcionó parches mínimos del código fuente para 7.4, 8.0 y 8.1, y algunas distribuciones también los portan hacia atrás, pero puede que no hayan llegado al paquete de su proveedor. WordPress.org recuerda además que PHP anterior a 8.2 no recibe actualizaciones de seguridad. Según VulnCheck, se contabilizaron más de 2,6 millones de servidores PHP expuestos a internet, al menos 1 millón de ellos con versiones que han llegado al final de su vida útil.

La CISA recomienda desconectar los sistemas que no puedan actualizarse o que funcionen con 8.1 o anterior. WordPress.org, citando al NCSC británico, aconseja desconectar el servidor hasta actualizarlo si lo gestiona usted. Si su sitio no genera ingresos, por ejemplo una simple página de presentación, es una opción realista. PHP 8.2 llega al final de su vida útil el 31 de diciembre de 2026; pasar a 8.2.35 solo le da un respiro corto, así que planifique ya su ruta de versiones.

El anuncio de PHP es claro: solo actualizar es una solución completa; las medidas temporales reducen la exposición a determinadas vías de ataque, pero no hacen segura una instalación. El aviso de GitHub también califica el paso a la versión corregida como la única medida completa. El segundo fallo exige que dos peticiones lleguen al mismo proceso; varios procesos y su reciclaje reducen la tasa de éxito sin eliminar el riesgo, y ninguna configuración lo elimina por completo. La CISA sugiere un WAF de forma temporal, y la palabra temporal importa aquí.

Estas son las medidas que enumera el anuncio de PHP, y debe aplicarlas el administrador de su servidor, no usted. El anuncio menciona además corregir los errores fatales y los tiempos de espera que el atacante puede provocar, y eliminar los ajustes INI no válidos u obsoletos que se aplican en cada petición. Según Codeable, WordPress no usa session.upload_progress; aun así, pregunte por otras aplicaciones del servidor.

• memory_limit=-1, definido de modo que la aplicación no pueda sobrescribirlo (mediante php_admin_value)
• Un post_max_size bajo: 8M si no hay subida de archivos, 32M si la hay, con upload_max_filesize por debajo
• session.upload_progress.enabled=0 y reinicio de todos los procesos, definido en php.ini o en la configuración del pool, no mediante ini_set ni .user.ini
• fatal_error_backtraces=0 en PHP 8.5
• No usar RLIMIT_AS ni RLIMIT_DATA, porque pueden desencadenar el fallo

Amazon Threat Intelligence indica que la investigación debe empezar como mínimo desde el 17 de octubre, el día en que se vio el primer intento. Sus indicadores son peticiones POST a subidas de formularios que contienen la cadena PHP_SESSION_UPLOAD_PROGRESS, entradas sospechosas en los registros del servidor web y actividad de procesos o cambios de archivos inesperados. Pida a su proveedor o administrador que los busque. La CISA recomienda además vigilar los procesos de PHP que abren una shell o descargan herramientas. Nuestra herramienta de auditoría de seguridad revisa los ajustes básicos visibles desde fuera; no sustituye a los registros ni a los archivos del servidor.

El segundo asunto son los procesos de larga duración. Según la base de conocimiento de Laravel Forge, una actualización reinicia PHP-FPM, pero los workers de cola, Horizon y Octane iniciados desde la línea de comandos siguen con el PHP antiguo hasta que se reinician. Para verificarlo, ejecute en el servidor php8.4 -v y php-fpm8.4 -v (si usa 8.4); según Qualys, la versión que devuelve php -v puede diferir de la instalación que atiende las peticiones web. Si definió memory_limit=-1 como solución provisional, vuelva a un valor finito. Si encuentra rastros o no puede estar seguro, hable con su administrador sobre cambiar las contraseñas de la base de datos, las claves de API y las contraseñas de administración; es un principio general de higiene, no algo que digan las fuentes.

Destacan tres errores. Evitarlos importa para la mayoría de las empresas tanto como la propia actualización.

Amazon escribe que un plazo de parcheo de 7 o 30 días presupone un retraso que ya no existe; hay que medir en horas. La PHP Foundation, por su parte, explicó que la corrección se preparaba desde agosto, que los identificadores CVE se filtraron el 20 de octubre con datos erróneos y que la publicación se adelantó un día. La lección es sencilla: deje por escrito de quién es el software que hay bajo su sitio, quién lo actualiza y a quién llamar, y ate a un calendario las versiones que llegan al final de su vida útil.

• Creer que basta con actualizar un plugin, un tema o WordPress: según WordPress.org, para estos problemas no hace falta ni está previsto ninguna actualización de WordPress, y actualizar un plugin o un tema no le protege
• Fiarse de php -v: la versión de la línea de comandos puede diferir de la instalación que atiende las peticiones web
• Tratar un WAF como la solución: la CISA lo cataloga como temporal, y que un proveedor diga que usa uno no demuestra que la versión esté al día