PHP2Shell: qué es la vulnerabilidad en PHP y cómo parchearla

PHP2Shell son dos fallos críticos en el propio PHP, registrados como CVE-2026-109618 y CVE-2026-109619. Esta vulnerabilidad en PHP puede permitir que un atacante sin sesión iniciada ejecute código en cualquier servidor que sirva páginas PHP. La solución pasa por actualizar PHP: 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o el paquete parcheado de tu distribución, y reiniciar después todos los workers de PHP.

Los detalles se filtraron el 20 de octubre, dos días antes de la publicación prevista, y el proyecto PHP adelantó los parches un día, al 21 de octubre. Si tienes algo funcionando sobre PHP (WordPress, WooCommerce, Drupal, Magento, Laravel, un panel de control), comprueba tu versión hoy mismo.

¿Qué es la vulnerabilidad en PHP PHP2Shell?

PHP2Shell es el nombre que los investigadores dieron a dos fallos de ejecución remota de código (RCE) en el intérprete de PHP. Los reportaron investigadores de Calif, Wiz, OpenAI y Quarkslab. PHP puntúa ambos con un 9,2 en CVSS v4.0.

Los fallos están en la forma en que PHP interpreta una petición entrante, antes de que arranque el código de tu aplicación. Actualizar WordPress, un plugin o tu framework no sirve de nada aquí. Lo que tiene que cambiar es el binario de PHP.

El aviso de PHP incluye todas las configuraciones que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto se lo asigna a Apache con mod_php, con un exploit demostrado en el que una sola petición sin autenticar dispara el ataque antes de que se ejecute código de la aplicación. El aviso también describe RCE a través de la función de progreso de subida de sesión (session upload progress) en PHP-FPM, si la aplicación cumple ciertas condiciones.

¿Qué versiones de PHP están afectadas?

Todo lo anterior a las cuatro versiones corregidas. Esto es lo que dicen el aviso de PHP y sus versiones de seguridad del 21 de octubre:

Cloudflare e Imperva dicen que los fallos se remontan a PHP 5.4. El aviso de PHP da por afectadas todas las versiones anteriores a las corregidas y no indica cuál es la primera versión afectada.

Tu número de versión puede parecer antiguo y estar parcheado. Las distribuciones Linux aplican los parches sobre versiones anteriores (backport) y mantienen el número original. Ubuntu 24.04 publica el parche como 8.3.6-0ubuntu0.24.04.13, que sigue mostrando 8.3.6. Debian 12 tiene 8.2.35-1~deb12u1 (DLA-4848-1) y Debian 13 tiene 8.4.27-1~deb13u1 (DSA-6574-1). Compara la versión completa del paquete con el rastreador de seguridad de tu distribución, no solo los tres primeros números.

¿Se está explotando PHP2Shell?

Los informes sobre esta vulnerabilidad PHP no coinciden y cambian cada pocas horas. Esto es lo que dijeron las fuentes, por orden:

• 17 de octubre: Amazon Threat Intelligence registró un intento de explotar PHP2Shell en sus honeypots MadPot, cuatro días antes de los parches. La petición venía de una dirección IP vinculada a un servicio comercial de anonimización.
• 20 de octubre: los detalles se filtran en internet. watchTowr confirmó que los fallos eran reales. Huntress dijo que no había visto explotación y que no conocía código de exploit público.
• 21 de octubre, 03:02 UTC: Cloudflare activó reglas de WAF para PHP2Shell. Más tarde contó que había visto tráfico de ataque contra sus clientes, con atacantes que cambiaban la carga útil (payload) para esquivar las reglas.
• 21 de octubre, 14:00 UTC: PHP publicó los parches. watchTowr informó ese mismo día de explotación de ambos fallos en su red de honeypots.
• 21 de octubre, por la tarde (hora de EE. UU.): el director ejecutivo de la PHP Foundation dijo a CNBC que no había pruebas de exploits funcionales, solo de exploits generados "incomplete, misguided, and non-working" (incompletos, mal planteados y que no funcionan). Imperva no vio tráfico coincidente durante su propia monitorización previa a la publicación.
• 23 de octubre: ninguno de los dos CVE figura todavía en el catálogo Known Exploited Vulnerabilities de CISA (su última actualización fue el 21 de octubre).

