PHP2Shell: la falla crítica de PHP y qué hacer si tu sitio corre en él

El 21 de octubre de 2026 el proyecto PHP publicó una actualización de seguridad fuera de calendario. Corrige dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, que en conjunto ya se conocen como PHP2Shell. Las dos tienen puntaje 9,2 sobre 10 y las dos permiten lo mismo: que alguien ejecute código en tu servidor enviando una petición web, sin cuenta, sin contraseña y sin que tu aplicación tenga un error propio.

El detalle técnico se filtró el 20 de octubre, un día antes de que existiera el parche. Por eso el aviso llegó con tanta urgencia.

Este artículo es para quien tiene un sitio, una tienda o un sistema interno y no sabe si eso corre en PHP. Spoiler: si tienes un WordPress, la respuesta es sí.

Qué es, sin tecnicismos

PHP es el lenguaje con que funcionan WordPress, WooCommerce, Joomla, Drupal, Moodle, PrestaShop, Magento y buena parte de los sistemas hechos en Laravel o Symfony. Cuando alguien visita tu sitio, un proceso de PHP en el servidor arma la página.

Las dos fallas están en cómo PHP limpia la memoria entre una visita y la siguiente:

CVE-2026-109618: si una petición agota la memoria a mitad de camino, PHP puede quedar con datos a medio armar y luego tratarlos como válidos.
CVE-2026-109619: un dato de una visita anterior puede sobrevivir después de liberado, y la visita siguiente lo usa antes de que se reinicie.

Un atacante que sabe provocar esas situaciones puede convertirlas en ejecución de código con los permisos del servidor web. Desde ahí puede leer la base de datos, robar las credenciales que están en la configuración o dejar instalado lo que quiera.

Lo más delicado: en servidores Apache con mod_php, el equipo de PHP demostró que el ataque funciona antes de que corra una sola línea de tu aplicación. No importa lo bien escrito que esté tu sitio ni qué plugins tenga.

¿Me afecta?

Afecta a toda instalación de PHP que atiende peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Es decir, prácticamente cualquier hosting compartido, VPS o contenedor que sirva un sitio en PHP.

Las versiones corregidas son estas:

Rama	Versión corregida	Observación
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	Deja de recibir parches el 31 de diciembre de 2026
PHP 8.1 o anterior	Sin versión oficial	Solo parches de código fuente o del proveedor

Si tu versión es menor que la de la tabla dentro de su rama, estás expuesto. 8.3.35 es vulnerable; 8.3.36 no.

PHP 8.1, 8.0 y 7.4 no tienen versión corregida

El proyecto PHP ya no publica versiones para esas ramas. Algunas distribuciones de Linux y proveedores de soporte extendido sí entregan parches propios. Si no tienes uno de esos, la agencia de ciberseguridad de Estados Unidos (CISA) recomienda sacar el sistema de internet hasta poder actualizarlo. Es una recomendación dura, y es la correcta.

Cómo saber qué versión usas

Depende de dónde está tu sitio:

Hosting compartido (cPanel, Plesk, DirectAdmin): busca la opción "Seleccionar versión de PHP" o "MultiPHP". Ahí aparece la rama (8.2, 8.3…), pero no siempre el parche exacto. Para eso, pregúntale al proveedor.
WordPress: en Herramientas → Salud del sitio → Información → Servidor aparece la versión de PHP que está usando el sitio.
Servidor propio o VPS: php -v muestra la versión de la línea de comandos, que puede no ser la misma que atiende la web. Revisa también php-fpm8.3 -v (o la versión que corresponda) y reinicia el servicio después de actualizar.
Docker: entra al contenedor que sirve la web y ejecuta php -v ahí, no en el equipo anfitrión.

Si nada de eso está a tu alcance, un archivo temporal con <?php phpinfo(); en el servidor muestra la versión exacta. Bórralo apenas lo leas: expone mucha información de tu configuración.

Qué hacer hoy

Si tu sitio está en un hosting

La actualización la hace el proveedor, pero no esperes a que lo anuncie. Escríbele:

Hola. ¿Ya actualizaron PHP por CVE-2026-109618 y CVE-2026-109619? Mi sitio usa PHP [8.x]. Necesito saber si está corriendo una versión corregida (8.5.12, 8.4.27, 8.3.36 o 8.2.35) y desde cuándo.

