El 21 de octubre de 2026, PHP publicó versiones de seguridad para corregir CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. El anuncio de lanzamiento de PHP 8.4.27 confirma el riesgo y recomienda actualizar de inmediato.

Esta nota reúne las comprobaciones que conviene priorizar ante el caso conocido como PHP2Shell. La exposición concreta debe evaluarse según la versión, la configuración y la forma en que PHP atiende las solicitudes.

Qué vulnerabilidades se corrigieron

Los avisos del proyecto describen dos problemas de gestión de memoria:

  • CVE-2026-109618 — corrupción durante errores por falta de memoria. Una interrupción por agotamiento de memoria puede dejar datos internos parcialmente inicializados. La limpieza de la solicitud puede procesarlos como si fueran válidos. El aviso de RCE via OOM corruption explica este mecanismo.
  • CVE-2026-109619 — reutilización de estado global obsoleto. Un proceso trabajador puede conservar referencias a memoria de una solicitud ya liberada. Una solicitud posterior puede acceder a ese estado antes de su reinicialización. El aviso de RCE via stale global state documenta ese uso de memoria liberada.

Conocer estas condiciones permite orientar la revisión sin asumir que todos los entornos tienen una vía de explotación idéntica.

Qué servidores deben revisarse

El comunicado oficial de PHP incluye las instalaciones que procesan solicitudes web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

PHP sitúa el mayor riesgo en Apache con mod_php: se ha demostrado una vía activada por una solicitud no autenticada antes de ejecutar el código de la aplicación. Para otros modos de ejecución, las condiciones pueden depender de la aplicación y de la configuración. El aviso técnico sobre corrupción OOM distingue esas condiciones y el grado de validación de cada caso.

Por eso, usar PHP-FPM debe motivar una revisión de su configuración y versión; la ausencia de una demostración completa para una vía particular no acredita que el servicio esté protegido.

Versiones de seguridad publicadas

Las versiones que incorporan las correcciones del 21 de octubre son las siguientes, según las secciones de versiones corregidas de los avisos de seguridad de PHP:

Rama Versión corregida publicada
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

Estas son las versiones publicadas para este aviso. Si el proveedor ofrece una revisión posterior, comprueba su documentación y el paquete aplicable a tu sistema.

El comunicado también indica que PHP 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Algunos proveedores de distribuciones y soporte extendido pueden ofrecer correcciones retroportadas. Para esos paquetes, la evidencia debe ser el aviso del proveedor y la revisión instalada; una cadena de versión por sí sola puede resultar insuficiente. Consulta el aviso oficial y el estado de soporte de PHP.

Laravel también debe entrar en el inventario

Una aplicación Laravel se ejecuta sobre PHP. En consecuencia, mantener Laravel actualizado no sustituye la actualización del intérprete. El mismo criterio de inventario comprende aplicaciones basadas en Symfony, WordPress, Drupal y desarrollos propios que utilicen ese entorno de ejecución.

Para Laravel, proponemos comprobar tres capas:

  1. El PHP que atiende la web. Contrasta la versión y el ejecutable de PHP-FPM o del servidor utilizado. El resultado de php -v corresponde a la consola y puede diferir del servicio web.
  2. Las imágenes y los procesos desplegados. Si usas contenedores, verifica la imagen reconstruida y los contenedores realmente activos. Incluye entornos de producción, desarrollo y pruebas.
  3. Los procesos persistentes. Revisa los servicios que mantienen procesos PHP en ejecución y planifica su reinicio con el procedimiento del entorno.

La documentación de despliegue de Laravel recuerda que los servicios de larga duración, como los trabajadores de colas y Octane, requieren recarga o reinicio durante los despliegues. En este caso, comprueba además que los procesos reiniciados utilizan el runtime actualizado. Antes de cambiar de rama de PHP, revisa la compatibilidad de la aplicación y sus dependencias.

Los servidores WordPress también deben revisarse

WordPress utiliza PHP para ejecutar el sitio, como recoge su página de requisitos oficiales. Por tanto, los servidores que alojan WordPress también deben revisar su versión de PHP y si cuentan con las correcciones correspondientes a estas vulnerabilidades.

Actualizar WordPress, sus plugins o sus temas no sustituye la actualización de PHP en el servidor. En un alojamiento administrado, solicita al proveedor la confirmación del paquete corregido que utiliza el sitio. Antes de cambiar de rama de PHP, comprueba la compatibilidad de WordPress y sus extensiones.

Contener mientras se prepara la actualización

PHP señala que actualizar es la única mitigación completa para estos fallos. Los controles temporales pueden reducir vías concretas de explotación, pero su alcance depende del entorno y debe contrastarse con ambos avisos técnicos. El anuncio oficial del lanzamiento insiste en la actualización como acción necesaria.

Si necesitas ayuda para identificar qué PHP están ejecutando tus aplicaciones y ordenar el cambio, cuéntanos qué sistemas tienes.