PHP2Shell (CVE-2026-109618): mitigarlo si aún no puedes actualizar

PHP2Shell son dos vulnerabilidades críticas de ejecución remota de código en el propio intérprete de PHP: CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 9.2. Los detalles se filtraron antes del parche y ya hay explotación activa. El 21 de octubre de 2026 PHP publicó las versiones corregidas. Este artículo es para quien aún no puede actualizar: qué reduce la exposición mientras tanto y qué revisar después.

Lo primero: no hay mitigación completa sin actualizar

Lo dice el propio aviso de PHP: "no hay mitigaciones completas, actualizar es la única opción segura". Todo lo que verás aquí son capas que reducen la superficie, no sustitutos del parche. Si una aplicación PHP expuesta a internet no es crítica y no puedes actualizarla hoy, lo más seguro es apagarla: varias organizaciones neerlandesas (Tweakers, la Tweede Kamer, el NCSC) lo hicieron por precaución.

Qué versiones de PHP afecta PHP2Shell

Paquetes de las distribuciones (22-oct, 18:40): Ubuntu ya los tiene para 26.04, 24.04 y 22.04 (USN-8948-1), y para 20.04, 18.04, 16.04 y 14.04 solo con Ubuntu Pro (USN-8948-2), Debian para trixie (DSA-6574-1) y el repositorio de Ondřej Surý (sury.org) está publicando parches para todas sus ramas, incluso PHP 5.6. Red Hat (RHSB-2026-013) afecta a RHEL 8, 9 y 10 y a las imágenes UBI; ya hay algunas actualizaciones y otras en camino, y los contenedores hay que reconstruirlos. Los backports de PHP para 7.4, 8.0 y 8.1 son parches en código fuente, no versiones descargables: si no compilas, usa el paquete de tu distribución. Estado actualizado en la alerta.

Por SAPI, el riesgo es mayor en Apache con mod_php: PHP ha demostrado ahí la explotación completa con una petición sin autenticar, antes de que se ejecute la aplicación. PHP-FPM también es vulnerable (en FPM se validó la vía de session upload progress), y FrankenPHP y LiteSpeed son probables candidatos. Si usas el repositorio de Remi, PHP avisa de que no tendrá actualizaciones el día del parche: usa los paquetes de la distribución o compila. Y si tu proveedor hace backport, la versión upstream puede no cambiar: compara la revisión completa del paquete con su aviso de seguridad.

Cómo funciona el ataque

Antes del parche se especulaba con un use-after-free en session upload progress y un fallo en el parser multipart. El aviso oficial lo concreta en dos fallos distintos:

• CVE-2026-109618, corrupción por falta de memoria (OOM). Una petición diseñada para agotar memory_limit (por ejemplo, un multipart sin longitud declarada, con muchas cabeceras por parte o campos muy anidados) interrumpe PHP con datos internos a medio inicializar, y la limpieza de la petición los trata como válidos.
• CVE-2026-109619, estado global obsoleto. Tras un error fatal, parte del estado de una petición sobrevive aunque su memoria se haya liberado, y la siguiente petición atendida por el mismo worker lo usa. Session upload progress (activo por defecto) y, en PHP 8.5, fatal_error_backtraces son vías confirmadas.

Lo importante para defenderse: buena parte del ataque ocurre antes de ejecutar tu código. Un middleware de Laravel, un plugin de seguridad de WordPress o el modo mantenimiento llegan tarde. Ocultar errores con display_errors, error_reporting o @ tampoco ayuda. La defensa tiene que estar en la configuración de PHP y delante de PHP: servidor web, WAF o red.

Mitigaciones si aún no puedes actualizar, por capas

1. Las mitigaciones temporales del aviso oficial

Son las que propone el equipo de PHP para cada CVE. Ponlas en el php.ini del SAPI web o, mejor, en el pool de FPM con php_admin_value, para que la aplicación no pueda sobrescribirlas. No valen ini_set() ni .user.ini.

; php.ini (en el del SAPI web: /etc/php/8.x/fpm/php.ini o apache2/php.ini)
; Mitigaciones temporales del aviso oficial. NO sustituyen a actualizar.

; CVE-2026-109618
memory_limit = -1
post_max_size = 8M          ; 32M si necesitas subidas
upload_max_filesize = 2M    ; siempre por debajo de post_max_size

; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; solo PHP 8.5

Por pool de PHP-FPM:

; /etc/php/8.x/fpm/pool.d/www.conf (en cada pool)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_flag[session.upload_progress.enabled] = off
; solo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
; opcional, si el rendimiento lo permite: un worker nuevo por petición
pm.max_requests = 1

# reinicia TODOS los workers (un reload no siempre basta)
sudo systemctl restart php8.x-fpm      # con mod_php: sudo systemctl restart apache2

• memory_limit = -1 es la mitigación principal de CVE-2026-109618, pero no completa. Compensa el riesgo de consumo de memoria con un límite de contenedor o cgroup (memory.max). No uses RLIMIT_AS ni RLIMIT_DATA: provocan justo el fallo de asignación que activa la vulnerabilidad.
• Revisa que ningún pool, .htaccess o configuración de la aplicación vuelva a fijar un memory_limit finito.
• El aviso recomienda mantener session.upload_progress.enabled = 0 también después de parchear si no usas esa función.

