PHP2Shell: la falla crítica de PHP

El 21 de octubre de 2026 a las 14:00 UTC, el equipo de PHP publicó parches de emergencia para dos vulnerabilidades críticas en el propio motor del lenguaje. Seis horas antes, Cloudflare ya estaba viendo ataques. Si tu empresa tiene un sitio web, una tienda en línea o un sistema administrativo, casi con certeza corre sobre PHP — y actualizar tu WordPress no te protege de esto.

Qué es PHP2Shell

PHP2Shell es el nombre de la investigación —y del exploit que la demuestra— detrás de dos vulnerabilidades en el intérprete de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas con calificación CVSS 9.2 (crítica). El equipo de watchTowr llegó a calificar el conjunto con un 10.0 redondo.

Lo que permiten, combinadas, es ejecución remota de código sin autenticación y sin interacción del usuario. Una sola petición HTTP, sin contraseña, sin estar registrado, sin hacer clic en nada.

CVE-2026-109618 — fuga de memoria del servidor

Un uso de memoria después de liberarla (use-after-free) en el manejador de progreso de subidas de PHP. El resultado es que el servidor puede devolver memoria liberada de otras peticiones dentro de la cookie PHPSESSID. Esa memoria puede contener contraseñas, tokens de sesión, llaves de API y hasta llaves privadas TLS de usuarios que estaban navegando en ese mismo momento.

El detalle que lo vuelve grave: funciona incluso si tu aplicación nunca llama a session_start().

CVE-2026-109619 — ejecución de código

El mismo patrón en otra parte del motor: estado interno que sobrevive después de que su memoria fue liberada, en el backtrace de errores fatales y en la memoria compartida de OPcache. Una petición posterior sobre el mismo worker usa ese estado viejo, y ahí es donde el atacante mete su código.

Por qué esto es distinto a cualquier parche que hayas aplicado

La falla no está en tu aplicación: está en el motor que la ejecuta. Y PHP procesa las peticiones multipart/form-data —las que se usan para subir archivos— antes de que corra una sola línea de tu código.

Esto tiene una consecuencia incómoda: no importa qué tan limpio esté tu sitio. Los investigadores demostraron ejecución remota sin autenticación contra instalaciones completamente actualizadas de:

• Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4
• phpMyAdmin 5.2.3, Nextcloud 35.0.1, Roundcube 1.7.4, MediaWiki 1.46.2
• Laravel 13.11, Symfony 8.1 y WHMCS

Y según el aviso oficial, un simple "Hola mundo" en PHP sobre un runtime afectado también puede serlo. No es un problema de CMS. Es un problema de PHP.

Qué versiones están afectadas

El código vulnerable se remonta a PHP 5.4.0, de 2012. En la práctica: todo servidor web que ejecute PHP 5.4 o posterior, en cualquier modo —mod_php de Apache, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. Las configuraciones por defecto son vulnerables, y mod_php es el escenario de mayor riesgo.

Si corres PHP 8.1, 8.0, 7.4 o algo más viejo, no hay actualización oficial que instalar. El equipo de PHP liberó parches mínimos de código fuente para 7.4, 8.0 y 8.1, pensados para quien compila desde fuente o tiene un proveedor con soporte extendido. Para todos los demás, la única salida real es migrar a una rama con soporte.

El problema específico de las PyMEs mexicanas

Aquí está el punto que casi nadie te va a explicar con claridad: si tu sitio está en hosting compartido, tú no puedes aplicar este parche.

En cPanel puedes elegir la rama de PHP que usa tu cuenta, pero el binario que ejecuta esa rama lo mantiene tu proveedor de hosting. Que el panel diga "PHP 8.2" no te dice nada: lo que importa es si ese 8.2 es 8.2.35 o posterior.

Dos escenarios que vemos todo el tiempo en empresas de Sonora y el noroeste:

• Sitios en PHP 7.4 u 8.0 "porque así funciona el sistema del contador". Esas ramas ya no reciben parches. La deuda técnica que parecía inofensiva acaba de convertirse en exposición directa a ejecución remota de código.
• Servidores propios o VPS sin nadie que los administre. Comprados hace tres años, nunca actualizados, corriendo el sistema de facturación o el ERP. Nadie los está mirando hoy.

Qué hacer hoy, según tu caso

Si tienes hosting compartido

1. Entra a cPanel y revisa en Select PHP Version qué rama usas.
2. Abre un ticket con tu proveedor y pregunta la versión exacta, con los tres números. No aceptes "ya estamos en 8.2": pide 8.2.35 o superior.
3. Si te dicen que tardarán días, pregunta si pueden mover tu cuenta a una rama ya parchada.
4. Si corres 8.1 o anterior, pide el plan de migración por escrito.

Si tienes servidor propio o VPS

