- Dos vulnerabilidades críticas en el motor de PHP, CVE-2026-109618 y CVE-2026-109619, permiten ejecución remota de código sin autenticación y tienen una gravedad de 9,2 sobre 10.
- La alerta afecta a infraestructuras muy extendidas como WordPress, Drupal, Magento o MediaWiki, por lo que no basta con actualizar el CMS: hay que revisar la versión de PHP del servidor.
- Se detectaron intentos de explotación antes y después de la divulgación, mientras varios servicios públicos europeos optaron por desconectar sistemas de forma preventiva.
- La prioridad es aplicar los parches disponibles para las ramas mantenidas y, si no es posible, aislar los entornos expuestos y revisar registros en busca de actividad sospechosa.
La comunidad de PHP ha pasado de la rutina a una situación de emergencia en muy poco tiempo. Dos vulnerabilidades críticas localizadas en el motor del lenguaje, identificadas como CVE-2026-109618 y CVE-2026-109619, han encendido todas las luces rojas porque, en determinadas configuraciones, abren la puerta a ejecutar código en remoto sin necesidad de credenciales. La puntuación de 9,2 sobre 10 ayuda a entender por qué tantos administradores han tenido que dejar lo que estaban haciendo para revisar servidores.
El asunto no se limita a una aplicación concreta ni a un complemento mal actualizado. El problema está en el propio motor de PHP, lo que eleva el alcance potencial a plataformas muy populares como WordPress, Drupal, Magento o MediaWiki. De ahí que los parches publicados el 21 de octubre se hayan convertido en una prioridad para proveedores de alojamiento, equipos de TI y organizaciones que, hasta ahora, daban por hecho que su infraestructura estaba razonablemente protegida.
Qué es PHP2Shell y por qué se considera grave
PHP2Shell es el nombre con el que se ha popularizado esta crisis de seguridad. Los fallos tienen que ver con la gestión de memoria y con la forma en que el intérprete procesa ciertas peticiones web. En entornos vulnerables, una solicitud preparada con cuidado puede desencadenar un comportamiento anómalo que acabe en ejecución remota de código. La configuración con Apache y mod_php se ha señalado como especialmente delicada, aunque otras arquitecturas de ejecución también deben revisarse.
La gravedad no viene solo de la nota CVSS. Lo que preocupa es que el atacante no necesita autenticarse previamente para intentar aprovechar la brecha en según qué circunstancias. Eso no significa que cualquier instalación esté condenada ni que todos los sitios hayan sido atacados, pero sí explica la urgencia de las alertas: cuanto más tiempo permanezca expuesto un servidor sin corregir, más margen tiene quien busque sacar partido al fallo.
Cómo se llegó a la alerta: filtración y parche adelantado
La respuesta no siguió el calendario previsto. Los investigadores trabajaban en una divulgación coordinada, con la idea de publicar los detalles y las correcciones a la vez, pero la información se filtró antes de tiempo. Ese adelanto obligó a mover la fecha de publicación y a acelerar la salida de las actualizaciones, que finalmente llegaron el 21 de octubre en lugar de esperar al 22, tal como se había planteado en un principio.
El proyecto PHP publicó parches para las cuatro ramas que mantiene con soporte oficial. La aparición de esas versiones fue el pistoletazo de salida para una carrera entre administradores, empresas de seguridad y proveedores de infraestructura, que tuvieron que compaginar la prisa por actualizar con la necesidad de comprobar que los sistemas seguían funcionando correctamente. En un ecosistema tan grande, cada cambio tiene ramificaciones.
El papel de la inteligencia artificial
Uno de los detalles que más ha llamado la atención es que las herramientas de inteligencia artificial han tenido un peso considerable en la investigación. Según se ha explicado, los modelos avanzados ayudaron a localizar y validar problemas complejos que llevaban tiempo pasando desapercibidos. Esa capacidad de análisis acelera el trabajo de los defensores, pero también introduce una reflexión incómoda: las mismas técnicas pueden reducir el tiempo y los conocimientos necesarios para desarrollar ataques.
La inteligencia artificial no convierte a cualquiera en un atacante de la noche a la mañana, pero sí puede acortar barreras técnicas que antes frenaban a muchos actores. En este caso, los investigadores la utilizaron para comprender mejor el alcance de los fallos y preparar comprobaciones, mientras los responsables de PHP trabajaban en las correcciones. El debate ya no es solo si la IA ayuda, sino cómo se equilibra su uso entre quienes protegen sistemas y quienes buscan comprometerlos.
Efectos en Europa y servicios desconectados
La alerta tuvo consecuencias visibles en varios países europeos. Países Bajos, Bélgica y Francia confirmaron suspensiones voluntarias de servicios oficiales o adoptaron medidas preventivas mientras se evaluaba la exposición. CERT-EU y otros organismos recomendaron aislar las aplicaciones accesibles desde Internet cuando no fuera posible aplicar los parches de inmediato, una decisión drástica pero comprensible cuando hay información sensible y servicios públicos en juego.
Cloudflare informó de intentos de explotación contra sistemas de sus clientes, y Amazon también detectó actividad dirigida a PHP2Shell. En concreto, se han descrito intentos desde al menos el 17 de octubre, antes de que la divulgación fuera pública, y nuevas pruebas después de conocerse los detalles. Que se hayan visto intentos no equivale a confirmar un compromiso masivo, pero sí demuestra que el interés por aprovechar la brecha apareció con rapidez.
La dimensión del asunto se entiende mejor al mirar la cuota de PHP en la web. Distintas estimaciones sitúan su presencia en alrededor del 70 % de los sitios, y algunas fuentes elevan la cifra hasta el 75 %. Esa presencia masiva no implica que todos esos sitios sean vulnerables, porque influyen la versión instalada, la configuración del servidor y el tipo de aplicación, pero sí explica por qué un fallo en esta capa tecnológica puede acabar afectando a medios, tiendas, administraciones y servicios cotidianos.
Cómo proteger instalaciones PHP
Lo primero que deben comprobar los responsables de sistemas es la versión exacta de PHP. Las ramas corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12, según corresponda. Actualizar WordPress, Drupal o cualquier otro CMS no resuelve el problema por sí solo si el motor que ejecuta la aplicación sigue siendo vulnerable. En alojamientos compartidos, muchos proveedores ya han aplicado las correcciones, pero conviene confirmarlo con el soporte y no darlo por supuesto.
Quienes mantienen PHP 8.1 o versiones anteriores están en una situación más delicada, porque esas ramas ya no reciben soporte oficial del proyecto. Algunas distribuciones o proveedores de mantenimiento extendido pueden ofrecer parches adaptados, así que toca preguntar y revisar los avisos correspondientes. Si la actualización no se puede aplicar de forma inmediata, la alternativa pasa por aislar los sistemas expuestos, restringir accesos y revisar registros en busca de señales de actividad anómala.
También resulta útil mirar más allá del número de versión. En Linux es habitual que los parches se integren sin cambiar la cifra visible, por lo que los avisos del proveedor y los registros de cambios son una referencia importante. Además, no está de más comprobar si el hosting ha publicado algún comunicado sobre PHP2Shell, si ha desactivado temporalmente alguna función y si recomienda alguna medida adicional para los clientes.
Una dependencia crítica de Internet
El episodio deja una lección que va más allá de las dos vulnerabilidades concretas. Internet depende de piezas tecnológicas compartidas cuya seguridad se da por sentada hasta que algo falla. PHP sostiene una parte enorme de la web, desde gestores de contenido hasta servicios públicos, y eso lo convierte en un objetivo de especial interés. La respuesta rápida de la comunidad y de los proveedores ha sido relevante, pero también ha mostrado la presión que soportan proyectos esenciales cuando aparece un fallo de este calibre.
El balance práctico deja una idea clara: hay que parchear y revisar sin entrar en pánico, pero sin confiarse. Los parches ya están disponibles para las ramas mantenidas, los intentos de explotación se han detectado antes y después de la divulgación, y varios servicios europeos han preferido desconectar antes que asumir un riesgo innecesario. La seguridad de un sitio no depende solo de tener el CMS al día, sino también de saber qué versión de PHP lo está ejecutando y de actuar con rapidez cuando la infraestructura común queda expuesta.