php2shell: dos RCE críticas en PHP y el repo del NCSC para frenarlas

El 21 de octubre de 2026, PHP publicó cuatro releases de emergencia: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades críticas que permiten ejecución remota de código sin autenticación, trackeadas por CERT-EU como CVE-2026-109618 y CVE-2026-109619. El advisory oficial de PHP no se anda con rodeos: todas las instalaciones que sirven peticiones web están en riesgo.

Mientras CISA, la NSA y el NCSC británico publicaban alertas casi en tiempo real, el Centro Nacional de Ciberseguridad de Países Bajos hizo la contribución más práctica: php2shell, un repositorio en GitHub con información operativa para detectar y mitigar las dos vulnerabilidades.

Dos RCE que atacan el estado interno del request

Ambas vulnerabilidades comparten raíz: el estado interno de una petición puede acabar en manos de la petición siguiente.

CVE-2026-109618 — RCE vía corrupción out-of-memory. PHP aplica el memory_limit del usuario con un longjmp() que interrumpe la ejecución en el momento en que se agota la memoria. El problema es que ese corte puede pillar a PHP con los datos internos del request solo parcialmente inicializados. Durante la limpieza posterior, el runtime trata esos datos inválidos como válidos. El resultado es corrupción de memoria explotable de forma remota.

CVE-2026-109619 — RCE vía estado global huérfano. Aquí el estado global propiedad del request sobrevive a la liberación de su memoria de respaldo. Si el mismo worker procesa otra petición, PHP puede reutilizar ese estado huérfano antes de que la inicialización normal lo sobrescriba.

El análisis público del exploit describe una forma concreta: un POST application/x-www-form-urlencoded de varios megabytes con un nombre de campo sobredimensionado que dispara el out-of-memory durante el parsing de $_POST. Requiere un body mayor de 1 MB, lo que lo hace bloqueable en el WAF o el edge — pero filtrar por tamaño es una venda, no una cura.

Quién está en riesgo

Todas las configuraciones que sirven web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP señala mod_php como el escenario de mayor riesgo, porque una petición sin autenticar puede disparar la explotación antes de que se ejecute el código de tu aplicación. Ni tu framework, ni tu capa de negocio, ni tu validación de entrada llegan a correr.

Y el impacto no se limita a sitios web. PHP va embebido en appliances, dispositivos de red, interfaces de gestión y productos de terceros donde el administrador no puede actualizar PHP directamente: depende del vendor. Esa es exactamente la brecha que el repo del NCSC viene a cubrir.

Con un agravante: Amazon Threat Intelligence observó intentos de explotación el 17 de octubre, cuatro días antes del disclosure público. Esto ya se está explotando.

El repo: NCSC-NL/php2shell

El repositorio, creado el mismo día del disclosure y en expansión continua, se organiza en tres bloques:

• detection_mitigation/ — material de detección y mitigación de ambas vulnerabilidades.
• software/ — el activo más valioso: un inventario SPDX de productos de software con dependencia de PHP potencialmente afectados, actualizado a medida que llegan advisories de vendors. Saber qué producto de tu stack lleva PHP embebido es la mitad de la batalla.
• tools/ — herramientas para usar y generar los ficheros del repositorio.

Se publica bajo licencia EUPL-1.2, con marcaje TLP:CLEAR, y acepta contribuciones vía pull request — su preferencia explícita son las ediciones sobre los ficheros SPDX fuente. En su primer día ya superaba las 140 estrellas y 37 forks.

Qué hacer ahora

1. Inventario. Identifica las aplicaciones PHP y sus versiones de runtime, priorizando los sistemas expuestos a internet.
2. Actualiza. PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si estás en 8.1 o anterior (sin soporte), aplica los backports mínimos de código publicados por PHP para 7.4, 8.0 y 8.1, o los paquetes de tu distribución o vendor LTS.
3. Si no puedes parchear hoy, sigue las mitigaciones temporales de PHP: deshabilitar session.upload_progress, reiniciar workers y revisar la guía oficial de memory_limit, post_max_size y fatal_error_backtraces (PHP 8.5). PHP lo deja claro: no son fixes completos.
4. Vigila. Advisories de vendors, logs de sistemas expuestos y actividad de exploit pública. La lista de advisories de los CSIRT nacionales europeos se centraliza en el repositorio CNW de ENISA.

El contexto

La respuesta institucional a php2shell es inusual por su velocidad y coordinación: la CERT-EU 2026-018, el alert de CISA, el advisory de la NSA y la nota del NCSC británico salieron todos en menos de 24 horas. Cuando varios CERT nacionales se mueven a la vez sobre un lenguaje que según W3Techs sigue alimentando cerca del 70% de la web con backend conocido, la escala del parcheo se vuelve el problema, no la vulnerabilidad.

Ahí está la lección para cualquier equipo: el PHP que tú no administras — el de la imagen Docker de un vendor, el del appliance de red, el del plugin de un CRM — es el que más tarde va a recibir el fix. El inventario SPDX del NCSC existe precisamente para hacer visible ese PHP invisible. Y la detección de explotación temprana cuatro días antes del disclosure confirma la regla de oro: en vulnerabilities críticas con exploit en la naturaleza, la ventana entre el leak y el parche ya no se mide en semanas.

Cobertura completa del día de parches en ia-news: la filtración previa y la crónica de la mañana del embargo, y los 10 CVEs de Node.js del mismo miércoles.