PHP2Shell, ejecución remota de código en PHP

¿Qué ha pasado?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación, y el equipo de PHP recomienda encarecidamente actualizar de inmediato. Las vulnerabilidades se conocen como PHP2Shell.

El caso es especialmente urgente porque los detalles se filtraron en internet el 20 de octubre, antes de la divulgación coordinada y antes de que existiera el parche. Investigadores de watchTowr han confirmado que las vulnerabilidades son reales y han reproducido CVE-2026-109618.

• CVE-2026-109618 (RCE por corrupción de memoria tras falta de memoria): la gestión de errores por falta de memoria puede interrumpir PHP mientras los datos internos de la petición solo están parcialmente inicializados, y la limpieza posterior puede tratarlos como válidos.
• CVE-2026-109619 (RCE por estado global residual): cierto estado interno de una petición puede sobrevivir después de liberar su memoria, y una petición posterior atendida por el mismo proceso puede reutilizarlo antes de que se reinicialice.

En España, INCIBE-CERT ha publicado un aviso sobre estas vulnerabilidades con importancia 5 sobre 5 (crítica). Según INCIBE, el equipo de PHP indica que todas las versiones podrían estar afectadas, aunque las pruebas solo se han hecho en las versiones 5 a 8. En el momento de publicar su aviso, INCIBE no tenía constancia de explotación activa de ninguno de los dos CVE.

¿A quién afecta?

A prácticamente cualquier organización con una web o aplicación en PHP (WordPress, PrestaShop, Magento, intranets, ERPs web, etc.). Según PHP, están en riesgo todas las instalaciones que sirven peticiones web, incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto es con mod_php, donde se ha demostrado un exploit en el que una petición sin autenticación puede desencadenar el ataque antes de que se ejecute ningún código de la aplicación.

A escala global, Palo Alto Networks ha identificado más de 22,6 millones de instancias expuestas potencialmente vulnerables.

¿Qué hay que hacer?

1. Inventariar. Localizar todos los sistemas con PHP, empezando por los expuestos a internet, sin limitarse a las versiones antiguas, ya que todas pueden estar afectadas.
2. Actualizar ya a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 según la rama. Las distribuciones Linux y los proveedores LTS recibieron los parches por adelantado, así que conviene consultar si ya hay paquetes actualizados. Para comprobarlo, se puede revisar el changelog del paquete (por ejemplo apt changelog php8.3-cli o rpm -q --changelog php) y buscar el número del CVE.
3. Si usas el repositorio Remi: PHP recomienda pasar a los paquetes de la distribución o compilar desde código fuente, ya que este repositorio no tendrá actualizaciones hoy.
4. Hosting compartido: confirmar con el proveedor que ha aplicado el parche en todas las versiones de PHP que ofrece.
5. Versiones sin soporte (8.1 o anterior): ya no reciben actualizaciones del proyecto PHP; algunas distribuciones y proveedores LTS ofrecen correcciones adaptadas. Dada la gravedad, el equipo de PHP ha publicado parches mínimos para PHP 7.4, 8.0 y 8.1 para quien compile desde código fuente. Aun así, lo recomendable es migrar a una versión con soporte.
6. Software de terceros: vigilar las actualizaciones de appliances y productos que incluyan PHP. El NCSC-NL ha publicado un inventario de productos con dependencia de PHP potencialmente afectados.
7. Si no se puede actualizar de inmediato, aplicar las mitigaciones temporales oficiales. Solo la actualización es una solución completa; estas medidas reducen la exposición a vías de ataque concretas, pero no hacen la instalación segura.
   
   • CVE-2026-109618: establecer memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo (por ejemplo con php_admin_value), fijar un post_max_size bajo (8M sin subida de ficheros, 32M si son necesarias) y usar un límite de contenedor o cgroup como barrera de disponibilidad. ⚠️ Quitar el límite de memoria sin un límite de cgroup o contenedor puede dejar el servidor sin RAM.
   • CVE-2026-109619: establecer session.upload_progress.enabled=0 y reiniciar todos los workers, configurándolo en php.ini, el pool de FPM o el servidor (no mediante ini_set() ni .user.ini); en PHP 8.5, además, fatal_error_backtraces=0.
8. Último recurso: si no se puede parchear ni mitigar a tiempo, valorar desconectar el sistema hasta poder protegerlo.
9. Revisar posibles compromisos. En sistemas que han estado expuestos sin parche, buscar indicios de intrusión y puertas traseras.

¿Necesitas ayuda?

Si no tienes claro qué versión de PHP usan tus webs o servidores, o quieres que revisemos tu exposición, contacta con el equipo de Infordisa y te ayudamos a evaluar y aplicar las actualizaciones.

Fuentes:
Aviso de seguridad oficial de PHP · INCIBE-CERT · NCSC · Avisos técnicos en GitHub