La mayoría de los problemas de seguridad que vemos en un sitio vienen de la aplicación: un plugin abandonado, un tema pirata, una contraseña reutilizada. Esta vez es distinto. La falla está un piso más abajo, en PHP, el motor sobre el que corre buena parte de la web: WordPress, WooCommerce, Laravel, Magento y miles de sitios hechos a mano. No importa qué tengas encima.
El 21 de octubre de 2026, el equipo de PHP publicó parches de emergencia. El motivo tiene nombre: PHP2Shell, dos vulnerabilidades críticas que permiten a un atacante anónimo ejecutar código en tu servidor o leer la memoria del proceso, con una sola petición. Sin clave. Sin que hagas clic en nada. Los detalles se filtraron antes de lo previsto y los primeros intentos de explotación aparecieron el mismo día.
¿Qué es PHP2Shell?
Son dos fallas con el mismo origen: CVE-2026-109618 y CVE-2026-109619. Ambas viven en el manejo del “progreso de subida de sesión”, una función que PHP trae activa de fábrica para mostrar cuánto avanza una subida de archivo.
El detalle técnico es de los finos: PHP lee un archivo de sesión antes de ejecutar cualquier línea de tu código, y un error de manejo deja apuntadores internos mirando a memoria que ya se liberó. Una petición posterior reutiliza esa memoria, y ahí está la grieta. En lenguaje llano: un desconocido desde internet puede terminar ejecutando código en tu servidor o leyendo datos de otras personas que estaban navegando tu sitio (claves, sesiones, formularios). Es una falla del tipo corrupción de memoria, la misma familia del histórico Heartbleed.
No estamos hablando de un ataque sofisticado que necesite un genio encapuchado. Estamos hablando de una petición bien armada contra un PHP sin actualizar.
¿Estás en riesgo?
Depende de tu versión de PHP. Este es el mapa de las ramas con soporte:
| Tu rama de PHP | Versión corregida |
|---|---|
| 8.5.x | 8.5.12 |
| 8.4.x | 8.4.27 |
| 8.3.x | 8.3.36 |
| 8.2.x | 8.2.35 |
| 8.1 / 8.0 / 7.4 (sin soporte) | migra a una rama con soporte |
La regla es simple: si el PHP que atiende tu web no está en 8.2.35, 8.3.36, 8.4.27, 8.5.12 o una versión superior, estás expuesto y hay que actuar hoy. Un detalle que confunde a muchos: la versión de PHP de la línea de comandos puede ser distinta a la que realmente sirve tu sitio. La que importa es la del servidor web.
Por qué esta vez es más grave de lo habitual
Cuando explicamos la ventana de exposición de una vulnerabilidad, el punto es que el reloj corre desde que se publica el parche, porque ahí también arranca la carrera de los atacantes. PHP2Shell marca todas las casillas:
- No requiere autenticación. Cualquiera en internet puede intentarlo.
- No requiere interacción. No depende de que un usuario tuyo caiga en una trampa.
- Funciona con la configuración de fábrica, sin nada raro de por medio.
- Es independiente de la aplicación. Da igual si tu sitio es WordPress o a medida: la falla está en PHP.
- Ya hay explotación activa y los detalles circulan, así que la barrera de entrada es baja.
No es un problema de nicho: es un problema de casi toda la web. Muchos sitios ni siquiera saben qué versión de PHP tienen detrás, porque llegó con el hosting o con la tienda que les armaron hace años.
Qué hacer hoy
1. Actualiza PHP. Es la única solución de fondo. Lleva tu rama a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 o superior. Si usas un hosting administrado, pídele a tu proveedor que confirme la versión y aplique el parche; si administras tu propio servidor, actualiza desde el gestor de paquetes de tu sistema. Este es exactamente el hábito del que hablamos en actualizar periódicamente, el más básico y el más ignorado.
2. Si no puedes actualizar al instante, mitiga. El día del aviso, los servidores que distribuyen los paquetes quedaron saturados por la demanda. Mientras llega el parche a tu sistema, desactivar el progreso de subida de sesión (session.upload_progress.enabled=0) y reiniciar el servicio reduce la vía principal del ataque. Es un parche a medias, no un reemplazo: apenas puedas, actualiza.
3. Confirma si estás afectado. Que tu panel diga “todo al día” no siempre significa que el parche se aplicó. En RealRisk publicamos la ficha completa de PHP2Shell, con el detalle técnico y su nivel de riesgo. Y ahí mismo encontrarás un verificador gratuito y no destructivo que confirma o descarta si tu servidor está afectado, mirando solo la versión, sin tocar ni gatillar nada.
El patrón de siempre
PHP2Shell asusta por la palabra “crítica”, pero la defensa es de las más aburridas que existen: mantener PHP al día. No hay que comprar una herramienta cara ni contratar a un experto de planta. Hay que estar atento y actualizar a tiempo. Es la misma historia que vimos hace unos meses con wp2shell en WordPress: falla crítica, parche el mismo día, y una carrera contra el reloj.
En Asentic, apenas se publicó el aviso, aplicamos la mitigación en todos los sitios que operamos y dejamos el upgrade en marcha para completarlo en cuanto el paquete esté disponible. Ese es el trabajo: no adivinar el próximo ataque genial, sino tapar a tiempo los agujeros conocidos.
Si no estás seguro del estado de tu sitio, nuestro diagnóstico gratuito FreeScan te da una foto de tu postura de seguridad en minutos, sin costo ni compromiso. Y si administras varios servidores, cruza cada uno contra la tabla de arriba antes de terminar el día.
Este material es informativo. Las versiones y fechas corresponden a los avisos oficiales de PHP al 21 de octubre de 2026. Ante una falla con explotación activa, prioriza siempre actualizar.
