Los investigadores han identificado dos vulnerabilidades con una puntuación de gravedad de 9,2 sobre 10 que podrían permitir tomar el control de servidores sin necesidad de autenticarse. PHP ha publicado parches de seguridad, varios proveedores de alojamiento ya han distribuido actualizaciones y una nueva vulnerabilidad ha ampliado la alerta este 23 de octubre.
La comunidad tecnológica se encuentra en alerta tras la publicación de dos vulnerabilidades críticas en PHP, el lenguaje de programación que utilizan millones de páginas web y aplicaciones en todo el mundo. Los fallos, identificados como CVE-2026-109618 y CVE-2026-109619, pueden permitir la ejecución remota de código sin que el atacante necesite disponer de una cuenta o iniciar sesión en el sistema afectado.
El equipo de desarrollo de PHP publicó las versiones corregidas el 21 de octubre, mientras que organismos europeos de ciberseguridad han recomendado aplicar las actualizaciones con carácter urgente. Además, el 23 de octubre se ha conocido una tercera vulnerabilidad relacionada con la ejecución remota de código, lo que obliga a extremar las precauciones incluso en entornos que ya han instalado los primeros parches.
El incidente, conocido en el ámbito de la seguridad como parte de la alerta «PHP2Shell», no significa que todos los sitios web que utilizan PHP hayan sido pirateados. Sin embargo, sí pone de manifiesto un riesgo importante: un servidor vulnerable y expuesto a Internet podría convertirse en objetivo de un ataque capaz de comprometer su funcionamiento y los datos que almacena.
¿Qué es PHP y por qué afecta a tantas páginas web?
PHP es un lenguaje de programación de código abierto que se ejecuta principalmente en el servidor. Su función es generar contenido dinámico, procesar formularios, gestionar sesiones de usuario, consultar bases de datos y ejecutar la lógica interna de las aplicaciones web.
A diferencia de HTML, que define la estructura del contenido mostrado en el navegador, PHP permite realizar operaciones antes de entregar la página al visitante. Por ejemplo, cuando un usuario inicia sesión en una tienda online, consulta sus pedidos o publica un comentario, PHP puede intervenir en el procesamiento de esa solicitud.
Su popularidad se debe a su flexibilidad, su amplia documentación y su integración con numerosas plataformas. Entre ellas destaca WordPress, además de sistemas de comercio electrónico, gestores de contenidos, foros, aplicaciones empresariales y paneles de administración.
Por este motivo, una vulnerabilidad en el propio intérprete de PHP puede tener consecuencias mucho más amplias que un fallo limitado a una aplicación concreta. El problema afecta al entorno que ejecuta el código, por lo que actualizar únicamente WordPress, un complemento o una plantilla no soluciona estas vulnerabilidades.
En qué consiste el ataque: dos fallos que pueden permitir tomar el control del servidor
Las dos vulnerabilidades anunciadas el 21 de octubre tienen una puntuación de 9,2 sobre 10 en el sistema CVSS, una clasificación que las sitúa en la categoría crítica.
La primera, CVE-2026-109618, está relacionada con la gestión de errores por falta de memoria, conocida como out-of-memory u OOM. PHP utiliza mecanismos internos para detener solicitudes que superan determinados límites de memoria. En ciertas circunstancias, esta interrupción puede producirse cuando los datos internos de una petición todavía no están completamente inicializados.
Durante la limpieza posterior al error, el intérprete puede tratar información inválida como si fuera correcta y manipular zonas de memoria que no deberían utilizarse de esa manera. Bajo condiciones específicas, un atacante puede aprovechar esta corrupción de memoria para conseguir ejecutar código en el servidor.
La segunda vulnerabilidad, CVE-2026-109619, está vinculada a un problema de estado interno obsoleto. Determinada información asociada a una petición puede permanecer disponible después de que la memoria que la respaldaba haya sido liberada. Una solicitud posterior, procesada por el mismo trabajador, podría reutilizar ese estado en condiciones inseguras.
En ambos casos, el resultado potencial es la ejecución remota de código, conocida por sus siglas en inglés RCE (Remote Code Execution). Este tipo de fallo permite que un atacante ejecute instrucciones en el sistema afectado sin disponer previamente de acceso legítimo.
Las consecuencias dependerán de los permisos del proceso comprometido y de la configuración del servidor. Entre los posibles escenarios figuran el robo de información, la instalación de puertas traseras, la modificación de archivos, el acceso a credenciales y el uso del servidor para lanzar nuevos ataques.
El equipo de PHP ha advertido de que determinadas configuraciones pueden presentar un riesgo especialmente elevado, entre ellas Apache con el módulo mod_php. También se encuentran expuestos los entornos que utilizan PHP-FPM, php-cgi, FrankenPHP o LiteSpeed.
La publicación de detalles técnicos y de pruebas de concepto aumenta la urgencia de las actualizaciones, ya que facilita que otros investigadores y posibles atacantes estudien los fallos.
¿Qué versiones de PHP son vulnerables?
Las ramas principales afectadas y sus correspondientes versiones corregidas son las siguientes:
| Rama de PHP | Versiones vulnerables | Versión corregida |
|---|---|---|
| PHP 8.5 | Versiones anteriores a 8.5.12 | 8.5.12 |
| PHP 8.4 | Versiones anteriores a 8.4.27 | 8.4.27 |
| PHP 8.3 | Versiones anteriores a 8.3.36 | 8.3.36 |
| PHP 8.2 | Versiones anteriores a 8.2.35 | 8.2.35 |
| PHP 8.1 y anteriores | Ramas sin soporte oficial vigente | Actualizar o migrar |
Importante: las versiones indicadas deben contrastarse con los avisos oficiales de PHP y del proveedor de alojamiento. Algunas distribuciones pueden aplicar parches de seguridad sin cambiar el número de versión principal.
La tabla recoge las correcciones oficiales para las ramas mantenidas por el proyecto. En las versiones antiguas pueden existir paquetes con correcciones retroportadas por distribuidores o proveedores de soporte extendido. Por ello, el número de versión por sí solo no siempre permite determinar si una instalación antigua está protegida: también hay que comprobar la compilación y los avisos del proveedor.
Las versiones de PHP anteriores a la 8.2 requieren especial atención, puesto que han dejado de recibir actualizaciones de seguridad ordinarias del proyecto. Aunque algunos proveedores ofrecen correcciones específicas para estas ramas, mantenerlas implica mayores riesgos y exige verificar expresamente el estado de los parches.
Las recomendaciones oficiales pueden consultarse en el archivo de seguridad de PHP y en los avisos de CERT-EU.
Nueva alerta del 23 de octubre: aparece una tercera vulnerabilidad
La situación ha evolucionado durante las últimas horas. CERT-EU ha incorporado a su aviso una tercera vulnerabilidad, identificada como CVE-2026-115560, que también podría permitir la ejecución remota de código.
Según la información disponible el 23 de octubre, el fallo afecta a aplicaciones web configuradas de una manera poco habitual. PHP considera que el riesgo es menos probable y no ha anunciado una actualización extraordinaria inmediata para este nuevo problema, sino una mitigación temporal hasta la siguiente versión correctiva ordinaria.
La medida indicada es desactivar session.upload_progress.enabled y reiniciar todos los procesos trabajadores de PHP para que el cambio entre en vigor.
Este nuevo aviso demuestra que instalar los parches de las dos primeras vulnerabilidades es imprescindible, pero no sustituye la necesidad de seguir los avisos oficiales posteriores. Los administradores deben comprobar tanto las actualizaciones del intérprete como las recomendaciones específicas que se publiquen para cada vulnerabilidad.
¿Qué medidas deben tomar los propietarios de páginas web?
La prioridad es verificar qué versión de PHP ejecuta cada aplicación y aplicar las actualizaciones correspondientes. Las principales recomendaciones son:
1. Actualizar PHP inmediatamente. Los administradores de servidores propios deben instalar las versiones corregidas desde los repositorios oficiales o los canales de actualización de su distribución. En alojamientos administrados, deben confirmar con el proveedor que el parche se ha aplicado al intérprete que realmente utiliza cada sitio.
2. Comprobar todas las instalaciones. Un mismo servidor puede ejecutar varias versiones de PHP para distintos dominios, subdominios o aplicaciones. Actualizar una sola versión no garantiza que el resto esté protegido.
3. Revisar los registros del servidor. Conviene analizar los registros de acceso, errores y actividad del sistema en busca de solicitudes anómalas, procesos inesperados, modificaciones de archivos o indicios de acceso no autorizado. La actualización no elimina una posible puerta trasera que se hubiera instalado previamente.
4. Reforzar las medidas de protección. Un cortafuegos de aplicaciones web (WAF), las restricciones de solicitudes y los límites de carga pueden reducir determinados vectores de ataque. Sin embargo, estas medidas no sustituyen el parche de seguridad.
5. Aislar temporalmente los sistemas que no puedan actualizarse. Si un servidor expuesto a Internet no puede recibir la corrección, las autoridades recomiendan valorar su aislamiento hasta que pueda protegerse adecuadamente.
6. Mantener copias de seguridad verificadas. Las copias deben estar protegidas frente a modificaciones no autorizadas y permitir restaurar los servicios desde un entorno limpio si se detecta una intrusión.
Para el tercer fallo, los administradores deben aplicar además la mitigación específica indicada por PHP y CERT-EU. Estas medidas temporales no deben confundirse con una solución definitiva para las dos vulnerabilidades críticas originales.
Algunos proveedores de hosting ya han distribuido los parches
La respuesta de los proveedores de alojamiento y de las plataformas de administración de servidores ya está en marcha. A fecha de 23 de octubre de 2026, existen actualizaciones publicadas para entornos que utilizan cPanel y Plesk, aunque esto no significa que todos los servidores de todos los proveedores estén actualizados automáticamente.
cPanel ha documentado versiones corregidas de EasyApache 4 para las ramas PHP 7.4 y posteriores, incluidas las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. También ha publicado instrucciones para actualizar los paquetes y comprobar que contienen las correcciones.
Por su parte, Plesk ha confirmado la disponibilidad de versiones corregidas para sus entornos Linux y Windows en las ramas 8.2, 8.3, 8.4 y 8.5. Para algunas ramas antiguas, la corrección se distribuye mediante compilaciones específicas que pueden conservar el mismo número de versión, por lo que resulta necesario comprobar la fecha de compilación y el estado del paquete.
Los propietarios de sitios web alojados en servidores compartidos no siempre necesitan instalar manualmente el intérprete. No obstante, deben comprobar el estado de su alojamiento y solicitar confirmación si no encuentran información clara sobre las actualizaciones.
En WordPress, la versión de PHP puede consultarse desde Herramientas > Salud del sitio > Información > Servidor. También suele estar disponible en el panel de control del alojamiento.
Una actualización que no conviene posponer
Las vulnerabilidades de PHP ponen de relieve la importancia de mantener actualizada la infraestructura que sostiene una página web. Aunque una aplicación esté correctamente programada y sus complementos estén al día, un fallo en el intérprete puede comprometer la seguridad de todo el servicio.
A fecha de 23 de octubre, los parches para las dos vulnerabilidades críticas iniciales ya están disponibles en las ramas mantenidas, y algunos proveedores han publicado correcciones para entornos adicionales. La aparición de una tercera vulnerabilidad obliga, además, a revisar las recomendaciones de mitigación más recientes.
La conclusión para administradores, empresas y propietarios de sitios web es clara: comprobar la versión de PHP, verificar las actualizaciones aplicadas y revisar posibles indicios de intrusión son tareas prioritarias. Esperar a que el proveedor actúe sin confirmar el estado real del servidor puede dejar una aplicación expuesta durante más tiempo del necesario.
En un escenario en el que los fallos de ejecución remota de código pueden comprometer servicios completos, la rapidez de respuesta y la verificación técnica de las medidas adoptadas son esenciales para reducir el riesgo.