2. Limitar o bloquear multipart/form-data en el servidor web

El propio aviso de CVE-2026-109618 recomienda bloquear las peticiones multipart antes de que lleguen a PHP si la aplicación no las usa. El precio: rompe todas las subidas de archivos y cualquier formulario multipart (en algunas tiendas, también el checkout). Prueba los flujos críticos después de aplicarlo.

nginx (el patrón de Flare; la regex sin anclar también caza mayúsculas, comas y espacios en la cabecera):

# contexto http {}
map $http_content_type $block_multipart {
    default        0;
    "~*multipart"  1;
}

# en cada server {} que sirva PHP
if ($block_multipart) {
    return 403;
}

# limita también el tamaño del cuerpo
client_max_body_size 8m;

Apache (usa %{HTTP:Content-Type}; %{CONTENT_TYPE} no coincide con nada en este contexto y falla en silencio):

# en cada <VirtualHost> que sirva PHP
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F]

# limita también el tamaño del cuerpo (bytes)
LimitRequestBody 8388608

Si necesitas subidas, no bloquees: limita en el proxy el tamaño del cuerpo, el número de partes, de cabeceras por parte y de campos, como pide el aviso. Puedes permitir multipart solo en rutas concretas, sabiendo que esas rutas siguen expuestas. Para comprobar que tu regla no se salta con variantes de la cabecera (mayúsculas, comas, cabeceras duplicadas, cuerpo chunked), el repositorio open-source php2shell-guard incluye reglas para nginx, Apache, Caddy, HAProxy y ModSecurity con un test de esas variantes. Revisa el código antes de ejecutarlo.

3. Cloudflare u otro WAF delante

Cloudflare desplegó reglas WAF de emergencia para todos los planes, incluido el gratuito. Comprueba que las managed rules están activas (en planes de pago, el Managed Ruleset en modo bloqueo; los bloqueos aparecen en Security → Security Analytics → Events como reglas "Anomalous Execution") y, sobre todo, cierra el acceso directo al origen: si el servidor acepta tráfico de cualquier IP, quien conozca la IP real se salta el WAF. Limita el firewall del origen a los rangos de IP publicados por Cloudflare. Un WAF interpreta el multipart de forma distinta a PHP: es una capa más, no una solución.

4. Medidas estructurales

• Sacar de internet lo que no necesite estar expuesto: paneles de administración, intranets, herramientas internas detrás de VPN o lista de IPs permitidas.
• Modo solo lectura: dejar pasar solo GET y HEAD mantiene la web visible y corta los cuerpos POST.
• Apagar PHP-FPM y servir una página estática de mantenimiento en lo que no sea crítico.
• Pasar de mod_php a PHP-FPM si no puedes actualizar a corto plazo: es donde PHP ha demostrado la explotación más directa.

# modo solo lectura: solo GET y HEAD llegan a PHP
if ($request_method !~ ^(GET|HEAD)$) {
    return 503;
}

Comprueba qué tienes realmente

La versión y configuración que importan son las del PHP que sirve la web, no las de la CLI (php -i lee otro php.ini):

# versión y configuración que usa la web (no la CLI): crea, consulta y BORRA
echo '<?php phpinfo();' | sudo tee /var/www/html/_pi.php
# abre https://tu-dominio/_pi.php y revisa: versión, memory_limit,
# session.upload_progress.enabled y (8.5) fatal_error_backtraces
sudo rm /var/www/html/_pi.php

# paquetes instalados
dpkg -l | grep -E '^ii +php' ; rpm -qa | grep -i php

Después de actualizar

• Reinicia todo lo que mantiene PHP en memoria: PHP-FPM, Apache con mod_php, Octane, workers de colas. Sin reinicio sigue corriendo el binario vulnerable.
• Busca intentos con las señales que propone Wiz: peticiones multipart raras seguidas de errores de memory_limit, errores 500 repetidos, cookies PHPSESSID anormalmente grandes o malformadas y reinicios inexplicables de workers.
• Busca compromiso, no solo vulnerabilidad: web shells, ficheros PHP nuevos o modificados, usuarios administradores nuevos y conexiones salientes raras. Hubo explotación antes del parche: Amazon vio el primer intento el 17 de octubre, así que revisa al menos desde esa fecha (Aikido recomienda ir hasta junio de 2026). Busca en los logs peticiones POST con PHP_SESSION_UPLOAD_PROGRESS.
• Retira las reglas temporales (bloqueo multipart, solo lectura, memory_limit = -1) cuando el parche esté aplicado y verificado. Pero deja session.upload_progress.enabled = 0: PHP lo recomienda incluso con el parche puesto, hasta la próxima versión, por otro fallo menos probable (CVE-2026-115560, aviso del 23-oct).

Preguntas frecuentes

---

Fuentes:

• PHP: publicación de seguridad del 21-oct-2026
• Aviso CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
• Aviso CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
• Sansec: Critical PHP RCE (CVE-2026-109618 y 109619)
• Aikido: PHP2Shell
• Flare: qué hicimos y qué deberías hacer

Artículos relacionados:

• ¿Tu web usa PHP? Actualiza hoy o puede ser atacada
• op.exp.8 Registro de la actividad: cómo cumplir el ENS con Wazuh

---