El 21 de octubre de 2026 la CISA instó a parchear de inmediato CVE-2026-109618 y CVE-2026-109619, los fallos «php2shell» que permiten la ejecución remota de código sin autenticar en PHP. Según Amazon, los primeros intentos de explotación llegaron el sábado 17 de octubre, cuatro días antes de los parches. Así que parchear este RCE de PHP son dos tareas: actualizar todos los servidores y comprobar después si algo se coló antes.

Los fallos están en PHP, no en las aplicaciones que alojas sobre él. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y ambos CVE puntúan 9,2 en CVSSv4. El código inyectado se ejecuta con los privilegios del worker web.

CERT-EU da por expuesta toda configuración que sirva web: PHP-FPM, mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera mod_php la de mayor riesgo. CVE-2026-109618 es una corrupción de memoria durante la gestión de la falta de memoria; CVE-2026-109619 es un use-after-free ligado al estado que se conserva entre peticiones.

La cronología importa más que la lista de versiones. El equipo de PHP adelantó la publicación tras filtrarse los detalles, parcheó el 21 de octubre y solo un día antes había avisado a los administradores de que se prepararan. Los honeypots de Amazon registraron intentos desde el 17 de octubre y más entre las 02:00 y las 08:00 UTC del 21 de octubre; el vicepresidente de la BSI esperaba una explotación a gran escala a las pocas horas de las actualizaciones.

Una precaución sobre las pruebas: Amazon habla de intentos, no de compromisos confirmados, y el equipo de PHP afirmó que ninguna de las pruebas de concepto publicadas antes del parche funcionaba. La propia CISA dijo en el momento de la publicación que no había observado explotación, y watchTowr señaló que a 22 de octubre ninguno de los dos CVE figuraba en el catálogo KEV de la CISA, así que comprueba tú mismo el estado actual del catálogo. Trata la comprobación de intrusión que sigue como una precaución, no como la asunción de una brecha.

Quién se encarga del parche en cada uno de nuestros productos

La respuesta depende de lo que hayas contratado, y un parque mixto normalmente tiene un poco de todo. Así trazamos la línea:

  • VPS, VDS y MEM (no gestionados): nosotros operamos los hosts KVM y la red; actualizar el runtime de PHP dentro de la instancia te corresponde a ti.
  • Servidores bare metal no gestionados: un servidor de un único cliente es tuyo de principio a fin, incluida la pila web que lleva.
  • Servidores bare metal con la opción gestionada: nos encargamos del sistema operativo. Debes confirmar con nosotros por escrito si PHP, como runtime de tu aplicación, queda cubierto; no lo des por supuesto.
  • Instancias MNG: son gestionadas, pero no des por hecho que la gestión cubra el PHP ni el resto del software de tu instancia; confírmalo con nosotros. Pregúntanos antes de contar una instancia MNG como resuelta.

El error caro en la respuesta a una vulnerabilidad de PHP es una instancia que todos creen que está parcheando otro. Fija quién es responsable de cada servidor antes de empezar a actualizar.

Crea un inventario de servidores PHP antes de parchear

La CISA indica que se inventaríen todos los sistemas que ejecutan PHP, porque a menudo va integrado y su presencia no es evidente. Un inventario de servidores PHP para este evento necesita solo unos pocos campos por host:

  • Versión de PHP y SAPI (php -v y cómo invoca el servidor web a PHP)
  • Si el host está expuesto a internet; esos van primero, como aconseja la CISA
  • Quién lo parchea: tú, nosotros o un proveedor de la aplicación
  • Si PHP viene incluido dentro de un producto que no instalaste como PHP

Para este último caso, CERT-EU remite a la lista del NCSC-NL NCSC-NL/php2shell, que recoge el software que integra PHP. Un dispositivo de un proveedor puede llevar un runtime vulnerable que ningún gestor de paquetes de tu lado mostrará jamás.

Versiones sin corrección upstream

