← Notas de desarrollo

Respuesta a PHP2Shell: verificar la compilación corregida de PHP y los procesos web

En esta página

La corrección de PHP2Shell no termina al actualizar el CMS o un complemento. Obtén una compilación de PHP que corrija CVE-2026-109618 y CVE-2026-109619, y verifica después que la utilice cada proceso que atiende solicitudes web. El comando php -v de una terminal solo informa sobre el CLI seleccionado en esa terminal.

¿A qué afecta PHP2Shell?

Los dos CVE afectan al estado de las solicitudes y al tiempo de vida de la memoria del motor de PHP. El primero implica el uso de un estado no válido durante la limpieza después de que la gestión de un agotamiento de memoria interrumpa la inicialización. El segundo implica un estado interno que persiste tras liberar la memoria de una solicitud y que utiliza una solicitud posterior en el mismo proceso. En las condiciones afectadas, es posible ejecutar código de forma remota sin autenticación.

El aviso del equipo de PHP incluye PHP-FPM, php-cgi, FrankenPHP y LiteSpeed, además de mod_php, entre los despliegues que atienden tráfico web y deben investigarse. Una SAPI concreta no es motivo para excluir un servicio. A la inversa, una cadena de versión vulnerable por sí sola no demuestra que exista una vía de explotación accesible en ese servicio.

¿Qué versión debes comparar?

Estas son las primeras versiones del código fuente original que corrigen los dos CVE iniciales, comprobadas el 30 de octubre de 2026. Antes de instalar, consulta la versión compatible actual del mismo proveedor y los avisos posteriores.

Rama de PHP Primera versión del código fuente que corrige ambos CVE
8.2 8.2.35
8.3 8.3.36
8.4 8.4.27
8.5 8.5.12

En los paquetes de distribuciones, compara la revisión completa del paquete con el aviso de su proveedor, en lugar de la versión abreviada de PHP. Por ejemplo, Ubuntu USN-8948-1 identifica 8.3.6-0ubuntu0.24.04.13 como el paquete php8.3-fpm corregido para Ubuntu 24.04. Comparar ese número con la versión original 8.3.36 clasifica erróneamente una corrección adaptada a una versión anterior. El aviso no autentica compilaciones personalizadas arbitrarias que muestren la misma cadena de versión.

El proyecto PHP ya no ofrece soporte para PHP 8.1 ni versiones anteriores. Verifica el soporte del proveedor y las pruebas de la adaptación de las correcciones, o migra a una rama con soporte. Un parche publicado para el código fuente y la prueba de que un servidor ejecuta ese parche son cosas distintas.

Recopilar pruebas del CLI sin confundirlas con pruebas de la web

Registrar como JSON el ejecutable CLI seleccionado, su versión y su configuración; evaluar los procesos web por separado

El diagrama sigue el recopilador que aparece a continuación. Bajo una SAPI web, termina sin imprimir información. Bajo el CLI, registra el ejecutable, la versión y la configuración sin decidir si está corregido. La identificación del servicio, la aplicación del parche y el reinicio son pasos operativos independientes que este código no realiza.

Con PHP 8.2 o posterior, guarda el archivo en un directorio nuevo fuera de la raíz de documentos. Solo lee el proceso actual mediante las constantes de PHP e ini_get; no envía solicitudes, no cambia ajustes ni inicia sesiones. No es necesario publicar una página phpinfo().

runtime-evidence.php

<?php
if (PHP_SAPI !== 'cli') {
    http_response_code(404);
    exit;
}

$evidence = [
    'scope' => 'this-cli-process-only',
    'pid' => getmypid(),
    'version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
    'binary' => PHP_BINARY,
    'loadedIni' => php_ini_loaded_file() ?: null,
    'uploadProgress' => ini_get('session.upload_progress.enabled'),
    'serializeHandler' => ini_get('session.serialize_handler'),
];
echo json_encode($evidence, JSON_PRETTY_PRINT | JSON_THROW_ON_ERROR), PHP_EOL;
php runtime-evidence.php
php -n -d session.upload_progress.enabled=0 runtime-evidence.php

El primer comando lee la configuración del CLI seleccionado. El segundo omite los archivos ini y desactiva el seguimiento del progreso de las subidas solo para esa invocación del CLI. No cambia la configuración del servidor web ni comprueba la configuración efectiva de un proceso web.

La comprobación local se ejecutó en un contenedor aislado de PHP CLI y confirmó una salida JSON con sapi igual a cli. El segundo comando devolvió null para loadedIni y la cadena "0" para uploadProgress. Las rutas, el PID, la versión y los valores predeterminados varían según el entorno. Estos resultados no establecen si un servicio de producción está corregido ni reproducen una explotación.

Verificar por separado la instalación y los procesos en ejecución

  1. Sigue la configuración del servidor web hacia sus servicios de destino, de FastCGI o de los módulos para identificar el ejecutable PHP real, los grupos de procesos, los contenedores y las réplicas. No supongas que el CLI del host y el entorno de ejecución web comparten una ruta de instalación.
  2. Compara el proveedor de ese entorno de ejecución y la revisión completa del paquete o el resumen de la imagen con el aviso. En una compilación personalizada, establece la relación entre el commit de corrección y el artefacto desplegado.
  3. Despliega una compilación corregida compatible y sustituye los procesos del grupo o servicio afectado, o sus contenedores. Comprueba primero el alcance del cambio si otros servicios comparten el entorno de ejecución.
  4. Verifica la relación entre los procesos nuevos y la compilación corregida en todos los objetivos. Comprueba las páginas normales, el comportamiento del inicio de sesión y las sesiones, las subidas y las tasas de error. No consideres terminado un despliegue parcial ni uno sin pruebas de los procesos en ejecución.

Separar «artefacto corregido identificado» de «adopción en ejecución verificada» en los registros internos de activos ayuda a localizar procesos omitidos. Un fallo por sí solo no demuestra una intrusión, y la ausencia de registros de error no la descarta. Si se sospecha una intrusión, conserva las pruebas e investiga por separado de la aplicación del parche.

Separar el aviso posterior sobre sesiones y la recompilación para Windows

El aviso posterior de PHP del 23 de octubre trata CVE-2026-115560 por separado. Se refiere a la combinación de session.serialize_handler configurado como php_binary o php_serialize, código de la aplicación que lo cambia a php antes de llamar a session_start(), y el seguimiento del progreso de las subidas aún habilitado. El aviso sugiere session.upload_progress.enabled=0 hasta la siguiente corrección ordinaria. Ese ajuste no demuestra que los dos CVE originales estén completamente resueltos. Comprueba la configuración efectiva de la SAPI web y el impacto en las funciones.

El aviso para Windows del 26 de octubre anuncia los paquetes 8.5.12-1, 8.4.27-1, 8.3.36-1 y 8.2.35-1, que incorporan la corrección de Brotli para CVE-2026-111497. Estos recompilan dependencias sin cambiar la versión del código fuente de PHP, por lo que PHP_VERSION por sí solo no permite distinguirlos. Los despliegues de Windows que usan la descompresión automática de respuestas de cURL también deben comprobar esa corrección del paquete. Consulta la guía de respuesta a Node2Shell para el mismo CVE de Brotli en Node.js.

Comentarios

Ver en GitHub ↗