Corregir PHP2Shell: actualizar PHP y reiniciar los workers

Versiones objetivo

• PHP 8.5.12 o posterior en la rama 8.5
• PHP 8.4.27 o posterior en la rama 8.4
• PHP 8.3.36 o posterior en la rama 8.3
• PHP 8.2.35 o posterior en la rama 8.2
• Todo lo anterior: pasar a una de estas versiones o confirmar un backport del proveedor y tratarlo como solución transitoria. La CISA aconseja desconectar PHP sin parchear si no es posible actualizar, incluido expresamente PHP 8.1 y anteriores.

Los tarballs de código fuente y los builds para Windows están en la página de descargas de PHP. Según php.net, las distribuciones Linux y los proveedores LTS recibieron los parches antes de la publicación, por lo que el paquete de la distribución suele ser el camino correcto. El mismo aviso indica que el repositorio voluntario Remi (rpms.remirepo.net) no tenía las actualizaciones el 21 de octubre y aconseja a sus usuarios pasar a los paquetes de la distribución o compilar por su cuenta.

Debian, Ubuntu y otros sistemas apt

Debian ha publicado correcciones: DLA-4848-1 (Debian LTS) para Debian 12 bookworm, php8.2 8.2.35-1~deb12u1, y DSA-6574-1 para Debian 13 trixie, php8.4 8.4.27-1~deb13u1. El security tracker marca como vulnerables los builds de la suite base (bookworm php8.2 8.2.32-1~deb12u1, trixie php8.4 8.4.24-1~deb13u1), así que la corrección solo llega si la suite de seguridad está en sus fuentes de paquetes. El 22 de octubre, el tracker seguía marcando testing (forky) php8.4 8.4.26-1 como vulnerable.

Actualice los metadatos e instale los paquetes de PHP realmente publicados. Los nombres siguen la rama menor (php8.3-fpm, php8.3-cli, php8.3-common y el paquete del módulo de Apache para mod_php). Si la versión candidata sigue por debajo de la corrección, espere a la distribución: no le falta ninguna opción.

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL, Alma, Rocky, Fedora: dnf o yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker y otras imágenes

Reconstruya y vuelva a desplegar. Descargar una nueva imagen base no cambia nada hasta que se sustituye la carga de trabajo que atiende el tráfico. Las etiquetas de las imágenes oficiales suelen seguir la versión de PHP; compruebe en Docker Hub que la etiqueta existe antes de fijarla. La indicación de Google Cloud para Cloud Run y GKE es la misma: reconstruir la imagen desplegada, salvo en el caso de una imagen base serverless que Google dice sustituir por sí mismo.

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. Actualice el propio cPanel para que EasyApache ofrezca un build de PHP parcheado. Los menús cambian; manda la documentación de cPanel.
2. En WHM, abra EasyApache 4 y despliegue una versión de PHP igual o superior a la corrección de la rama. En MultiPHP Manager, asigne una versión de PHP a los dominios.
3. Retire los dominios expuestos públicamente de los handlers con PHP 8.1 o anterior, salvo que su proveedor haya confirmado que el build incluye el backport.
4. Reinicie Apache y PHP-FPM desde WHM, compruebe la versión de PHP de un dominio y elimine las páginas de prueba temporales.

Plesk

1. Instale las actualizaciones de Plesk y de los paquetes del sistema. La ruta de clics actual se describe en la documentación de Plesk.
2. En Herramientas y configuración, revise las actualizaciones y la lista de handlers de PHP. La configuración de PHP del dominio muestra qué versión usa realmente una suscripción.
3. Elija un handler parcheado (8.2.35, 8.3.36, 8.4.27 u 8.5.12, o un build verificado del proveedor). Aplíquelo primero a los sitios públicos.
4. Reinicie el servicio de PHP que usa Plesk y compruebe la versión en el dominio, no solo en el host del panel.

宝塔面板 (BT Panel)

Según el aviso de 宝塔 del 22 de octubre de 2026, los paneles para Linux y Windows han sincronizado 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Los paquetes 7.4.34, 8.0.31 y 8.1.35, ofrecidos solo para Linux, son builds de 宝塔, no versiones del proyecto PHP. La ruta de clics y el ajuste incompleto para Windows están en la página de BT Panel.

mod_php frente a PHP-FPM

Ambos figuran en la lista de riesgo del proyecto PHP. mod_php se considera el mayor riesgo porque la vía demostrada sin autenticación actúa antes del código de la aplicación. Reiniciar Apache recarga mod_php. PHP-FPM es un proceso aparte: reinicie cada pool (systemctl restart php8.3-fpm o la unidad equivalente) y tenga en cuenta que los pools pueden fijar su propio binario. El php del PATH de su shell puede ser un build distinto del del pool. PHP cita FrankenPHP, php-cgi y LiteSpeed como SAPI que atienden peticiones web y, por tanto, afectadas; siga sus guías de actualización en lugar de suponer que un paquete apt php-fpm las cubre.

Medidas provisionales, incompletas según PHP

