¿Y si un ciberdelincuente pudiera atacar el servidor de tu empresa sin conocer ninguna contraseña y sin aprovechar un fallo de WordPress?
Esta es la situación que ha puesto en alerta a administradores de sistemas, proveedores de alojamiento web y responsables de ciberseguridad tras descubrirse dos vulnerabilidades críticas en PHP, una de las tecnologías más utilizadas para ejecutar páginas y aplicaciones web.
Los fallos, identificados como CVE-2026-109618 y CVE-2026-109619, se conocen conjuntamente como PHP2Shell. Ambos presentan una gravedad de 9,2 sobre 10 en la escala CVSS 4.0 y pueden permitir la ejecución remota de código sin necesidad de autenticación.
El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó actualizaciones extraordinarias para corregir estas vulnerabilidades. Sin embargo, la publicación de los parches no garantiza que todos los servidores de Internet los hayan instalado.
Para las empresas, el riesgo no se limita a la pérdida de disponibilidad de una página corporativa: dependiendo de la configuración y de los permisos del servidor, una explotación exitosa podría comprometer información, modificar contenidos o afectar a otros servicios.
La prioridad es comprobar qué versión de PHP está ejecutando realmente cada aplicación web y confirmar que se han instalado las correcciones de seguridad.
¿Qué ha ocurrido con las vulnerabilidades PHP2Shell?
El 20 de octubre de 2026, el equipo de seguridad de PHP anunció una actualización extraordinaria para resolver dos vulnerabilidades de gravedad crítica.
El aviso se produjo en un contexto especialmente delicado: los detalles de los fallos comenzaron a circular antes de su divulgación coordinada, reduciendo el margen de preparación de los administradores de sistemas.
Las actualizaciones se publicaron el 21 de octubre de 2026, incluyendo versiones corregidas para las principales ramas de PHP que reciben soporte oficial.
Según el comunicado de seguridad de PHP, estas vulnerabilidades afectan al procesamiento interno de solicitudes web, lo que resulta especialmente relevante porque determinados ataques pueden ejecutarse antes de que el código de una aplicación, como WordPress, llegue a intervenir.
Esto explica por qué actualizar únicamente los plugins, el tema o el propio gestor de contenidos no resulta suficiente para solucionar el problema.
Los intentos de explotación ya se han detectado
La amenaza no se ha quedado únicamente en una demostración técnica.
Cloudflare confirmó haber observado tráfico malicioso dirigido contra las vulnerabilidades y desplegó reglas específicas de protección en su firewall de aplicaciones web.
Por su parte, la compañía de ciberseguridad Imperva publicó cifras correspondientes a las primeras 24 horas de actividad observada tras la divulgación:
- 482.342 solicitudes asociadas a la amenaza.
- 21.998 sitios web identificados como objetivos.
- 103 países con sitios alcanzados por esta actividad.
Estos datos proceden de la telemetría de Imperva, no representan todo Internet y no significan que esos sitios hayan sido comprometidos.
La diferencia es importante: detectar intentos de explotación no equivale a confirmar intrusiones exitosas.
No obstante, los registros evidencian la rapidez con la que las herramientas automatizadas pueden buscar sistemas vulnerables después de hacerse pública una debilidad crítica.
Fuente: Investigación de Imperva sobre PHP2Shell.
¿Cómo funcionan las dos vulnerabilidades críticas de PHP?
PHP es un lenguaje de programación que permite generar contenidos dinámicos, procesar formularios, consultar bases de datos y gestionar numerosas funciones de las páginas web.
A diferencia de un fallo localizado en un plugin, PHP2Shell afecta a componentes internos del propio intérprete de PHP.
Por este motivo, diferentes aplicaciones pueden estar expuestas aunque sus desarrolladores hayan seguido buenas prácticas de programación.
CVE-2026-109618: corrupción de memoria
La primera vulnerabilidad está relacionada con la gestión de errores cuando PHP se queda sin memoria disponible durante el procesamiento de determinadas solicitudes.
Un atacante puede intentar provocar situaciones anómalas para que PHP interrumpa una operación cuando todavía existen estructuras internas sin inicializar correctamente.
En determinadas circunstancias, la posterior gestión de esa memoria puede abrir la puerta a la ejecución de código no autorizado.
Riesgo principal: que un atacante remoto pueda ejecutar instrucciones en el servidor utilizando los permisos del proceso PHP.
CVE-2026-109619: reutilización de información interna
La segunda vulnerabilidad afecta al estado interno que PHP mantiene durante el procesamiento de solicitudes.
En determinadas situaciones, el programa puede conservar referencias a zonas de memoria que ya han sido liberadas.
Si una solicitud posterior reutiliza ese estado de manera insegura, podría producirse una condición explotable para ejecutar código.
Riesgo principal: permitir que solicitudes web especialmente preparadas aprovechen información interna residual para comprometer el proceso PHP.
¿Por qué tienen una gravedad tan elevada?
Ambas vulnerabilidades pueden permitir ejecución remota de código (RCE) sin que el atacante necesite iniciar sesión.
La ejecución de código no implica necesariamente el control absoluto del servidor: el alcance depende de los privilegios del proceso comprometido y de las medidas de aislamiento implantadas.
Sin embargo, puede convertirse en el punto de partida de un incidente de seguridad importante.
Los avisos oficiales contemplan distintas configuraciones de servidor, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP ha señalado un riesgo especialmente elevado en determinadas configuraciones con Apache mod_php.
¿Qué versiones de PHP están afectadas y cuáles son seguras?
Las correcciones oficiales publicadas el 21 de octubre están disponibles para las ramas PHP 8.2, 8.3, 8.4 y 8.5.
| Rama PHP | Versiones vulnerables | Primera versión corregida |
|---|---|---|
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.1 y anteriores | Ramas sin soporte oficial | Migrar o verificar correcciones del proveedor |
Estas son las versiones corregidas publicadas por el proyecto PHP. Algunas distribuciones Linux y proveedores de soporte extendido incorporan parches de seguridad en paquetes que mantienen otra numeración.
Por ello, la comprobación no debe limitarse a comparar números: también es necesario verificar si el proveedor ha incorporado las correcciones correspondientes.
Atención a los servidores antiguos: PHP 8.1 y las ramas anteriores ya no reciben actualizaciones ordinarias del proyecto. Además, PHP 8.2 finalizará su soporte de seguridad el 31 de diciembre de 2026.
Mantener versiones obsoletas supone un riesgo que va más allá de PHP2Shell, porque futuras vulnerabilidades pueden quedar sin solución oficial.
WordPress y otras aplicaciones web: ¿están afectadas?
La respuesta es sí: las aplicaciones que utilizan una versión vulnerable de PHP pueden estar expuestas.
Entre las tecnologías que dependen de PHP encontramos:
- WordPress, utilizado para páginas corporativas, blogs y tiendas online.
- Drupal y Joomla, empleados en portales y aplicaciones de gestión de contenidos.
- PrestaShop y WooCommerce, utilizados en comercio electrónico.
- Aplicaciones desarrolladas con Symfony o Laravel, que pueden proporcionar servicios web y herramientas empresariales a medida.
No se trata de afirmar que todas estas plataformas tengan un defecto propio o que todas sus instalaciones hayan sido atacadas.
El problema reside en la infraestructura de ejecución que utilizan.
Un WordPress actualizado no garantiza un PHP seguro
Imaginemos una empresa que dispone de una página WordPress con todos sus plugins, temas y componentes actualizados.
Su administrador ha implantado contraseñas robustas, autenticación multifactor y un complemento de seguridad.
Sin embargo, el proveedor de hosting mantiene una versión de PHP anterior a la corrección de PHP2Shell.
En ese escenario, las medidas de seguridad de WordPress continúan siendo útiles, pero no solucionan las vulnerabilidades del intérprete PHP que utiliza el servidor.
Esta diferencia demuestra la importancia de analizar la seguridad del servicio completo, incluyendo el alojamiento, las versiones del software y la configuración del servidor.
¿Qué consecuencias podría tener para una empresa?
Una página web empresarial puede parecer un servicio secundario frente al correo electrónico o los servidores internos.
Sin embargo, suele ser un elemento fundamental para la captación de clientes, la reputación y, en algunos negocios, la operativa diaria.
Si un atacante explotara con éxito una vulnerabilidad como PHP2Shell, las consecuencias potenciales podrían incluir:
1. Manipulación de la página web
Modificación de contenidos, introducción de enlaces maliciosos o alteración de formularios para redirigir información.
2. Exposición de información confidencial
Dependiendo del acceso conseguido, podría existir riesgo para configuraciones, credenciales almacenadas o datos gestionados por las aplicaciones.
3. Interrupción de servicios
Una incidencia podría dejar inaccesible la página corporativa, un portal privado o una aplicación de gestión.
4. Fraude y suplantación de identidad
Una página manipulada podría utilizarse para mostrar instrucciones fraudulentas o engañar a clientes y proveedores.
5. Riesgo para otros sistemas
Cuando el servidor web comparte infraestructura o dispone de conexiones privilegiadas con otros recursos, una intrusión podría facilitar movimientos posteriores dentro del entorno tecnológico.
Estas son consecuencias potenciales, no daños confirmados en todas las organizaciones que utilizan PHP.
¿Por qué es especialmente importante para pymes y despachos profesionales?
Muchas pequeñas y medianas empresas contratan su página web a un proveedor externo y consideran que la seguridad queda completamente cubierta por ese servicio.
Sin embargo, la responsabilidad de mantener la web protegida requiere una coordinación adecuada entre el propietario del servicio, el desarrollador y el proveedor de alojamiento.
Pensemos en situaciones habituales:
- Una asesoría: utiliza formularios de contacto para recibir solicitudes relacionadas con asuntos fiscales, contables o laborales.
- Una administración de fincas: dispone de una web con acceso a un área privada para propietarios y comunidades.
- Un despacho de abogados: publica documentación y dispone de formularios mediante los que potenciales clientes plantean sus consultas.
- Un estudio de arquitectura o ingeniería: recibe solicitudes comerciales y permite acceder a documentación de proyectos mediante herramientas web.
En todos estos casos, una vulnerabilidad grave podría afectar a la confianza de los clientes o interrumpir procesos de negocio.
La pregunta relevante no es únicamente si la web utiliza WordPress, sino quién controla las actualizaciones del servidor, cómo se verifica su aplicación y qué medidas existen si se detecta una incidencia.
Cómo proteger tu web empresarial frente a PHP2Shell
La primera medida consiste en confirmar que la infraestructura utiliza una versión corregida de PHP.
No obstante, una gestión profesional de la seguridad web debe contemplar también otros controles.
1. Comprobar la versión real de PHP
En WordPress se puede consultar la información técnica desde:
Herramientas → Salud del sitio → Información → Servidor → Versión de PHP.
También puede revisarse desde el panel del proveedor de alojamiento web.
Es importante comprobar la versión que utiliza realmente el sitio publicado, porque en algunos servidores conviven diferentes versiones de PHP.
Cuando la infraestructura es administrada por un tercero, conviene solicitar confirmación expresa de que se han aplicado los parches.
2. Instalar las actualizaciones de seguridad
Si la versión instalada está afectada, debe actualizarse a una versión corregida o a un paquete que incorpore los parches oficiales.
Antes de realizar el cambio conviene disponer de una copia de seguridad y comprobar la compatibilidad con la aplicación.
Después hay que verificar que el servicio utiliza efectivamente la versión corregida y que las funcionalidades de la web continúan operativas.
Una actualización anunciada en el panel no equivale necesariamente a que todos los procesos y servicios hayan quedado correctamente actualizados.
3. Revisar las protecciones del firewall web
Un firewall de aplicaciones web (WAF) puede analizar tráfico HTTP y aplicar reglas para reducir determinados intentos de explotación.
Cloudflare, por ejemplo, desplegó protecciones específicas frente a PHP2Shell.
Sin embargo, un WAF no sustituye la actualización del software vulnerable.
Es una capa adicional de protección que puede reducir exposición y proporcionar información sobre actividad sospechosa.
4. Limitar temporalmente la exposición cuando no sea posible actualizar
Cuando una aplicación especialmente sensible no puede recibir el parche de forma inmediata, puede ser necesario limitar el acceso público, restringir los usuarios autorizados o aislar temporalmente el servicio.
Esta es una de las recomendaciones contempladas por el CERT de las instituciones de la Unión Europea.
La medida debe evaluarse considerando la importancia empresarial del servicio y la disponibilidad de alternativas seguras.
5. Revisar los registros de seguridad
Tras la divulgación de una vulnerabilidad crítica, resulta recomendable revisar la actividad registrada por el servidor y sus sistemas de protección.
Entre los indicios que pueden justificar una investigación se encuentran las solicitudes HTTP anómalas, errores inesperados, procesos PHP que se cierran repetidamente, archivos no reconocidos o conexiones de salida inusuales.
Estas señales no demuestran por sí mismas una intrusión. Deben analizarse en contexto para distinguir actividad legítima, intentos fallidos y posibles compromisos.
6. Mantener copias de seguridad y comprobar su recuperación
Las copias de seguridad permiten recuperar la disponibilidad y la información cuando ocurre una incidencia.
Deben conservarse de manera protegida, incluir los componentes necesarios para restaurar el servicio y verificarse mediante pruebas de recuperación.
No obstante, una copia de seguridad no corrige una vulnerabilidad: restaurar una aplicación sin actualizar puede volver a exponerla al mismo problema.
Actualización del 23 de octubre: PHP advierte de una tercera vulnerabilidad
Tras la publicación de las correcciones para PHP2Shell, el proyecto PHP comunicó el 23 de octubre de 2026 otro problema de seguridad, identificado como CVE-2026-115560.
A diferencia de las dos vulnerabilidades principales, esta requiere una combinación poco habitual de configuración y código de la aplicación relacionada con el manejo de sesiones.
El equipo de PHP considera improbable su explotación en configuraciones convencionales y prevé incluir la corrección en el siguiente ciclo ordinario de actualizaciones.
Mientras tanto, recomienda desactivar temporalmente la funcionalidad session.upload_progress.enabled cuando corresponda, especialmente en entornos donde se utilice la configuración afectada. Este cambio debe realizarlo un administrador desde la configuración del servidor y requiere reiniciar los procesos PHP correspondientes.
Importante: esta recomendación específica no sustituye los parches del 21 de octubre para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619.
El nuevo aviso refuerza la necesidad de mantener un seguimiento continuo de las comunicaciones oficiales, incluso después de instalar una actualización extraordinaria.
Cómo ayuda GHM Soluciones Informáticas a mejorar la seguridad de las empresas
La seguridad de una página web no depende exclusivamente de instalar un certificado HTTPS o mantener actualizado su gestor de contenidos.
También intervienen las versiones del servidor, la configuración de servicios, los permisos, las protecciones perimetrales, las copias de seguridad y la capacidad de detectar actividad sospechosa.
En GHM Soluciones Informáticas ayudamos a las empresas a identificar riesgos y mejorar la protección de su infraestructura tecnológica.
Mediante nuestros servicios de auditoría de ciberseguridad podemos evaluar la exposición de sistemas y servicios, revisar las medidas de seguridad implantadas y definir prioridades de corrección.
Cuando los servicios web forman parte de una infraestructura gestionada o supervisada, su seguridad debe coordinarse con las actualizaciones, la protección de accesos y la segmentación de red.
Además, mediante nuestras soluciones de ciberseguridad empresarial, integramos tecnologías como SonicWall, protección Endpoint Kaspersky y monitorización SIEM Wazuh, según las características y necesidades de cada entorno.
El SIEM Wazuh permite centralizar y correlacionar los registros de las fuentes integradas, mientras que nuestro servicio SOC analiza los eventos relevantes e investiga posibles incidencias.
Esta supervisión ayuda a disponer de mayor visibilidad sobre la infraestructura, aunque no reemplaza las actualizaciones de seguridad ni garantiza que todos los ataques puedan detectarse.
Nuestro objetivo es que las empresas dispongan de una infraestructura mantenida, protegida y supervisada, reduciendo la exposición a riesgos evitables.
Conclusión: actualizar PHP es una cuestión de seguridad empresarial
Las vulnerabilidades PHP2Shell muestran cómo un fallo en una tecnología ampliamente utilizada puede afectar a aplicaciones muy diferentes, desde una sencilla página corporativa hasta servicios empresariales complejos.
Los parches para las dos vulnerabilidades críticas están disponibles desde el 21 de octubre de 2026.
Por tanto, la prioridad actual no es esperar una solución, sino confirmar que las actualizaciones se han instalado y que los servicios expuestos utilizan una versión corregida.
También resulta importante comprobar si existen versiones obsoletas, supervisar los registros de seguridad y mantener procedimientos de respuesta ante posibles incidencias.
Una empresa puede tener su página aparentemente funcionando con normalidad y, aun así, conservar componentes vulnerables en el servidor.
¿Sabes qué versión de PHP utiliza tu web y cuándo se revisó por última vez la seguridad de sus servicios?
En GHM Soluciones Informáticas podemos ayudarte a evaluar la exposición de tu infraestructura y establecer medidas de protección adaptadas a tu empresa.
Preguntas frecuentes sobre las vulnerabilidades críticas de PHP
¿Qué es PHP2Shell?
PHP2Shell es el nombre utilizado para identificar dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecutar código de forma remota en servidores que utilizan versiones afectadas del lenguaje.
¿Cuáles son las vulnerabilidades críticas de PHP publicadas en octubre de 2026?
Las dos vulnerabilidades principales son CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS 4.0 de 9,2 y fueron corregidas mediante actualizaciones de PHP publicadas el 21 de octubre de 2026.
¿Qué versiones de PHP corrigen PHP2Shell?
Las primeras versiones oficiales que corrigen ambos fallos son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. También pueden existir paquetes de distribuidores que incorporen estas correcciones mediante parches adaptados a sus versiones.
¿Las páginas web de WordPress están afectadas?
Las páginas de WordPress que utilizan una versión vulnerable de PHP pueden estar expuestas. No significa que WordPress tenga necesariamente una vulnerabilidad propia ni que todas sus instalaciones hayan sido comprometidas.
¿Es suficiente actualizar WordPress y sus plugins?
No. Las actualizaciones de WordPress y sus plugins son necesarias, pero estas dos vulnerabilidades afectan al intérprete PHP del servidor. Es imprescindible verificar que PHP también está corregido.
¿Cómo puedo saber qué versión de PHP utiliza mi web?
En WordPress puedes acceder a Herramientas, Salud del sitio, Información y Servidor. También puedes consultarlo en el panel de hosting o solicitarlo a tu proveedor de alojamiento.
¿Pueden aprovechar PHP2Shell sin conocer una contraseña?
Sí. Las vulnerabilidades permiten escenarios de ejecución remota de código sin autenticación previa. La viabilidad y el alcance concreto dependen de la versión instalada y de las condiciones del servidor.
¿Un firewall web protege completamente frente a PHP2Shell?
No. Un WAF puede reducir intentos de explotación conocidos, pero no garantiza protección frente a todos los métodos de ataque. La solución principal consiste en instalar las actualizaciones correspondientes.
¿Debo desconectar mi página web si todavía no puedo actualizar PHP?
No necesariamente en todos los casos. Sin embargo, para servicios expuestos con un riesgo importante, puede ser recomendable restringir o suspender temporalmente el acceso público hasta aplicar una corrección verificada.
¿Qué ocurre si mi servidor utiliza PHP 7.4, 8.0 o 8.1?
Estas versiones ya no reciben soporte ordinario del proyecto PHP. Lo recomendable es migrar a una rama compatible y mantenida. Si se utiliza soporte extendido, debe comprobarse expresamente que el proveedor ha incorporado los parches de PHP2Shell.
¿Se han detectado ataques reales aprovechando estas vulnerabilidades?
Se han documentado intentos de explotación y campañas de exploración automatizada. Cloudflare e Imperva han publicado observaciones sobre esta actividad. Estos registros no demuestran por sí solos que todas las webs atacadas hayan sido comprometidas.
¿Qué es la vulnerabilidad CVE-2026-115560?
Es una tercera vulnerabilidad de PHP comunicada el 23 de octubre de 2026. Requiere una configuración poco habitual relacionada con sesiones. PHP ha recomendado una mitigación específica hasta publicar la corrección definitiva en su ciclo ordinario de actualizaciones.
¿Cómo puede proteger una empresa su infraestructura web a largo plazo?
Mediante actualizaciones periódicas, inventario de versiones, configuración segura del servidor, control de accesos, copias de seguridad verificadas, protección de aplicaciones web y revisión de eventos de seguridad. Una auditoría permite identificar las medidas prioritarias según la exposición de cada empresa.
