CVE-2026-109618: mitigar la vulnerabilidad de PHP sin parche

¿Hay una mitigación para CVE-2026-109618 y CVE-2026-109619?

Solo parciales, y ninguna es una corrección. El aviso de PHP lo dice así: aunque solo una actualización es una solución completa, las medidas que propone reducen la exposición a vías de ataque concretas, pero no hacen segura una instalación. Para CVE-2026-109619, el aviso de GitHub añade que no existe una mitigación genérica completa por configuración. Usa estos ajustes solo para ganar tiempo hasta que instales el parche de PHP2Shell. En España, el aviso de INCIBE-CERT recuerda igualmente que las medidas temporales no son una solución completa.

¿Cuáles son las medidas temporales oficiales?

Ajuste	Para	Qué bloquea	Efectos secundarios
`memory_limit=-1` (para que las aplicaciones no puedan cambiarlo)	CVE-2026-109618	El fallo controlable por el límite de memoria de PHP. Un fallo de reserva de memoria de más bajo nivel puede seguir llegando al código vulnerable.	Los procesos de PHP pueden usar memoria sin límite; vigila los recursos del servidor.
`post_max_size` bajo: `8M` si no necesitas subidas de archivos, `32M` si las necesitas	CVE-2026-109618	Reduce la cantidad de datos de la petición que se pueden meter en PHP	Fallan las subidas y los formularios más grandes.
`session.upload_progress.enabled=0`	CVE-2026-109619	Las vías confirmadas a través de la sesión, no otras variantes	Pueden dejar de funcionar las barras de progreso de subida.
`fatal_error_backtraces=0` (solo PHP 8.5)	CVE-2026-109619	Solo la vía confirmada a través de los backtraces de errores fatales	Menos detalle de diagnóstico en los registros de errores.

Todos estos ajustes necesitan reiniciar todos los procesos de PHP para surtir efecto. PHP advierte además que no hay que sustituirlos por límites RLIMIT_AS o RLIMIT_DATA, que pueden provocar precisamente el fallo de reserva de memoria vulnerable, y que ocultar errores con error_reporting, display_errors o @ no sirve.

¿Cómo aplico bien la medida de session.upload_progress?

El ajuste tiene que estar activo antes de que PHP analice la petición:

Configura session.upload_progress.enabled=0 en php.ini, en la configuración del pool de PHP-FPM o en la configuración del servidor web.
No uses ini_set() en el código ni un archivo .user.ini de FPM; se aplican demasiado tarde.
Reinicia todos los procesos de PHP (todos los pools de PHP-FPM, o Apache si usas mod_php). Los procesos que no se reinician siguen con la configuración antigua.

En un hosting compartido normalmente no puedes cambiar estos ajustes; pídeselo a tu proveedor o instala el parche a través de él.

¿Vale como mitigación que mi web no tenga subida de archivos?

No. Las vías de ataque están en el tratamiento de peticiones de PHP, no en el formulario de subida de tu web, así que una web sin subida de archivos no está a salvo por eso. Precisamente por eso el ajuste oficial es una opción de PHP a nivel de servidor y no un interruptor de la aplicación.

¿Un WAF como Cloudflare cuenta como mitigación?

No. Es una capa adicional, no una corrección. Cloudflare desplegó reglas de WAF automáticamente en todos los planes con WAF, incluido el gratuito, unas nueve horas antes de la publicación, e informó de que los atacantes modificaban sus cargas para esquivarlas. Un WAF solo filtra el tráfico que pasa por él, y el PHP de tu servidor sigue siendo vulnerable.

¿Sirve un plugin de modo mantenimiento como mitigación?

No de forma fiable. Una página de mantenimiento de WordPress la sirve el propio PHP, y algunas vías de ataque se producen antes de que se ejecute el código de la aplicación. Para cortar la exposición sin parchear, bloquea las peticiones antes de que lleguen a PHP o desconecta la web, como aconsejaron varias agencias nacionales para las webs que no se pueden actualizar.

¿Cuánto tiempo puedo confiar en una medida temporal?

Solo hasta que puedas actualizar, idealmente cuestión de días. Las correcciones y los análisis técnicos son públicos, y Sansec prevé una explotación masiva. Planifica la actualización ya. Comprueba tu situación con el comprobador PHP2Shell y lee CVE-2026-109618 y CVE-2026-109619 para conocer los detalles de cada fallo.

¿Qué fuentes respaldan esta página?

Comprueba si tu PHP está afectado por PHP2Shell

Introduce la versión que indica tu web. La comparamos con la primera versión corregida de su rama y te decimos qué hacer a continuación.

Comprobador PHP2Shell →

Fuentes

Los datos principales de esta página (versiones corregidas, detalles de los CVE, paquetes de los distribuidores y avisos de organismos oficiales) proceden de fuentes oficiales. Las investigaciones, noticias y publicaciones de la comunidad se identifican como tales.

Security advisory: Critical remote code execution vulnerabilities, update nowOficial The PHP Group
RCE via OOM corruptionOficial The PHP Group
RCE via stale global stateOficial The PHP Group
Cloudflare deploys protections against php2shell vulnerabilityProveedor de CDN Cloudflare
PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)Investigación Sansec

Mitigación de CVE-2026-109618: medidas temporales contra PHP2Shell y sus límites