Los investigadores crearon exploits funcionales y otros equipos dicen haber reproducido los fallos. Da por hecho que los atacantes también pueden. Trata cualquier servidor PHP sin parchear y expuesto a internet como vulnerable.

Cómo comprobar tu versión de PHP

Comprueba el PHP que sirve las peticiones web. En muchos servidores, el PHP de la línea de comandos es una compilación distinta del que hay detrás de la web.

En el servidor:

php -v                     # command line PHP
php-fpm8.3 -v              # the FPM build (the name varies: php-fpm, php-fpm8.4)
apachectl -M | grep php    # a php_module line means Apache runs PHP as mod_php
dpkg -l | grep php         # Debian/Ubuntu: the full package versions
rpm -qa | grep php         # RHEL, Rocky, Alma, Fedora

Desde el navegador: crea un archivo llamado info.php con <?php phpinfo(); en la raíz de tu web, ábrelo y lee la versión que aparece arriba y la línea Server API (te dice si es FPM, Apache 2.0 Handler o CGI). Bórralo justo después, porque muestra toda tu configuración.

En WordPress: ve a Herramientas > Salud del sitio > Información y abre Servidor. La línea de versión de PHP es la que usa tu web.

En un panel de hosting: cPanel la muestra en MultiPHP Manager o en Select PHP Version, Plesk en la configuración de PHP del dominio, SiteGround en su propio panel, Site Tools, y la mayoría de hostings gestionados en la página de resumen del sitio.

En Docker: docker exec <container> php -v muestra el PHP de dentro del contenedor en ejecución, que es el que importa.

Para comprobarlo desde fuera, Searchlight Cyber ha publicado un comprobador de código abierto, php2shell-scanner, según Help Net Security. Úsalo solo contra servidores que sean tuyos.

Cómo parchear PHP2Shell

El orden vale para cualquier stack: primero los servidores expuestos a internet y después reiniciar todos los procesos de PHP. Un binario parcheado en el disco no sirve de nada mientras los workers antiguos sigan atendiendo peticiones.

Debian y Ubuntu

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

Después compara las versiones de los paquetes de dpkg -l | grep php con el rastreador de seguridad de Debian o Ubuntu. En Ubuntu 20.04 y anteriores, los paquetes 7.x corregidos llegan a través de Ubuntu Pro. Los repositorios de terceros se actualizan a su ritmo: Help Net Security informó de que rpms.remirepo.net no tenía actualización el día del lanzamiento, así que confirma que el tuyo ya la ha publicado antes de fiarte de él.

RHEL, Rocky, AlmaLinux y Fedora

Ejecuta sudo dnf upgrade 'php*' y reinicia después php-fpm y httpd. Consulta el aviso de tu proveedor para saber cuál es la versión de paquete corregida, porque no coincidirá con el número de PHP original.

Imágenes de Docker

Las imágenes oficiales php de Docker Hub recibieron las etiquetas 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el 21 de octubre. Fija una, reconstruye y vuelve a desplegar:

FROM php:8.4.27-fpm

docker compose build --pull && docker compose up -d

Un contenedor en ejecución conserva su PHP antiguo hasta que lo sustituyes. Las imágenes construidas sobre php (incluida wordpress) también necesitan un pull nuevo y otro despliegue.

Hosting compartido y cPanel

