PHP2Shell, explicado.

En resumen

• Vulnerabilidades: CVE-2026-109618 y CVE-2026-109619, conocidas públicamente como PHP2Shell, publicadas por el equipo de seguridad de PHP el 21 de octubre de 2026.
• Gravedad: crítica, con una puntuación de 9.2 (CVSS v4.0) cada una. Ambas pueden permitir la ejecución remota de código sin autenticación.
• Afectados: las instalaciones de PHP que atienden solicitudes web. Los investigadores encontraron versiones afectadas que se remontan a PHP 5.4.
• Solución: actualizar PHP. El proyecto PHP afirma que no existen mitigaciones completas y que actualizar es la única opción segura.

Qué son las vulnerabilidades

Ambos fallos son errores de seguridad de memoria en el entorno de ejecución de PHP, no en WordPress, Drupal, Laravel ni en otras aplicaciones creadas sobre él. Un sitio web puede estar expuesto aunque su propio código y sus plugins estén completamente actualizados.

• Corrupción por falta de memoria, CVE-2026-109618: quedarse sin memoria puede interrumpir PHP cuando los datos internos de la solicitud solo están inicializados en parte. La limpieza de la solicitud puede entonces tratar esos datos no válidos como válidos.
• Estado de solicitud obsoleto, CVE-2026-109619: el estado interno de una solicitud puede sobrevivir a la memoria que lo respalda. Una solicitud posterior atendida por el mismo proceso de trabajo de PHP puede usar ese estado obsoleto, lo que puede exponer la memoria del proceso o permitir la ejecución de código.

Los investigadores demostraron la ejecución remota de código sin autenticación contra WordPress y Drupal, y también contra Joomla en el caso del primer fallo. Incluso una aplicación mínima «Hello World» en un entorno de ejecución afectado puede estar expuesta.

A quién afecta

Según el aviso de PHP, los fallos afectan a todas las instalaciones de PHP que atienden solicitudes web, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Apache con mod_php presenta el mayor riesgo: un exploit demostrado desencadena el ataque con una solicitud sin autenticar antes de que se ejecute código alguno de la aplicación.

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP. El aviso enlaza correcciones mínimas en código fuente adaptadas a PHP 7.4, 8.0 y 8.1, pero lo más recomendable es migrar los entornos antiguos a una versión con soporte.

Versiones corregidas

Las versiones anteriores de cada rama con soporte deben considerarse vulnerables.

PHP 8.2 deja de tener soporte el 31 de diciembre de 2026.

Paquetes de las distribuciones

Las distribuciones de Linux recibieron las correcciones por adelantado y publican paquetes corregidos con sus propios números de versión. Un paquete de una distribución puede estar corregido aunque su versión parezca más antigua que la del proyecto original. En Ubuntu 24.04 LTS, por ejemplo, el paquete corregido es 8.3.6-0ubuntu0.24.04.13, no 8.3.36.

Consulta el aviso de seguridad de tu distribución para conocer las versiones exactas de los paquetes. El aviso de PHP también pide a los usuarios del repositorio remirepo que pasen a los paquetes de su distribución o compilen desde el código fuente, porque ese repositorio no tenía actualizaciones el día de la publicación.

Mitigaciones provisionales

Si no puedes actualizar de inmediato, el aviso de PHP enumera ajustes que reducen la exposición a determinadas vías de ataque. No hacen que una instalación sea segura y deben aplicarse en php.ini, en el grupo de procesos de PHP-FPM o en la configuración del servidor, y después hay que reiniciar todos los procesos de trabajo de PHP.

• Desactiva el progreso de carga de sesión: session.upload_progress.enabled = 0. No confíes en ini_set() ni .user.ini para esto.
• Elimina el límite de memoria de PHP con memory_limit = -1, configurado de forma que las aplicaciones no puedan anularlo, y usa en su lugar un límite de memoria del contenedor o del cgroup. No uses RLIMIT_AS ni RLIMIT_DATA; pueden activar la ruta vulnerable.
• Limita el tamaño de las solicitudes, por ejemplo post_max_size = 8M, o 32M si se necesitan cargas de archivos, y aplica límites a las solicitudes en el servidor web o en el proxy.
• En PHP 8.5, configura fatal_error_backtraces = 0.

Ocultar los errores no sirve de nada. Considera estos ajustes un puente breve hasta la actualización, no una solución.

Cortafuegos de aplicaciones web

Cloudflare implementó reglas gestionadas de WAF para PHP2Shell antes de la divulgación pública, también en su plan gratuito. Un WAF es una capa adicional útil mientras actualizas, pero se ha observado que los atacantes modifican las cargas útiles para evitar la detección, y actualizar solo el código o los plugins del sitio web no corrige un fallo del entorno de ejecución. Actualiza PHP aunque tengas un WAF.

Después de actualizar

• Reinicia PHP: reinicia PHP-FPM, Apache o el servidor de aplicaciones PHP para que todos los procesos de trabajo carguen el código corregido.
• Comprueba el entorno de ejecución que sirve el sitio web: la versión de PHP de la línea de comandos puede ser distinta de la que atiende las solicitudes web, y es habitual que los servidores ejecuten varias versiones de PHP a la vez.
• Comprueba todos los servidores y cuentas de alojamiento: es fácil pasar por alto los sitios de staging, las instalaciones antiguas y los servidores secundarios.
• Revisa los límites: la corrección añade un límite de memoria estricto que finaliza el proceso al alcanzarse, así que revisa los ajustes de memoria y de tamaño de las solicitudes para las solicitudes pesadas legítimas.

Si usas alojamiento administrado, pide a tu proveedor que confirme que el entorno de ejecución corregido ya está instalado.

Indicios que conviene investigar

Los investigadores enumeran señales que merecen un análisis más detallado. Por sí solas, no demuestran que un servidor haya sido atacado.

• Valores inusualmente grandes o mal formados de PHPSESSID en las cookies.
• Solicitudes multipart seguidas de errores por límite de memoria o de respuestas HTTP 500 repetidas.
• Caídas inexplicables de los procesos de trabajo de PHP.

Si sospechas de una intrusión, actualizar PHP no elimina nada de lo que un atacante haya podido dejar. Eso requiere una investigación independiente.

Cómo podemos ayudarte

Nuestra verificación identifica el entorno de ejecución de PHP que realmente sirve tu sitio web, comprueba el estado de las correcciones del proveedor y te entrega conclusiones por escrito con un siguiente paso claro. No se cambia nada en tu servidor hasta que acordemos el alcance contigo.

Fuentes

• Aviso de seguridad de PHP, 21 de octubre de 2026
• Resumen de la investigación de PHP2Shell
• Aviso de seguridad de Ubuntu USN-8948-1
• Cloudflare: protección WAF frente a las vulnerabilidades de PHP

Revisado el 22 de octubre de 2026. Este resumen es información general, no asesoramiento sobre tus sistemas. Consulta el aviso de PHP para conocer los detalles más recientes.