El 21 de octubre de 2026 el equipo de PHP publicó un aviso de seguridad sobre dos fallas críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Para una empresa que administra hosting, servidores y sistemas a medida sobre PHP, fue probablemente la semana de seguridad más intensa que hemos vivido. En este artículo contamos qué pasó, cómo respondimos y qué aprendimos.
Qué es PHP2Shell y por qué fue tan grave
Se trata de dos fallas de manejo de memoria en el núcleo de PHP, con una severidad de 9.2 sobre 10 (CVSS 4.0), que permiten ejecutar código en el servidor con una sola petición y sin necesidad de usuario ni contraseña, antes incluso de que se ejecute el código de la aplicación. Afectan prácticamente a todas las versiones de PHP desde la 5.4 hasta la 8.5 y a todas las formas comunes de servir PHP: PHP-FPM, Apache con mod_php, LiteSpeed y otras.
Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Para las ramas sin soporte (7.4, 8.0 y 8.1) el equipo de PHP solo publicó parches mínimos de código fuente, sin versiones oficiales.
La magnitud del problema llegó a los grandes medios. The Wall Street Journal estimó que afecta hasta al 70% de los sitios web; la BBC, The New York Times y Reuters informaron que gobiernos, escuelas y hospitales desconectaron sus sitios mientras aplicaban la corrección, y The Guardian reportó millones de intentos de ataque en todo el mundo. Según The Hacker News, Amazon detectó un primer intento de explotación el 17 de octubre, cuatro días antes del anuncio, y agencias como CISA, la NSA, el FBI y el NCSC del Reino Unido pidieron actualizar de inmediato o desconectar los sistemas afectados.
Las primeras horas: informar antes que nada
Lo primero que hicimos fue lo que creemos que todo proveedor debe hacer: avisar. En la mañana del 22 de octubre enviamos un comunicado a todos nuestros clientes de hosting explicando qué era PHP2Shell, a quiénes afectaba y qué estábamos haciendo. Elegimos un lenguaje sencillo, sin tecnicismos innecesarios, porque la mayoría de nuestros clientes no son técnicos y lo que necesitan saber es si su sitio está en riesgo y qué tienen que hacer.
En paralelo coordinamos con nuestro proveedor de infraestructura la instalación de las versiones corregidas en todos los servidores de hosting compartido, de forma escalonada y con monitoreo de estabilidad. Esa misma tarde pudimos enviar un segundo comunicado confirmando que los parches ya estaban aplicados.
El problema de fondo: las versiones antiguas de PHP
Parchar los servidores resolvió la urgencia, pero dejó a la vista un problema que ya conocíamos: muchos sitios siguen funcionando con versiones de PHP que ya no reciben soporte. PHP 7.4, por ejemplo, dejó de tener soporte el 28 de noviembre de 2022, y PHP 8.2 lo pierde el 31 de diciembre de 2026.
Por eso, esa misma noche enviamos recomendaciones de actualización segmentadas según la versión que usa cada sitio (7.3, 7.4, 8.1 y 8.2). Un parche puntual puede cubrir PHP2Shell, pero una versión sin soporte no recibirá correcciones para las fallas que se descubran después. La única protección real a largo plazo es migrar a una versión vigente, y eso casi siempre implica revisar y ajustar el código del sitio.
Los servidores dedicados: un caso distinto
En el hosting compartido las actualizaciones las aplicamos de forma centralizada. En los servidores dedicados y en la infraestructura en la nube que administramos para algunos clientes, como instancias Amazon EC2 con bases de datos Amazon RDS, la situación es diferente: cada servidor tiene su propia configuración y sus propios sistemas, y una actualización de PHP debe ser planificada y ejecutada por un especialista, verificando antes y después que todo siga funcionando.
Aquí encontramos el escenario más delicado: empresas que conservan un sistema antiguo en PHP 7.4 porque les funciona y su operación diaria no les deja tiempo para revisar la versión migrada. Mientras ese sistema siga en uso, aunque se le aplique el parche de PHP2Shell, seguirá expuesto a cualquier vulnerabilidad futura. Mantuvimos estos servidores bajo monitoreo constante y, en paralelo, conversamos con cada cliente para darle prioridad a la migración.
Lo que aprendimos
- Comunicar rápido y claro vale tanto como parchar. Un cliente informado a tiempo confía más y colabora mejor.
- La deuda técnica tiene costo de seguridad. Las versiones sin soporte no son un problema de rendimiento, sino de exposición permanente.
- Segmentar ayuda. No todos los clientes necesitan el mismo mensaje: enviar recomendaciones según la versión de PHP de cada sitio hizo que cada uno supiera exactamente qué hacer.
- Los servidores dedicados necesitan un plan propio. Lo que en hosting compartido es automático, en un servidor dedicado requiere planificación y un especialista.
- La amenaza sigue activa. Al 26 de octubre ya se confirmaron ataques exitosos y se conoce una tercera falla relacionada, CVE-2026-115560, aún sin parche, según BleepingComputer. Seguimos atentos.
Si tu sitio usa PHP
Revisa qué versión de PHP utiliza tu sitio y actualízala a una versión corregida. Si usa PHP 8.1 o anterior, planifica cuanto antes la migración a una versión con soporte. Si eres cliente de Innovemus y tienes dudas, escríbenos a [email protected] o contáctanos a través de Nova en innovemus.com o por WhatsApp.