Aquí no puedes parchear PHP por tu cuenta. La mayoría de hostings compartidos en España y Latinoamérica usan cPanel (Select PHP Version o MultiPHP Manager) o Plesk, y SiteGround tiene su propio panel, Site Tools. En todos los casos, el parche lo aplica el proveedor: actualiza las compilaciones de PHP que ofrece el panel (ea-php de EasyApache o alt-php de CloudLinux en la mayoría de servidores con cPanel). Consulta su página de estado o pregunta al soporte si sus compilaciones de PHP incluyen los parches para CVE-2026-109618 y CVE-2026-109619. Si tu web sigue en 7.4 u 8.1, cámbiala a 8.3 o superior en MultiPHP Manager o Select PHP Version, después de probarla en una copia de staging si tienes una.

Hosting gestionado de WordPress

Tu proveedor parchea PHP por ti. WordPress.org dice que no hace falta ni está prevista ninguna actualización de WordPress para estos fallos. Confirma que el proveedor ya ha desplegado el parche y mira Salud del sitio > Información > Servidor. Si la web está en PHP 8.1 o anterior, súbela de versión, porque esas ramas solo reciben backports de proveedores.

Windows y compilaciones desde el código fuente

Las fuentes corregidas y los binarios para Windows están en la página de descargas de php.net. Para 7.4, 8.0 y 8.1, PHP publicó backports mínimos del código fuente para quien compila PHP por su cuenta.

Si hoy no puedes parchear

PHP es tajante en esto: solo una actualización arregla el fallo por completo. Su aviso enumera ajustes que cortan vías de ataque concretas sin dejar el servidor a salvo:

• Pon session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor (no con ini_set() ni en .user.ini) y reinicia todos los workers. Así se cortan las vías de sesión confirmadas.
• En PHP 8.5, pon fatal_error_backtraces=0 y reinicia todos los workers.
• Fija memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo, por ejemplo con php_admin_value. Combínalo con un post_max_size bajo (8M sin subidas de archivos, 32M con ellas) y un límite de memoria en el contenedor o el cgroup. No uses RLIMIT_AS ni RLIMIT_DATA, que pueden disparar el fallo.
• Limita en el servidor web o en el proxy el tamaño de la petición, el número de campos, las partes multipart y la profundidad de anidamiento, y rechaza las peticiones multipart si la web nunca recibe subidas.

Prueba cada cambio antes de desplegarlo, porque algunos rompen las subidas. Si un servidor no se puede parchear ni mitigar a tiempo, tanto el NCSC británico como WordPress.org recomiendan plantearse desconectarlo, o ponerlo detrás de una VPN o de una lista de direcciones permitidas para que solo lleguen direcciones conocidas.

Reduce la exposición mientras parcheas

Nada de lo anterior impide que un escáner envíe peticiones. La explotación masiva de un fallo recién publicado está automatizada: hay scripts que barren internet en busca de servidores PHP y lanzan el exploit contra cada uno. Esos escáneres suelen funcionar en servidores alquilados de redes de hosting y centros de datos, o pasan por VPN, proxies y Tor. El primer intento que vio Amazon venía de un servicio de anonimización. Los visitantes reales casi nunca navegan desde un centro de datos.

Eso te da una segunda capa para los días que tardes en parchearlo todo: rechazar las peticiones de esas redes antes de que lleguen a PHP. IPScanner no detecta PHP2Shell ni arregla PHP. Comprueba quién se conecta, clasifica a cada visitante en una categoría (humano, crawler verificado, automatización maliciosa, hosting, Tor, VPN, proxy y alguna más) y bloquea las categorías que elijas.

La comprobación tiene que ejecutarse delante de PHP. PHP2Shell se dispara mientras PHP interpreta la petición, así que cualquier cosa que se ejecute dentro de PHP llega tarde.

El plugin de WordPress y las comprobaciones de WooCommerce frenan registros falsos, spam y card testing en tus formularios. Para PHP2Shell son la capa equivocada. A una web de WordPress en un único servidor Apache sin nada delante, lo más rápido es ponerle Cloudflare y el Worker por delante.

