PHP2Shell en 8 claves

PHP2Shell permitiría realizar ejecución de código en remoto en millones de servidores y comprometer sistemas, redes y datos confidenciales de organizaciones de todo el mundo

El 20 de octubre se hizo público que PHP, el lenguaje de programación empleado en el 70% de las webs mundiales, tenía dos vulnerabilidades que permitirían la explotación de código malicioso en remoto. Estas vulnerabilidades críticas se conocen de forma conjunta como PHP2Shell.

La fundación a cargo de PHP informó de que ya estaba trabajando en una actualización de seguridad para parchear sendas vulnerabilidades y que se publicaría al día siguiente, el 21 de octubre.

Durante el tiempo que se tardó en publicar la actualización de seguridad, múltiples empresas y, sobre todo, administraciones públicas optaron por pasar a offline sus sistemas basados en PHP, siguiendo las recomendaciones de los organismos públicos a cargo de la ciberseguridad, como el estadounidense (CISA) o el español (INCIBE).

PHP2Shell no solo es una de las noticias del año en el ámbito de la ciberseguridad, sino que pone el foco en cuestiones críticas para la seguridad de las organizaciones y su continuidad de negocio como:

• El rol que juega la IA en la detección y explotación de vulnerabilidades y la velocidad con la que se hace.
• La seguridad de la cadena de suministro de software.
• La gestión de vulnerabilidades.

A continuación, vamos a repasar las claves de PHP2Shell y a poner en valor el rol que juegan las auditorías de seguridad continuas y la gestión de vulnerabilidades en la protección de una organización.

1. ¿Qué es PHP2Shell?

Como ya apuntamos antes, el concepto de PHP2Shell engloba, en realidad, a dos vulnerabilidades distintas:

• CVE-2026-109618. Es una vulnerabilidad que permite la ejecución remota de código por corrupción durante un agotamiento de memoria o OOM (out-of-memory).
• CVE-2026-109619. Esta vulnerabilidad también permite la ejecución remota de código, en este caso, a través de un estado global obsoleto que apunta a la memoria de la solicitud.

Ambas se tratan de vulnerabilidades de seguridad de memoria presentes en el motor central de PHP y que facilitan la divulgación de información sensible almacenada en la memoria de los procesos PHP y la ejecución de código sin autenticación, abriendo las puertas a la instalación de malware en los servidores atacados.

Todo ello con independencia de la aplicación que se ejecute sobre PHP. Lo que conlleva a que puedan verse afectadas por PHP2Shell todas las webs desarrolladas con este lenguaje.

De ahí que no deba sorprendernos que las dos debilidades hayan sido catalogadas como vulnerabilidades críticas con una puntuación en CVSS de 9.2 sobre 10.

Si a ello le sumamos que PHP es el lenguaje de programación empleado en WordPress, Drupal o Joomla, los principales gestores de contenido del mundo, así como en miles de aplicaciones, resulta lógico que se hayan encendido muchas luces de alarma estos días.

2. ¿A qué sistemas afecta PHP2Shell?

Todas las versiones de este lenguaje de programación desde la 5.4.0 hasta la 8.5.11 presentan alguna de las dos vulnerabilidades. Si bien, como señalaremos después, ya existen correcciones en algunas ramas: 8.2, 8.3, 8.4 y 8.5. Mientras que las versiones anteriores están fuera de soporte oficial y no tienen por qué tener parches.

Desde la propia fundación PHP se ha señalado que están en riesgo todas las instalaciones de PHP que procesan solicitudes web, incluidas las que emplean:

• PHP-FPM.
• Apache con mod_php.
• php-cgi.
• FrankenPHP.
• LiteSpeed.

Si bien, el mayor riesgo está en los servidores que funcionan con Apache mod_php, ya que se ha constado la existencia de un exploit que permite desencadenar un ataque antes de que se ejecute ningún código de la aplicación.

3. ¿Qué pueden hacer los actores maliciosos que exploten estas vulnerabilidades?