Úselas solo como puente, tomadas del aviso de php.net. Reducen algunas vías y no hacen seguro un host. Configúrelas en php.ini o en un ajuste de pool o de Apache a nivel de administrador (php_admin_value). Según PHP, ini_set() y los .user.ini por directorio actúan demasiado tarde para la vía de subida de sesión.

CVE-2026-109618

• memory_limit=-1, fijado de modo que la aplicación ya no pueda establecer un límite finito. Según PHP, así desaparece el error de límite de memoria controlable, pero un fallo de asignación subyacente aún puede alcanzar el fallo.
• Un post_max_size bajo. PHP recomienda 8M sin subidas y 32M con subidas, manteniendo upload_max_filesize por debajo de post_max_size.
• Límites de tamaño de petición en el servidor web o el proxy, también para peticiones sin un Content-Length utilizable. PHP cita el tamaño de petición decodificado, el número de campos de entrada, las partes multipart, las cabeceras y la profundidad de anidamiento.
• Un límite de contenedor o de cgroup como frontera de disponibilidad que termina el worker afectado. PHP desaconseja usar RLIMIT_AS o RLIMIT_DATA, porque pueden desencadenar el fallo de asignación vulnerable.

CVE-2026-109619

• session.upload_progress.enabled=0 y, después, reiniciar cada worker. Según PHP, esto bloquea las vías de sesión confirmadas, no otras variantes.
• Solo en PHP 8.5: fatal_error_backtraces=0 y, después, reiniciar. Según PHP, esto solo bloquea la vía confirmada de backtraces de errores fatales.
• Eliminar ajustes por petición inválidos u obsoletos que emiten diagnósticos antes de la inicialización. Desactivar errores con error_reporting, display_errors o @ no cierra el fallo.
• Corregir errores fatales y tiempos de espera agotados que un atacante pueda alcanzar, también en callbacks y en la limpieza tras subidas o importaciones. Es la formulación del proyecto; se trata de un consejo de endurecimiento, no de una afirmación de que un código de aplicación sin errores haga seguro FPM.

Firewalls de aplicaciones web

La CISA indica que un firewall de aplicaciones web puede ofrecer cierta protección hasta la actualización. Cloudflare indica que las reglas gestionadas para este problema estaban activas desde el 21 de octubre de 2026 a las 03:02 UTC para clientes con planes WAF gratuitos y de pago, desarrolladas aún bajo embargo con la PHP Foundation y otros, y que los clientes debían parchear igualmente. Una regla puede eludirse; la propia Cloudflare observó cómo los atacantes adaptaban sus payloads. Mantenga el WAF, pero no lo use como corrección.

El boletín de AWS 2026-143-AWS enumera controles compensatorios para usuarios de AWS WAF. Para CVE-2026-109618: la regla SizeRestrictions_BODY del Core rule set (CRS) de AWS WAF, como protección adicional frente a cuerpos de solicitud de más de 8 KB (8.192 bytes). Para CVE-2026-109619: AWS publicó la versión 2.3 del grupo de reglas administradas AWS WAF PHP y la convirtió en la versión predeterminada en todo el mundo. El boletín publica además, en JSON, una regla personalizada que bloquea solicitudes POST con PHP_SESSION_UPLOAD_PROGRESS en el cuerpo y PHPSESSID en el cuerpo o en una cookie. AWS también afirma que solo actualizar es una corrección completa y que las versiones sin soporte 5.4 a 8.1 no tienen corrección para CVE-2026-109618.

Después de actualizar

• Compruebe la versión en la SAPI que responde a las peticiones HTTP y reiníciela. Expel y la Universidad de Toronto insisten ambos en el reinicio.
• Priorice los sistemas expuestos públicamente, después todo lo que procese subidas o importaciones no fiables y, por último, los appliances. El NCSC británico y el Centro Canadiense de Ciberseguridad indican ambos que los productos de terceros con PHP integrado necesitan sus propias actualizaciones del fabricante.
• Si un host estuvo expuesto y no pudo parchearse rápido, la CISA aconseja buscar workers de PHP que lancen shells o descarguen herramientas. El NCSC británico aconseja buscar puertas traseras antes de confiar en un host expuesto y luego actualizado. No podemos añadir una lista verificada de indicadores. Elastic Security Labs (21 de octubre) describe con más detalle el mismo enfoque basado en comportamiento: vigilar servidores web o workers de PHP que inicien shells, descarguen herramientas con curl o wget o escriban nuevos archivos de script en la raíz web.
• Las notas del NCSC-NL enlazadas en el aviso británico son un inventario inicial de productos, no una certificación de que un producto no incluido sea seguro.

Endurecimiento que conviene mantener tras actualizar

El aviso completo de PHP recomienda límites en el borde (tamaño decodificado, profundidad de anidación, variables de entrada, partes multipart y cabeceras por parte), rechazar multipart en rutas sin subidas y evitar RLIMIT_AS y RLIMIT_DATA. Por qué los límites de subida no bastan y en qué se diferencian mod_php, FPM, FrankenPHP y LiteSpeed: ver la página de CVE-2026-109618.