Empieza en modo monitor y bloquea después. El modo monitor registra cada veredicto y no bloquea nada, así que ves quién llama a tus endpoints de PHP antes de cambiar nada. Pasadas unas horas, pon hosting, Tor y automatización maliciosa en bloqueo. VPN y proxy dependen de tu caso: bloquéalos en un panel de administración y piénsatelo dos veces en una tienda abierta al público. Los buscadores y crawlers de IA verificados del directorio de crawlers pasan siempre.

Para bloquear necesitas el plan Starter. En el plan Free, una web funciona solo en modo monitor. Las cuentas nuevas tienen siete días de funciones de Starter sin tarjeta, lo que cubre una ventana de parcheo. Consulta los precios.

Ten claros los límites:

• Un atacante con conexión doméstica o con un proxy residencial que las comprobaciones no detecten sigue llegando a PHP.
• Los filtros fallan en abierto (fail open). Si la API de IPScanner va lenta o no responde, las peticiones pasan y la web sigue en pie.
• Un filtro solo sirve si el tráfico pasa por él. Si tu origen responde en su IP pública, un escáner se salta Cloudflare por completo, así que haz que el origen acepte conexiones solo desde los rangos de IP de Cloudflare.

Si tu web está en Cloudflare, deja también activadas sus reglas gestionadas de WAF. Cloudflare dice que sus reglas para PHP2Shell funcionan por defecto en todos los planes desde el 21 de octubre. Esas reglas miran la petición en sí; IPScanner mira quién la envía. Ninguna de las dos sustituye al parche.

Comprueba si alguien ha entrado

Si un servidor ha estado sin parchear y expuesto desde mediados de octubre, revísalo antes de pasar página. Los avisos y los equipos de respuesta a incidentes apuntan a las mismas señales:

• peticiones POST multipart grandes o muy anidadas a rutas .php, a menudo con PHP_SESSION_UPLOAD_PROGRESS en el cuerpo
• errores "Allowed memory size exhausted" y ráfagas de workers de PHP caídos o relanzados en los logs de errores
• archivos nuevos o modificados en la raíz web, cron jobs o cuentas de usuario nuevas
• procesos de PHP o del servidor web que abren shells o hacen conexiones salientes que no reconoces

Si sospechas que te han comprometido, aísla el servidor y conserva los logs antes de reiniciar nada. Después rota todos los secretos que PHP pudiera leer: contraseñas de bases de datos, claves de API, claves de sesión.

Checklist de PHP2Shell

1. Haz una lista de todas tus instalaciones de PHP, empezando por las expuestas a internet, incluidos paneles de control, appliances y contenedores.
2. Averigua la versión que sirve las peticiones web (phpinfo, Salud del sitio, php-fpm -v), no solo php -v.
3. Instala 8.5.12, 8.4.27, 8.3.36, 8.2.35 o el paquete corregido de tu distribución.
4. Reinicia todos los pools de PHP-FPM y los workers de Apache y LiteSpeed; reconstruye y vuelve a desplegar los contenedores.
5. En 8.1 o anteriores, consigue un backport de un proveedor o actualiza; si no puedes hacer ninguna de las dos cosas, desconecta la web o limítala a una lista de direcciones permitidas.
6. ¿Todavía no puedes parchear? Aplica los ajustes provisionales de PHP y restringe el acceso.
7. Pon un filtro delante de PHP (Cloudflare, Traefik, Caddy, nginx), primero en modo monitor y después bloqueando hosting, Tor y automatización maliciosa.
8. Cierra tu origen para que solo acepte conexiones del proxy que tiene delante.
9. Busca en tus logs desde el 17 de octubre las señales de arriba.
10. Rota los secretos de cualquier servidor que haya estado expuesto y sin parchear.

Fuentes: Aviso de seguridad de PHP, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, WordPress.org, Cloudflare, FAQ de watchTowr, watchTowr, Help Net Security, SecurityWeek, The Hacker News, CNBC, Imperva, Qualys, Armis, Ubuntu, Debian.