Actualizado: 22 de octubre de 2026
El 21 de octubre, numerosas páginas de gobiernos, hospitales, universidades y empresas dejaron de estar disponibles. En varios casos no se trataba de un ataque que hubiera derribado sus servidores, sino de una decisión preventiva: desconectar temporalmente servicios mientras llegaban las correcciones de dos vulnerabilidades críticas de PHP.
La alerta recibió el nombre de PHP2Shell y puso de manifiesto un problema poco visible para el usuario común. Una página puede tener WordPress, sus complementos y su sistema de acceso actualizados, pero continuar expuesta si el motor PHP que ejecuta su código contiene una vulnerabilidad.
La respuesta involucró a desarrolladores de software libre, investigadores que utilizaron inteligencia artificial, empresas de ciberseguridad, proveedores de hosting y organismos gubernamentales. Reconstruimos los hechos y explicamos qué debe comprobar realmente un administrador antes de declarar protegido su servidor.
¿Qué es PHP2Shell y por qué generó tanta preocupación?
PHP es un lenguaje de programación utilizado para construir sitios y aplicaciones web. Está presente en plataformas como WordPress, Drupal, Joomla y numerosas aplicaciones empresariales.
PHP2Shell es el nombre utilizado para dos vulnerabilidades identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas recibieron una puntuación crítica de 9,2 sobre 10 en CVSS 4.0.
Su gravedad reside en que, bajo determinadas condiciones, un atacante remoto podría ejecutar código en un servidor vulnerable sin conocer contraseñas ni disponer de una cuenta autorizada.
Las dos fallas están relacionadas con el tratamiento de la memoria:
CVE-2026-109618: un error de memoria durante el procesamiento de una solicitud puede dejar estructuras internas incompletas que PHP utiliza posteriormente de manera insegura.
CVE-2026-109619: determinados datos internos de una solicitud pueden conservar referencias a memoria ya liberada y ser reutilizados por una solicitud posterior.
El riesgo no se limita a una aplicación concreta. Se encuentra en el propio intérprete PHP. Por ello, actualizar únicamente WordPress o instalar un complemento de seguridad no resuelve estas vulnerabilidades.
Según la documentación oficial, el riesgo alcanza a diferentes formas de ejecutar PHP en servidores web, como Apache con mod_php, PHP-FPM, php-cgi, LiteSpeed y FrankenPHP. La exposición concreta depende de la configuración y del mecanismo de explotación.
Fuentes: PHP, Wiz Research y Cloudflare.
Cronología: de una investigación reservada a una alerta mundial
Agosto de 2026: investigadores identifican las vulnerabilidades
La investigación comenzó meses antes de que el público conociera PHP2Shell.
Ryan Austin, investigador de Calif, encontró una de las fallas durante un análisis del código de PHP con asistencia de inteligencia artificial. Wiz identificó y comunicó de manera independiente vulnerabilidades relacionadas.
Los hallazgos llevaron a una coordinación reservada con responsables de PHP y especialistas de seguridad. La finalidad era desarrollar correcciones antes de divulgar los detalles que podían facilitar ataques.
El trabajo también puso sobre la mesa un debate relevante: la inteligencia artificial permite examinar software complejo y encontrar errores difíciles de detectar, pero esas mismas capacidades pueden acelerar la investigación ofensiva.
Septiembre y octubre: preparación de las correcciones
La respuesta no consistió simplemente en modificar unas líneas de código.
Los responsables del proyecto PHP debían desarrollar y probar correcciones, mientras distribuidores de sistemas operativos y proveedores de hosting preparaban sus propios paquetes.
También participaron empresas de protección de tráfico web. Cloudflare informó que trabajó en reglas de su firewall de aplicaciones web, conocido como WAF, desde comienzos de octubre.
Estas medidas podían reducir la exposición, pero no sustituían la actualización del motor PHP.
20 de octubre: una filtración acelera los acontecimientos
La divulgación estaba prevista inicialmente para el 22 de octubre. Sin embargo, información sobre las vulnerabilidades comenzó a circular antes de tiempo, incluida una publicación en Hacker News que fue retirada.
El equipo de seguridad de PHP adelantó su calendario y emitió una advertencia pública para que los administradores prepararan actualizaciones de emergencia.
La filtración redujo el margen disponible para coordinar la defensa. Desde ese momento, los responsables de servidores debían identificar instalaciones vulnerables y preparar acciones sin disponer todavía de todas las correcciones.
21 de octubre: llegan los parches y comienzan las desconexiones preventivas
PHP publicó cuatro versiones de seguridad:
Rama de PHP
Primera versión oficial corregida
PHP 8.5
8.5.12
PHP 8.4
8.4.27
PHP 8.3
8.3.36
PHP 8.2
8.2.35
La Comisión Europea, ENISA, CERT-EU, Europol y la red europea de equipos de respuesta a incidentes emitieron una declaración conjunta para recomendar acciones inmediatas.
El mensaje fue claro: identificar las aplicaciones que utilizan PHP, actualizar los componentes expuestos a internet y considerar su aislamiento temporal cuando no fuera posible corregirlos.
Mientras tanto, comenzaron a conocerse interrupciones de servicios públicos y privados.
22 de octubre: el trabajo continúa en los proveedores
La publicación de las correcciones oficiales no significó que todos los servidores del mundo quedaran protegidos de inmediato.
Los proveedores de sistemas operativos y hosting necesitaban adaptar, compilar, distribuir y verificar sus paquetes. En instalaciones administradas, el operador debía comprobar tanto el parche disponible como la versión que realmente estaba utilizando cada aplicación.
Este detalle resulta especialmente importante en servidores con varias ramas de PHP instaladas y diferentes sistemas de ejecución.
¿Qué gobiernos, empresas e instituciones se vieron afectados?
Los reportes de Reuters y de medios locales europeos documentaron interrupciones preventivas en varios países.
En Alemania, el proveedor federal de servicios informáticos ITZBund retiró temporalmente varias páginas de internet.
En Francia, se informaron medidas sobre servicios gubernamentales, incluido el ámbito del Ministerio del Interior.
En Países Bajos, la Cámara de Representantes suspendió temporalmente su sitio web. También se reportaron interrupciones relacionadas con el Puerto de Róterdam, entidades sanitarias, asociaciones profesionales y servicios educativos.
La agencia neerlandesa ANP identificó hospitales cuyos sitios o servicios digitales dejaron de estar disponibles, entre ellos Maastricht UMC+, Jeroen Bosch Ziekenhuis y BovenIJ. Algunas instituciones conservaron su página principal, pero restringieron funcionalidades concretas.
También se notificaron medidas en Finlandia, Bélgica y la República Checa. La Fundación Wikimedia informó de la suspensión temporal de algunos sistemas mientras realizaba tareas de protección.
En el sector tecnológico, Cisco publicó una evaluación de sus productos. Su comunicado identificó servicios confirmados como no vulnerables, entre ellos Cisco Umbrella y determinados servicios alojados en la nube, mientras continuaba investigando otros productos.
Esto permite distinguir tres situaciones diferentes:
Servicio desconectado preventivamente: no demuestra que haya sido hackeado.
Producto potencialmente vulnerable: requiere evaluar su versión y configuración.
Intrusión confirmada: necesita pruebas específicas de explotación y compromiso.
La existencia de intentos de ataque tampoco demuestra que todos hayan tenido éxito. Hasta el cierre de esta investigación no existe evidencia pública suficiente para atribuir una intrusión exitosa a cada una de las instituciones mencionadas.
Fuentes: Reuters, NL Times, ANP, cobertura de hospitales y Cisco Security Advisory.
¿Quiénes ayudaron a contener la emergencia?
La investigación y la respuesta fueron colectivas.
Calif y Wiz contribuyeron al descubrimiento y análisis de las vulnerabilidades. OpenAI participó en la iniciativa de investigación asistida por inteligencia artificial y en la coordinación de divulgación responsable.
Los desarrolladores de PHP y la PHP Foundation asumieron la tarea central de preparar y publicar las correcciones.
Cloudflare desarrolló protecciones WAF y comunicó que las activó por defecto antes de la divulgación pública para clientes de sus servicios correspondientes.
CloudLinux, cPanel, Ubuntu y otros distribuidores trabajaron en llevar las correcciones a sus paquetes, incluidos sistemas que mantienen versiones de PHP distintas de las oficiales más recientes.
ENISA, CERT-EU, las autoridades nacionales de ciberseguridad y otros organismos ayudaron a transmitir advertencias y recomendaciones a administradores e instituciones.
El episodio demuestra el valor de la divulgación coordinada. Descubrir una vulnerabilidad es solo el principio. También es necesario desarrollar una corrección, distribuirla, instalarla y comprobar que los sistemas la utilizan.
¿Qué ocurrió con CloudLinux, cPanel y los servidores de hosting?
CloudLinux publicó una comunicación específica para las dos vulnerabilidades y explicó su plan de distribución de correcciones.
Su respuesta incluyó paquetes ALT-PHP, utilizados por PHP Selector, y EA-PHP, asociados a EasyApache y al ecosistema cPanel. También informó sobre protecciones de Imunify360 y paquetes para sistemas con soporte extendido.
Aquí aparece una dificultad frecuente en el hosting compartido: un servidor puede tener PHP 8.4 y PHP 8.5 instalados en varias familias de paquetes, mientras cada cliente utiliza una versión diferente.
Actualizar una sola familia no garantiza que todas las aplicaciones estén protegidas.
Existe otra distinción fundamental. Algunos proveedores aplican backports, es decir, incorporan una corrección de seguridad a una versión anterior sin cambiar necesariamente su número principal.
Por eso, para confirmar una corrección hay que revisar el aviso del proveedor, el paquete instalado y su registro de cambios. La simple ejecución de php -v no siempre basta.
Fuente: Estado oficial de CloudLinux y comunicado técnico de CloudLinux.
Lecciones desde la administración de tres servidores
Durante esta emergencia también revisamos tres servidores de producción basados en CloudLinux y cPanel.
La experiencia permitió identificar errores de procedimiento que pueden repetirse en otras empresas de hosting.
Primera lección: actualizar no es lo mismo que inventariar.
Una revisión centrada únicamente en los paquetes pendientes puede dejar fuera una rama de PHP que todavía no está instalada. Por ello, el mantenimiento debe comparar las versiones existentes, las disponibles y las utilizadas realmente por los clientes.
Segunda lección: ALT-PHP y EA-PHP requieren verificaciones independientes.
Aunque ambas familias pertenezcan al mismo servidor, sus paquetes, extensiones y configuraciones pueden ser diferentes. La revisión debe incluirlas en una misma planificación.
Tercera lección: una extensión puede existir sin aparecer cargada en una prueba CLI.
Durante nuestras verificaciones, MySQLi y PDO MySQL aparecieron como no cargados en una ejecución directa del intérprete. Sin embargo, las bibliotecas estaban instaladas y una prueba funcional explícita confirmó su funcionamiento.
La causa de la diferencia estaba relacionada con el contexto de configuración utilizado por la línea de comandos. No justificaba reinstalar PHP ni modificar indiscriminadamente los archivos de configuración.
Cuarta lección: CageFS, PHP Selector y el sitio web no son equivalentes.
Comprobar que CageFS está habilitado no demuestra por sí solo que una aplicación funcione correctamente dentro de él. Tampoco basta con comprobar que Apache o MariaDB están activos.
La validación debe considerar la cuenta, la versión PHP seleccionada, las extensiones y, cuando corresponda, una prueba HTTP controlada.
Quinta lección: no se debe confundir estabilidad con seguridad.
Nuestros registros mostraron PHP 8.5.11 funcionando correctamente, con sus módulos MySQL disponibles. Sin embargo, esa comprobación funcional no certifica que los paquetes contengan las correcciones de PHP2Shell.
Las versiones oficiales corregidas publicadas el 21 de octubre son posteriores. Para considerar protegido un servidor con paquetes del proveedor, necesitamos comprobar documentalmente que el parche fue incorporado.
Esta es probablemente la enseñanza más importante de toda la intervención.
¿Cómo proteger un servidor frente a PHP2Shell?
El primer paso es identificar todas las instalaciones PHP que atienden solicitudes web. Esto incluye versiones antiguas, entornos alternativos, aplicaciones integradas y componentes administrados por terceros.
Después corresponde comprobar si cada instalación tiene una versión oficial corregida o un paquete del proveedor con el parche incorporado.
En servidores cPanel y CloudLinux, la revisión debe abarcar ALT-PHP, EA-PHP, PHP Selector, MultiPHP y los mecanismos reales de ejecución.
También conviene mantener las protecciones WAF, revisar registros de solicitudes sospechosas y comprobar procesos o archivos inesperados. Si existen indicios de intrusión, deben conservarse las evidencias antes de realizar cambios que puedan destruirlas.
Las medidas temporales publicadas por PHP, como determinados ajustes de sesiones y memoria, pueden reducir algunos riesgos. No son sustitutos completos de los parches. Además, cualquier cambio de configuración debe evaluarse según la aplicación y contar con respaldo y posibilidad de reversión.
Una vez instaladas las correcciones, es necesario verificar que los procesos web están utilizando el código actualizado. Según la arquitectura, puede requerirse reiniciar de manera controlada los procesos PHP correspondientes. Instalar paquetes sin comprobar qué procesos siguen activos puede dejar una protección incompleta.
Para los propietarios de páginas web que no administran sus propios servidores, la recomendación es solicitar al proveedor de hosting una confirmación específica de las correcciones aplicadas, no conformarse únicamente con que la página esté funcionando.
¿Qué nos enseñó PHP2Shell?
PHP2Shell no fue únicamente una emergencia de programación. También expuso la dependencia de miles de servicios respecto de componentes que normalmente permanecen invisibles para sus usuarios.
La inteligencia artificial ayudó a descubrir errores complejos. Los investigadores los comunicaron, los mantenedores desarrollaron correcciones, las empresas de infraestructura prepararon defensas y numerosas instituciones decidieron reducir temporalmente su exposición.
Pero la última responsabilidad continúa estando en cada operador: conocer sus sistemas, aplicar las correcciones y comprobar su efectividad.
Un servidor puede estar encendido, responder rápidamente y ejecutar todas sus aplicaciones sin errores, y aun así necesitar una actualización crítica de seguridad.
Esa diferencia entre funcionamiento y protección es la principal lección que deja PHP2Shell.