Si la respuesta es vaga, o tu sitio está en PHP 8.1 o anterior, eso ya es información: tienes un riesgo que el proveedor no está resolviendo.

Si administras el servidor

Actualiza PHP con los paquetes de tu distribución. Las distribuciones recibieron los parches por adelantado, así que lo normal es que ya estén disponibles.
Reinicia todos los procesos de PHP (PHP-FPM, Apache). Mientras un proceso viejo siga vivo, sigue siendo vulnerable.
Prioriza los servidores expuestos a internet y, entre ellos, los que usan mod_php.
Verifica la versión desde la web, no solo desde la consola.

Si usas contenedores

Aquí hay una trampa que nos tocó ver de cerca. Una imagen basada en php:8.3-fpm-alpine parece que se actualiza sola, porque la etiqueta apunta siempre al último parche. Pero si tu sistema de integración continua construye con caché, puede reutilizar la capa base vieja y publicar una imagen "nueva" con el PHP vulnerable adentro.

Lo seguro es fijar la versión exacta en el Dockerfile (FROM php:8.3.36-fpm-alpine), reconstruir, desplegar y comprobar con php -v dentro del contenedor que está corriendo.

Si no puedes actualizar hoy

El equipo de PHP publicó medidas que reducen la exposición, con una advertencia explícita: no dejan la instalación segura. Sirven para ganar horas, no para reemplazar el parche.

; php.ini o configuración del pool de FPM (no sirve ini_set ni .user.ini)
session.upload_progress.enabled = 0
post_max_size = 8M            ; 32M si el sitio recibe archivos
upload_max_filesize = 8M      ; siempre menor que post_max_size
; solo en PHP 8.5:
fatal_error_backtraces = 0

Además recomiendan limitar el tamaño y la complejidad de las peticiones en el servidor web o el proxy, y, si tu aplicación no recibe formularios con archivos, bloquear las peticiones multipart. Un firewall de aplicaciones web (WAF) puede ayudar mientras tanto.

Después de cualquier cambio de configuración hay que reiniciar los procesos de PHP para que tome efecto.

Ocultar errores no protege

Apagar display_errors o bajar error_reporting no evita la segunda falla. El problema está en lo que PHP hace con la memoria, no en lo que muestra.

¿Ya lo están explotando?

Las fuentes no coinciden, y vale la pena decirlo así:

CISA y la empresa de seguridad Huntress dicen que, al 21 de octubre, no habían observado explotación en sistemas reales.
Qualys cita a Cloudflare, que reporta tráfico de ataque dirigido a estas fallas.
Rapid7 indica que varios equipos ya están reproduciendo la investigación y que espera un exploit público pronto.

Para efectos prácticos da lo mismo quién tenga razón hoy: con el detalle filtrado y el parche publicado, cualquiera puede comparar el antes y el después del código. Lo razonable es asumir que el ataque va a existir y actuar antes.

Después del parche

Actualizar cierra la puerta, pero no te dice si alguien entró antes. Si tu servidor estuvo expuesto entre el 20 de octubre y el momento en que actualizaste:

Revisa si algún proceso de PHP lanzó comandos del sistema (sh, bash, curl, wget). Es la señal que recomienda vigilar CISA.
Busca archivos PHP nuevos o modificados en carpetas donde no deberían cambiar, como uploads.
Rota las credenciales que viven en la configuración (base de datos, correo, llaves de APIs) si encuentras cualquier cosa rara.

Que los registros no muestren nada no prueba que no haya pasado nada. Rapid7 lo advierte explícitamente.

En resumen

Si usas PHP para la web, actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reinicia los procesos.
Si estás en un hosting, pregúntale al proveedor con las versiones exactas.
Si estás en PHP 8.1 o anterior, el problema es más grande que esta falla: planifica la migración y, mientras tanto, consigue un parche del proveedor o saca el sistema de internet.
Y aprovecha el susto para anotar dónde corre PHP en tu empresa. La próxima alerta va a llegar, y saber eso de antemano es lo que hace que la respuesta tome una hora en vez de una semana.

Fuentes: anuncio del proyecto PHP, alerta de CISA, análisis de Rapid7, Qualys y Huntress.

¿No sabes dónde corre PHP en tu empresa? Conversemos