Al explotar PHP2Shell, los actores maliciosos pueden, según ha alertado la NSA, la agencia estadounidense de seguridad, tomar el control de los servidores que ejecutan versiones vulnerables de PHP sin necesidad de autenticación o acceso previo.

Una vez dentro de los servidores, los atacantes podrían:

• Ejecutar malware.
• Robar datos confidenciales.
• Modificar las webs alojadas en los servidores.
• Provocar la interrupción de los servicios.
• Adentrarse en una red.
• Comprometer de forma total un sistema.

Si tenemos en cuenta que muchas organizaciones no cuentan con un servidor propio, sino que emplean servidores compartidos con otras empresas, un ataque contra un servidor puede conllevar graves consecuencias para múltiples organizaciones a la vez.

4. ¿Ya es posible explotar PHP2Shell?

Sí. Antes de que se publicaran los parches ya circulaban pruebas de concepto para explotar PHP2Shell y atacar a los servidores vulnerables.

De hecho, desde el INCIBE apuntan que «se han comunicado ataques contra servidores PHP antes de la publicación de las actualizaciones». Y algunas empresas como una multinacional líder en el terreno de las redes de distribución de contenido (CDN) ya han informado de que han detectado múltiples ataques.

De ahí que en el lapso que pasó desde la publicación de las vulnerabilidades hasta el lanzamiento de los parches de seguridad, muchas organizaciones optasen por dejar fuera de servicio sus webs y prevenir las consecuencias que detallamos antes.

5. ¿Cómo puede una organización saber si ha sido víctima de un ataque explotando PHP2Shell?

En primer lugar, autoridades públicas como el FBI, recomiendan a las organizaciones que realicen un inventario para saber en qué activos se ejecuta PHP y qué versión se emplea, priorizando el control de los sistemas expuestos a internet.

En esta labor es imprescindible tener en cuenta, también, el uso de PHP en software de proveedores tecnológicos.

En segundo lugar, se deben monitorizar los servidores web que ejecuten PHP para detectar actividad sospechosa: ejecución inesperada de comandos o descarga de archivos…

¿Qué pasa si se detecta actividad potencialmente maliciosa? Se debe activar el plan de respuesta a incidentes y proceder a aislar de forma inmediata los sistemas afectados.

6. ¿Cómo se puede subsanar PHP2Shell?

Instalando una de las cuatro actualizaciones de seguridad publicadas por la fundación PHP: 8.5.12, 8.4.27, 8.3.36 o 8.2.35.

Además, aunque las versiones anteriores a la rama 8.2 de PHP ya están obsoletas y no se les preste soporte, ante la criticidad de PHP2Shell, el equipo de seguridad de la fundación ha hecho públicas adaptaciones mínimas del código fuente para las versiones PHP 7.4, PHP 8.0 y PHP 8.1.

¿Qué pasa con los sistemas que no pueden actualizarse de forma inmediata? Aunque el proyecto PHP ha listado varias medidas que reducen la exposición a los ataques, estas no solventan íntegramente PHP2Shell.

Por ejemplo, se recomienda establecer memory_limit=-1 de tal forma que las aplicaciones no puedan anularlo, por ejemplo, mediante php_admin_value en el grupo de FPM o en la configuración de Apache. De esta forma se elimina el fallo relacionado con la memoria controlable de PHP, pero no se solventa la vulnerabilidad.

Por eso, los principales organismos a cargo de la ciberseguridad como el INCIBE, la CISA o la NSA recuerdan que la actualización es la única forma de solucionar completamente PHP2Shell. Y que mientras no se pueda actualizar la versión, es recomendable aislar de internet a los sistemas afectados para prevenir incidentes de seguridad.

7. ¿Cómo se descubrieron estas vulnerabilidades críticas?

Más allá de que PHP2Shell puede impactar en miles y miles de organizaciones a nivel mundial, su revelación ha generado una gran expectación por la forma en que se descubrieron las vulnerabilidades. O, más bien, cómo se probó que eran explotables y no solo se trataba de debilidades de índole teórica.