1. Actualiza PHP en todos los runtimes del servidor, no solo el del sitio principal. Incluye los que sirven aplicaciones internas o a medida.
2. Reinicia Apache, PHP-FPM y cualquier worker de larga duración. Sin reinicio, el proceso viejo sigue en memoria y sigue vulnerable.
3. Usa los paquetes de tu distribución. Si usas el repositorio de Remi, verifica que ya tenga la corrección: el 21 de octubre todavía no la tenía.
4. Confirma la versión real con php -v y, por separado, con la que reporta el servidor web — no siempre son la misma.

Si no puedes parchar en las próximas horas

Existen mitigaciones temporales, pero quiero ser muy claro: cada una es parcial y todas tienen costo. Son para ganar horas, no para quedarse así.

• session.upload_progress.enabled = 0 — cierra la vía principal, pero no toca las rutas de OPcache ni de backtrace.
• fatal_error_backtraces = 0 — solo aplica a PHP 8.5.
• pm.max_requests = 1 — rompe el requisito de que dos peticiones caigan en el mismo worker. Cuesta rendimiento.
• Bloquear multipart/form-data en el servidor web — efectivo, pero rompe todas las subidas de archivos y posiblemente tu checkout. Si lo haces, prueba una compra completa después.
• No uses RLIMIT_AS ni RLIMIT_DATA como sustituto del límite de memoria: el aviso oficial lo desaconseja explícitamente.

Después de cambiar cualquiera de estos ajustes, reinicia todos los workers o el cambio no surte efecto.

Si usas Cloudflare, ya tienen reglas de WAF desplegadas para los vectores conocidos, disponibles en todos los planes, incluido el gratuito. Actívalas. Pero no te confundas: un WAF filtra los ataques que ya conoce. No sustituye el parche.

Cómo saber si ya te atacaron

No hay todavía indicadores de compromiso públicos —ni hashes, ni IPs, ni dominios. Lo que sí hay son patrones que vale la pena cazar en tus registros:

• Peticiones multipart/form-data anómalas hacia endpoints PHP, especialmente con nombres de campo inusualmente largos.
• Caídas de workers o errores de agotamiento de memoria en ráfagas. El ataque depende de provocar un error fatal, así que los crashes son parte del método, no un efecto secundario.
• Ataques observados desde las 07:43 UTC del 21 de octubre, seis horas antes de que existiera el parche. Si tus registros llegan a esa fecha, revísalos.

El equipo de Corelight publicó detecciones abiertas para Zeek y Suricata que buscan precisamente estos comportamientos: secuencias de crashes de PHP, inundación de cabeceras multipart, claves de formulario demasiado largas y patrones de datos serializados sospechosos.

Y una advertencia del aviso oficial que conviene tomar en serio: la ausencia de señales sospechosas no prueba que no te afectó. Parcha de todos modos.

Cuidado con los "exploits" que circulan en GitHub

Ya hay pruebas de concepto falsas publicadas. Investigadores encontraron al menos una que escondía un payload en Base64 — en ese caso solo cambiaba el fondo de pantalla de quien la ejecutaba, pero el siguiente no va a ser tan amable.

No descargues ni ejecutes código de prueba sin verificar. Si necesitas validar si tu servidor es vulnerable, revisa la versión; no corras exploits de desconocidos en tu propia infraestructura.

Lo que esto dice sobre hacia dónde va la seguridad

Hay un detalle en esta historia que no deberías pasar por alto. Estas fallas llevaban más de una década en el código de PHP sin que nadie las encontrara. Lo que cambió fue el método: los equipos de Wiz Research, OpenAI Codex Security y el investigador Calif las hallaron y construyeron el exploit apoyándose en modelos de IA de frontera, que según el propio reporte bajaron sustancialmente la barrera para armar cadenas de explotación complejas.

En enero escribimos sobre el megahackeo Chronus, donde el atacante usó IA generativa para automatizar reconocimiento y exfiltración. Esta vez la IA estuvo del lado de la investigación y el parche llegó antes del ataque masivo. Pero la conclusión operativa es la misma: la ventana entre "se descubre una falla" y "se explota en masa" se está cerrando. Aquí fueron seis horas, y en contra.

En ese mundo, tener un inventario de qué versiones corres y un proceso de parcheo que no dependa de que alguien se acuerde deja de ser buena práctica y pasa a ser el mínimo.

¿Necesitas ayuda para revisar tu exposición?

Si no sabes qué versión de PHP corre tu sitio, si tu proveedor no te responde, o si sospechas que algo ya pasó en tu servidor, podemos ayudarte a revisarlo.

• Revisión de exposición — identificamos todos tus runtimes de PHP, sus versiones exactas y qué tan expuestos están. Escríbenos.
• ¿Crees que ya te comprometieron? Nuestra línea de respuesta a incidentes opera 24/7: almstra.com/bajo-ataque.
• Diagnóstico gratuito de 45 minutos si quieres entender tu postura general antes de decidir algo. Agéndalo aquí.

Actualizaremos este artículo conforme se publiquen indicadores de compromiso y análisis adicionales.