Entre el 20 y el 21 de octubre de 2026 el ecosistema PHP ha vivido su incidente de seguridad más grave en años. Dos vulnerabilidades en el núcleo del intérprete, bautizadas conjuntamente como PHP2Shell, permiten la ejecución remota de código sin autenticación (RCE) antes incluso de que se ejecute cualquier script del sitio. Es decir: no importa si tu web es WordPress, Drupal, Joomla, Magento o un desarrollo a medida; el fallo está en PHP, no en la aplicación.
La filtración prematura de los vectores de explotación, horas antes de que existiera un parche, obligó a una respuesta de emergencia coordinada entre el equipo de PHP, las principales distribuciones Linux y los proveedores de alojamiento. IONOS, donde alojamos la mayor parte de las webs que mantenemos, fue uno de los primeros en actuar.
Qué es PHP2Shell y por qué es tan grave
Ambas vulnerabilidades han sido clasificadas por el proyecto PHP con una puntuación CVSS v4.0 de 9.2 (Crítico). Algunos investigadores de seguridad, como watchTowr, las han valorado con un 10.0. El hallazgo corresponde al equipo de investigación de Wiz, que demostró ejecución remota de código contra instalaciones de WordPress, Drupal y Joomla.
CVE-2026-109618: corrupción de memoria por interrupción OOM
El motor Zend gestiona la directiva memory_limit mediante llamadas a longjmp() para abortar las peticiones que superan la cuota de memoria asignada. Si una petición rebasa ese límite mientras el intérprete está procesando estructuras internas en fase de parseo —por ejemplo, durante la recepción de subidas de archivos multipart/form-data—, el flujo de ejecución se interrumpe dejando estructuras a medio inicializar.
En la rutina de limpieza posterior al aborto, el recolector asume que los punteros son válidos e intenta liberar memoria que nunca llegó a inicializarse. Con técnicas de heap grooming, un atacante puede preparar reservas de memoria previas para tomar el control del puntero liberado y redirigir el flujo de instrucciones.
CVE-2026-109619: estado global persistente entre peticiones
Los procesos persistentes que reutilizan workers —PHP-FPM, mod_php o FrankenPHP— conservan referencias a estructuras internas después de producirse un error fatal en una petición anterior. Una petición posterior atendida por el mismo worker hereda punteros a memoria ya liberada (un use-after-free lógico en el ciclo de vida del proceso) antes de que la inicialización del entorno los restablezca a valores limpios.
El resultado es el mismo en ambos casos: código del atacante ejecutándose con los privilegios del proceso web, sin credenciales y sin que la aplicación haya llegado a intervenir.
Entornos afectados y versiones parcheadas
Están afectadas todas las instalaciones de PHP que atienden peticiones web, con independencia del modo de ejecución: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto PHP señala mod_php como el escenario de mayor riesgo. Según Wiz, el fallo está presente desde PHP 5.4 hasta la 8.5.11, lo que significa que llevaba más de una década latente.
El 21 de octubre a las 14:00 UTC el proyecto PHP publicó las versiones corregidas:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Las ramas 8.1 y anteriores han alcanzado el fin de su ciclo de vida y no reciben parche oficial. Quien siga en esas versiones depende de que su proveedor de hosting o su distribución Linux haya retroportado la corrección, o bien debe migrar a una rama soportada.
La respuesta de IONOS
IONOS activó su protocolo de emergencia la misma tarde del 21 de octubre, en cuanto se publicaron los parches. En su página de estado anunció que estaba instalando la actualización de seguridad en todos sus sistemas, con previsión de terminar en 24 horas, advirtiendo de posibles lentitudes o breves interrupciones en los servicios basados en PHP. Como medida preventiva adicional, desactivó temporalmente las instancias de Nextcloud hasta disponer del parche.
El 22 de octubre a las 10:32, IONOS informó de que los sistemas estaban estables y de que todos los servicios funcionaban con normalidad. En paralelo, publicó una nota oficial confirmando que la actualización ya estaba instalada en todas las plataformas que gestiona directamente: Hosting Web, Managed WordPress, MyWebsite, Managed Nextcloud y HiDrive Next. Los clientes de estos productos no tienen que hacer nada.
Hay un detalle que distingue a un proveedor serio de uno que simplemente reacciona: según la propia nota, antes de que existiera el parche IONOS ya había desplegado configuraciones de PHP adaptadas y reglas de cortafuegos para bloquear las peticiones sospechosas y reducir la ventana de exposición. Mitigación primero, corrección definitiva después. Es el orden correcto, y no todos los hostings lo siguieron.
Una excepción importante: quien gestione PHP por su cuenta en un VPS o servidor dedicado de IONOS es responsable de instalar la actualización. En esos entornos IONOS no interviene.
Qué significa esto para tu web WordPress
Si tu web está en un hosting gestionado de IONOS con PHP 8.2 o superior, está protegida. Pero conviene matizar tres cosas:
- El parche cierra la puerta, no revisa la casa. Hubo intentos de explotación contra proveedores de alojamiento durante la mañana del 21, antes de que saliera la corrección. Una web parcheada hoy puede haber sido comprometida ayer. Conviene revisar integridad de archivos, usuarios administradores y tareas programadas.
- PHP 8.1 o anterior es un riesgo real. Si tu web sigue en una rama sin soporte, PHP2Shell es el recordatorio definitivo de que migrar ya no es opcional. Muchos sitios WordPress antiguos siguen ahí por plugins que nadie ha actualizado.
- Un cortafuegos de aplicación ayuda, pero no sustituye al parche. Wordfence y reglas WAF reducen la superficie de ataque. La única corrección definitiva es la versión de PHP actualizada.
Este tipo de incidentes es exactamente la razón por la que existe nuestro servicio de mantenimiento WordPress profesional: verificar la versión de PHP de cada sitio, comprobar que el proveedor ha aplicado la corrección, revisar la integridad tras un incidente y migrar las webs que siguen en versiones sin soporte. Si sospechas que tu sitio pudo verse afectado antes del parche, disponemos también de un servicio de desinfección de páginas web WordPress.
Si no sabes en qué versión de PHP está tu web ni si tu proveedor ha aplicado la actualización, escríbenos y lo comprobamos.