Lo cierto es que estas debilidades llevaban presentes en el núcleo de PHP desde hace años y ya en 2020 se descubrió una vulnerabilidad de agotamiento de memoria en PHP y en 2024 se volvió a identificar. Sin embargo, no se pudo demostrar que fuese explotable, lo que implicó que no se parcheara.

Sin embargo, gracias al uso de IA de frontera o vanguardia se probó que las vulnerabilidades que englobamos bajo el paraguas de PHP2Shell sí son explotables y permiten la ejecución de código remoto.

Los equipos que descubrieron la posibilidad de explotar las vulnerabilidades informaron a PHP en agosto, el proyecto comenzó a desarrollar los parches de seguridad y se pactó la revelación tanto de las vulnerabilidades como de las actualizaciones de seguridad para el 22 de octubre con el objetivo de evitar que miles de sistemas quedasen expuestos a los ataques.

No obstante, se filtró la información el 20 de octubre y los acontecimientos se precipitaron.

¿Qué podemos destacar de lo ocurrido en torno al descubrimiento de PHP2Shell?

1. La colaboración entre las compañías de ciberseguridad y los desarrolladores de software es esencial para proteger al tejido productivo, el sector público y el conjunto de la sociedad frente a los ciberataques.
2. La IA ya está permitiendo detectar y explotar vulnerabilidades presentes en el software desde hace años que han pasado desapercibidas o que no eran posibles de explotar.
3. El tiempo que se necesita para identificar una vulnerabilidad y desarrollar una prueba de concepto para explotarla es cada vez más corto. A las pocas horas de que se hiciera público PHP2Shell ya se detectaron intentos de ataque y circulaban pruebas de concepto para explotarlas. Por eso, los procedimientos para subsanar vulnerabilidades también tienen que acelerarse.
4. La gestión de vulnerabilidades es aún más crítica que antes y debe ser eficiente y ágil. Las empresas necesitan monitorizar toda su infraestructura tecnológica y gestionar las vulnerabilidades presentes en ella con la máxima celeridad.

8. ¿Por qué son esenciales las auditorías de seguridad y la gestión de vulnerabilidades?

PHP2Shell también evidencia la importancia que juegan los servicios de ciberseguridad a la hora de identificar debilidades y solventarlas antes de que sean explotadas y generen incidentes de seguridad. ¿De qué servicios hablamos?

1. Auditorías de seguridad continuas en las aplicaciones y servidores web. Esta clase de evaluación conjuga el uso de herramientas automatizadas y el análisis de expertos en ciberseguridad, para maximizar la detección de amenazas que pueden poner en jaque la seguridad de aplicaciones web y su infraestructura.

La realización de pruebas específicas siguiendo las principales metodologías del sector, como las de OWASP, permiten identificar debilidades relacionadas con:

• La infraestructura de servidores.
• Una programación inadecuada.
• La lógica de negocio específica de una compañía.
• La ausencia de buenas prácticas de seguridad.

El objetivo es identificar problemas de configuración, autenticación o lógica de una aplicación que puedan abrir la puerta a accesos no autorizados a información confidencial, suplantaciones de identidad de usuarios, el robo de datos o tomar el control del servidor.

2. Gestión de vulnerabilidades. Esta clase de servicio permite a las organizaciones contar con un inventario de sus activos clasificado y en el que figuren los responsables de cada uno de ellos. A partir de esta tarea se procede a monitorizar de forma continua todos los activos para detectar debilidades, priorizar su remediación y evitar riesgos como el uso de software que ha llegado al fin de su ciclo de vida o que está desactualizado.

Mediante una gestión de vulnerabilidades eficaz se logran reducir los tiempos de detección y mitigación de debilidades, garantizando su resolución antes de que sean explotadas con éxito.

En definitiva, las empresas y las administraciones públicas deben asegurarse de que sus webs y aplicaciones no están alojadas en servidores que aún no hayan sido parcheados para evitar la explotación de PHP2Shell.

De lo contrario, se exponen a sufrir incidentes de seguridad que pueden amenazar la información de sus sistemas o su propia operatividad.