PHP 8.1 y anteriores no reciben actualizaciones rutinarias upstream, aunque el equipo de PHP facilitó backports de código fuente limitados para 7.4, 8.0 y 8.1. CERT-EU dice que algunas distribuciones y proveedores de LTS incorporan backports de las correcciones. watchTowr afirma que PHP 7.3 y anteriores, incluido PHP 5, no tienen corrección alguna, y la BSI dice que todas las versiones conocidas, hasta al menos PHP 5, son vulnerables.

Si un host ejecuta una de ellas, tienes tres opciones: pasar a una rama con corrección, aplicar un backport de un proveedor o aislar el host. ExecutiveGov informa de que la NSA y la CISA dicen que los sistemas que no se pueden actualizar deben desconectarse; la redacción de CERT-EU es más suave: plantea considerar aislarlos. Revisa también tus repositorios: el repositorio de voluntarios rpms.remirepo.net no tendrá actualizaciones el mismo día.

Mitigación temporal de php2shell mientras esperas

CERT-EU es explícito: los ajustes temporales reducen la exposición y «no hacen segura una instalación». Para CVE-2026-109618 sugiere un memory_limit=-1 que no se pueda sobrescribir, un post_max_size bajo y límites de memoria de cgroup, y advierte contra RLIMIT_AS y RLIMIT_DATA. Para CVE-2026-109619 se desactiva el seguimiento del progreso de las subidas:

session.upload_progress.enabled=0
; PHP 8.5 only
fatal_error_backtraces=0

Establece la primera línea en php.ini, en el pool de FPM o en la configuración del servidor, y reinicia todos los workers, como indica CERT-EU. El grupo de reglas gestionadas de PHP de AWS WAF, en su versión 2.3, añade una regla PHP2Shell_BODY para CVE-2026-109619 si ya filtras el tráfico de ese modo. Es una medida provisional delante de un servidor sin parchear, no un sustituto.

Un SLA de parcheo de 30 días da por hecho que el atacante te espera. En este caso, Amazon registró intentos de explotación cuatro días antes del parche.

Comprueba si hubo intrusión además de actualizar

Parchear cierra la puerta, pero no te dice quién estaba ya dentro. AWS aconseja investigar desde el 17 de octubre como mínimo. Una lista de comprobación de la comunidad cita una retrospectiva anterior, hasta junio de 2026, pero no se explica el motivo de esa fecha, así que decide tu ventana según cuánto historial de logs puedas permitirte leer.

La pista de AWS para el threat hunting es buscar en los logs web peticiones POST que contengan PHP_SESSION_UPLOAD_PROGRESS en subidas de formularios. Más allá de eso, busca archivos en el webroot que tus despliegues no hayan creado, procesos hijo lanzados por el worker web y conexiones salientes del usuario web. Como el código se ejecuta con ese worker, determina qué puede leer su cuenta: archivos de configuración, credenciales de bases de datos, almacenamiento montado.

En nuestras instancias cloud, haz un snapshot antes de cambiar nada, para conservar el disco previo al parche y poder examinarlo. Después, rota las credenciales que el worker web pudiera leer en cualquier host donde la búsqueda encuentre algo o donde falten los logs desde el 17 de octubre.

El orden de trabajo

  1. Inventaría PHP, incluidas las copias integradas, y anota quién parchea cada host.
  2. Actualiza primero los hosts expuestos a internet, a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o a un backport de un proveedor.
  3. Aplica los ajustes temporales donde la actualización tenga que esperar y reinicia todos los workers.
  4. Aísla los hosts que estén en ramas sin corrección.
  5. Busca en los logs desde el 17 de octubre y amplía la ventana si puedes.

El consejo de AWS es medir en horas los plazos de parcheo crítico, porque los SLA de 7 o 30 días suponen un retraso que ya no existe. Ten claro hoy cuáles de tus servidores gestionas tú y cuáles nos has pedido que gestionemos nosotros, para que esas horas se dediquen a parchear y no a averiguarlo.

Fuentes