PHP2Shell: dos fallas críticas en PHP y qué hacer esta semana

El martes 21 de octubre, el Puerto de Róterdam, el portal de gobierno Overheid.nl y varios hospitales de Países Bajos sacaron sus sitios de internet. El Ministerio del Interior de Francia puso todos los suyos en «mantenimiento preventivo». Nadie reportó un ataque. Se desconectaron por precaución, porque esa mañana se supo que el lenguaje en el que corren tenía dos agujeros críticos.

El lenguaje es PHP. Es el mismo que mueve WordPress, Drupal, Joomla y Magento. Si tu empresa tiene un sitio web, una tienda en línea o un sistema interno con más de cinco años, es muy probable que corra PHP.

Respuesta corta. PHP2Shell son dos fallas críticas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, con CVSS 9.2. Permiten ejecutar código en el servidor sin iniciar sesión y afectan a PHP 5.4 en adelante. Ya hay ataques. Las versiones corregidas, del 21 de octubre de 2026, son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

¿Qué es PHP2Shell y por qué es tan grave?

Son dos errores de manejo de memoria en el propio intérprete de PHP. Uno aparece cuando PHP se queda sin memoria a mitad de una petición y deja datos a medio inicializar. El otro deja referencias a memoria ya liberada que una petición posterior, atendida por el mismo proceso, puede reutilizar. Encadenados, permiten ejecutar código en el servidor.

Tres cosas lo hacen grave:

• No hace falta un error en tu aplicación. Wiz demostró que hasta un «Hello World» es vulnerable. La falla está debajo de WordPress, no dentro.
• No hace falta login. Basta una petición HTTP armada con cuidado.
• Ya se explota. Cloudflare reportó tráfico de ataque contra sus clientes antes de la publicación oficial, porque el detalle se filtró antes de tiempo.

Wiz, que encontró las fallas, dice que corresponden a cerca del 70% de los sitios web del mundo. BleepingComputer da un rango de 75% a 80%. Censys contó 3,082,629 hosts y 56,663,669 propiedades web con PHP visibles desde internet. Wiz lo compara con Log4Shell, de 2021: no por la técnica, sino por lo difícil que va a ser parchear todo.

¿Qué versión de PHP necesitas?

El 21 de octubre de 2026 el equipo de PHP publicó cuatro versiones corregidas. Lo que tienes que mirar es el número completo, no solo la rama.

Un detalle que confunde: en un hosting compartido, el selector de PHP suele decir «8.2» y nada más. Eso no te dice si tienes 8.2.34 (vulnerable) u 8.2.35 (corregida). Pídele al proveedor el número exacto, por escrito.

¿Cómo revisas qué versión corre tu sitio?

1. Con acceso al servidor: ejecuta php -v. Si usas contenedores, hazlo dentro de cada uno: docker exec <contenedor> php -v. Cada imagen trae su propio PHP.
2. En WordPress: Herramientas → Salud del sitio → Información → Servidor. Ahí aparece la versión de PHP completa.
3. En hosting compartido o administrado: abre un ticket y pregunta tres cosas. Qué versión exacta corre tu cuenta, si ya aplicaron 8.x.y corregida y, si no, cuándo.
4. Si administras varios sitios: haz la lista completa hoy. Sitio, servidor, versión de PHP y quién la actualiza. Esa lista es el trabajo.

¿Qué encontré al revisar mis propios sistemas?

Esta mañana hice la revisión completa, sistema por sistema, con php -v en cada uno. Uno de ellos tenía una versión vulnerable. Lo respaldé, lo actualicé a la versión corregida y verifiqué que siguiera funcionando. Todo en la misma mañana.

No lo cuento por el susto. Lo cuento porque ese sistema lo había montado yo hace pocas semanas, con versiones fijas y documentadas. Aun así, la falla estaba ahí. Si te pasa con un sistema que conoces de memoria, imagina con el sitio que armó otra persona hace tres años.

¿Qué haces si no puedes actualizar hoy?

Actualizar es la única corrección completa. El equipo de PHP lo dice así: «no hay mitigaciones completas, actualizar es la única opción segura». Mientras llegas ahí, estas medidas reducen el riesgo:

Dos aclaraciones. Actualizar WordPress, sus plugins o el tema no corrige nada de esto: la falla vive en PHP. Y el aviso de PHP menciona memory_limit=-1 como mitigación principal del primer CVE. Úsala solo si el servidor tiene otro límite de memoria por fuera, como un contenedor con tope. Sin eso, cambias un riesgo por otro.

La pregunta ya no es si tu sitio tiene plugins al día. Es si alguien sabe, con número exacto, qué versión de PHP corre debajo.

¿Por qué la IA importa en esta historia?

Según la cronología de Wiz, la primera falla se encontró el 19 de agosto de 2026 con apoyo de modelos de IA (Gemini 4 Argon y GPT-5.6 Sol). Al día siguiente ya tenían ejecución remota contra Drupal. A los dos días, contra WordPress. Wiz lo resume así: los modelos de frontera redujeron de forma sustancial la barrera para convertir una falla vieja en un exploit.

Esta vez lo hicieron investigadores, con divulgación coordinada y dos meses para preparar el parche. La misma capacidad está disponible para quien no coordina con nadie. Lo práctico para tu empresa es que la ventana entre «se publica la falla» y «alguien la explota» se acorta. Tu ciclo de parcheo también tiene que acortarse.

¿Qué hacer esta semana?

1. Haz el inventario. Cada sitio, tienda, intranet o sistema con PHP, con su versión exacta y quién la actualiza.
2. Actualiza a 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Empieza por lo que está expuesto a internet y por lo que corre con mod_php.
3. Si dependes de un hosting, pide confirmación por escrito. Versión exacta y fecha de aplicación.
4. Si no puedes parchear hoy, pon un WAF delante y aplica session.upload_progress.enabled=0.
5. Si corres PHP 8.1 o anterior, agenda la migración. Esta no será la última falla, y ya no hay versiones oficiales para esas ramas.
6. Revisa los logs. Wiz sugiere buscar peticiones multipart raras seguidas de errores de memoria o respuestas 500 repetidas, y cookies PHPSESSID anormalmente grandes.

Si mañana alguien te pregunta qué versión de PHP corre el sitio de tu empresa, ¿sabrías la respuesta con número exacto, o tendrías que preguntarle a alguien más?