Dos vulnerabilidades en el motor de PHP exponen a casi cualquier sitio, tienda en línea o portal construido sobre PHP 5.4 o posterior, sin importar qué tan bien esté escrito su código.
El 21 de octubre de 2026, el equipo de PHP publicó parches de emergencia para PHP2Shell, el nombre con el que se conocen las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Ambas permiten a un atacante ejecutar comandos en un servidor web sin autenticarse y sin interacción del usuario.
No es una amenaza teórica: Amazon detectó un intento de explotación cuatro días antes de que la falla se hiciera pública, y Cloudflare reportó ataques horas antes de que saliera el parche. En este artículo explicamos qué es PHP2Shell, por qué es distinta a otras vulnerabilidades web y qué debe hacer tu organización hoy.
¿Qué pasó? Así funciona PHP2Shell
PHP2Shell fue descubierta por investigadores de Wiz, Calif y OpenAI, con participación de Quarkslab. El equipo de PHP anunció la falla el 20 de octubre y liberó las correcciones al día siguiente. Ambas vulnerabilidades tienen una calificación de 9.2 sobre 10 (CVSS v4.0); la firma watchTowr las calificó con un 10.0.
El problema vive en el propio motor de PHP, no en las aplicaciones. Cuando una petición agota la memoria asignada, PHP detiene el procesamiento de golpe, pero no siempre limpia su estado interno. La siguiente petición atendida por el mismo proceso puede reutilizar esa memoria “sucia”. A esto se le llama use-after-free: usar un área de memoria que ya fue liberada, lo que abre la puerta a que el atacante inyecte instrucciones propias.
El vector de entrada es una función que viene activada por defecto: el seguimiento de progreso de carga de archivos en sesiones (session.upload_progress). Basta con enviar peticiones de carga (multipart) especialmente construidas.
Lo más grave: todo ocurre antes de que se ejecute una sola línea del código de la aplicación. CrowdStrike verificó que una sola petición POST anónima puede hacer que un servidor Apache con mod_php abra una terminal y ejecute un comando del atacante. Además, los investigadores demostraron que la falla puede filtrar memoria del servidor, incluyendo contraseñas, tokens de sesión y llaves de API.
Un dato relevante: según Wiz, estas fallas existían desde hace años, y fueron modelos de IA de frontera los que redujeron drásticamente la dificultad de convertirlas en un exploit funcional.
¿Por qué importa? El alcance es enorme
PHP es la base de una parte muy grande de la web: WordPress, WooCommerce, Magento, Shopware, Symfony, WHMCS y miles de aplicaciones internas. Sansec confirmó ejecución remota sin autenticación contra Magento 2.4.9 y otras diez aplicaciones PHP.
Están afectadas prácticamente todas las formas de servir PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los servidores con mod_php son los de mayor riesgo.
Tres factores elevan la urgencia:
- Explotación activa previa a la divulgación. La red de honeypots MadPot de Amazon registró un intento el 17 de octubre, y Cloudflare vio ataques la mañana del 21, antes del parche.
- Herramientas públicas. Ya circulan exploits y un escáner de código abierto (php2shell-scanner, de Searchlight Cyber). También circulan PoCs falsos en GitHub, según JFrog, así que hay que descargar herramientas solo de fuentes confiables.
- Equipos de seguridad afectados. Palo Alto Networks confirmó que todas las versiones de PAN-OS y Panorama son vulnerables y aún no hay versiones corregidas. Fortinet y Cisco publicaron avisos y están revisando sus productos, sin confirmar equipos afectados hasta ahora.
El NCSC del Reino Unido recomienda considerar desconectar los sistemas que no puedan parcharse de inmediato.
Cómo respondió Cloudflare: mitigación en el perímetro antes del parche
Cloudflare protegió a sus clientes con WAF unas 9 horas antes de la divulgación pública. Desde el 21 de octubre a las 3:02 UTC, todos sus clientes con WAF, incluido el plan gratuito, quedaron protegidos de forma predeterminada.
La empresa participó en el esfuerzo coordinado con la PHP Foundation, OpenAI y Wiz, y trabajó en las reglas desde inicios de octubre. Como el exploit se filtró antes de la fecha oficial, Cloudflare vio tráfico de ataque real contra sus clientes y observó cómo los atacantes modificaban sus cargas maliciosas para evadir las reglas; con esa telemetría las fue ajustando.
Lo novedoso es la técnica. En PHP2Shell, una petición maliciosa puede verse casi igual que una legítima, así que inspeccionar solo la petición no basta. Cloudflare estrenó la detección de transacción completa: analiza juntas la petición y la respuesta del servidor dentro de la misma conexión. Si la respuesta confirma que el exploit funcionó, la bloquea antes de que llegue al atacante. Esto reduce falsos positivos y frena la fuga de datos de memoria.
| Plan de Cloudflare | Protección desplegada | ¿Requiere acción? |
|---|---|---|
| Free | Cloudflare Managed Free Ruleset (7 reglas “Anomalous Execution”) + Managed Response Firewall | No, activa por defecto |
| Pro, Business y Enterprise | Cloudflare Managed Ruleset (7 reglas “Anomalous Execution”) + Managed Response Firewall | Sí: confirmar que el ruleset esté desplegado en modo bloqueo |
Para revisar los intentos bloqueados, entra a Security > Security Analytics > Events y filtra por los IDs de regla que Cloudflare publicó en su blog y en el changelog del WAF.
Dos advertencias importantes. Primero, Cloudflare insiste en que el WAF es defensa en profundidad y no sustituye actualizar PHP. Segundo, la protección solo cubre el tráfico que pasa por Cloudflare: si la IP de tu servidor de origen es accesible directamente, un atacante puede saltarse el WAF. Restringe el origen para aceptar solo tráfico de las IPs de Cloudflare o publícalo mediante Cloudflare Tunnel.
¿Qué significa para tu organización?
1. Tener código limpio no te protege. Una aplicación bien mantenida está igual de expuesta que una descuidada, porque la falla está en el motor. Las revisiones de código o los escaneos de la aplicación no la detectan.
2. Las versiones fuera de soporte son el eslabón más débil. PHP 8.1 y anteriores ya no reciben soporte oficial. Muchas organizaciones mantienen aplicaciones heredadas, portales de proveedores o sistemas internos sobre PHP 7.x que nadie actualiza. Ahí es donde se concentrará el riesgo durante meses.
3. Es un problema de datos y de cumplimiento. La fuga de memoria puede exponer credenciales y datos de clientes. Para una tienda en línea, eso toca directamente PCI DSS; para cualquier empresa que trate datos personales, la LFPDPPP; y para organizaciones certificadas, los controles de gestión de vulnerabilidades e incidentes de ISO 27001.
4. Tu propia infraestructura de seguridad puede estar en la lista. Firewalls, paneles de administración, appliances y sistemas embebidos suelen correr PHP por dentro. El caso de PAN-OS demuestra que el inventario no termina en tus servidores web.
¿Qué debe hacer tu organización ahora?
- Haz inventario de todo lo que corre PHP. Servidores web, contenedores, hosting compartido, paneles como cPanel, appliances de red y sistemas de proveedores. Pregunta a tus proveedores de SaaS y hosting si ya aplicaron el parche.
- Actualiza de inmediato. Las versiones corregidas son: Rama de PHPVersión corregida 8.58.5.12 8.48.4.27 8.38.3.36 8.28.2.35 8.1 o anteriorSin soporte oficial: backports de tu distribución o proveedor LTS, o migrar Usa los paquetes de tu distribución Linux cuando estén disponibles y reinicia todos los procesos de PHP después de actualizar.
- Si no puedes parchar hoy, mitiga. Desactiva
session.upload_progress.enabled(yfatal_error_backtracesen PHP 8.5), reinicia los workers, y en PHP-FPM considerapm.max_requests=1. Bloqueamultipart/form-dataen rutas que no reciben archivos. Apóyate en tu WAF o IPS (FortiWeb, perfiles IPS de FortiGate, Cloudflare) con firmas actualizadas. Ojo: cada medida es parcial; ninguna sustituye el parche. - Busca indicios de compromiso desde el 17 de octubre. Revisa si el usuario del servidor web (www-data, apache, nginx) lanzó terminales o procesos inesperados, si aparecieron webshells, y rota credenciales, tokens y llaves de API de los sistemas expuestos. Un EDR con visibilidad en servidores es clave aquí.
- Valida que realmente estás protegido. Ejecuta un escaneo de vulnerabilidades autenticado y una prueba de penetración externa sobre tus activos públicos para confirmar que no quedó ningún servidor olvidado.
Conclusión
PHP2Shell es una de las vulnerabilidades más serias de los últimos años: afecta al motor que sostiene buena parte de la web, se explota sin contraseña y ya hay atacantes usándola. La diferencia entre un susto y un incidente mayor estará en la velocidad de respuesta de los próximos días.
También es una señal de época. Que la IA haya acelerado la creación de este exploit significa que fallas antiguas, enterradas en código que nadie revisa, pueden convertirse en armas mucho más rápido que antes. El inventario de activos y la gestión de parches dejaron de ser tareas de mantenimiento: son controles de primera línea.
En Cyberseg Solutions acompañamos a organizaciones en la gestión de vulnerabilidades críticas, desde el inventario y la mitigación en firewalls hasta la validación con pruebas de penetración. Si quieres confirmar que PHP2Shell no tiene un punto de entrada en tu infraestructura, escríbenos.
Fuentes:
- Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched
- JFrog Security Research — PHP2Shell: All You Need to Know
- CrowdStrike — Protecting customers from PHP2Shell
- Imperva — PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment
- Sansec — PHP2Shell: Critical PHP RCE
- Cloudflare — Protections against php2shell
- Qualys — Find, mitigate and patch PHP2Shell
- Advisory PHP GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp
© 2026 Cyberseg Solutions. All rights reserved
