Tutorial: Como mitigar PHP2Shell (CVE-2026-109618 / 109619)

Daniel Muñoz · Ayer a las 09:50

⚠️ PHP2Shell: qué hacer si tienes hosting compartido y tu proveedor no ha actualizado

PHP sacó el 21/10 parches de emergencia para dos vulnerabilidades críticas (CVE-2026-109618 y CVE-2026-109619), con puntaje 9.2/10. Permiten ejecutar código en el servidor sin estar logueado, y ya hay ataques activos.

Las versiones corregidas son: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

El detalle es que muchos hostings todavía no han compilado los paquetes, el repo de Ondřej está colapsado y los proveedores no responden tickets. Aquí les dejo qué pueden hacer mientras tanto y, sobre todo, qué tienen que exigirle a su proveedor.

Ojo, antes de empezar: la única solución completa es actualizar PHP a la versión corregida. Las mitigaciones temporales solo reducen la exposición, y en hosting compartido la mayoría de ellas solo las puede aplicar el proveedor, porque tienen que ir a nivel de servidor. Siendo honestos, aquí estamos bastante en manos del hosting.

🥇 Paso 1: revisa si ya tienes la versión parcheada disponible

Esto es lo primero, porque si existe, se acabó el problema.

Si tienes cPanel (Banahosting y la mayoría de los hostings latinos):

Busca "Select PHP Version" o "Seleccionar versión de PHP" (CloudLinux), o "MultiPHP Manager".
Fíjate si en la lista aparece la versión parcheada de tu rama (por ejemplo 8.3.36 si estás en 8.3).
Si aparece, cámbiala y listo. Si no, sigue al paso 2.

Si tienes Plesk: ve al dominio → PHP Settings y mira qué versiones te ofrece.

Si tienes DirectAdmin: Domain Setup / PHP Version Selector, lo mismo.

Los paquetes de CloudLinux (alt-php) y de cPanel (ea-php) suelen salir antes que los de Ondřej, así que vale la pena revisar varias veces en el día.

🥈 Paso 2: pon Cloudflare delante de tu sitio (si no lo tienes)

Cloudflare ya está detectando los ataques. Con tu dominio pasando por ahí, el tráfico malicioso se filtra antes de llegar a PHP. Revisa en el panel de Security → WAF si tienes activas las reglas administradas para estos CVE (en el plan gratuito puede variar, así que verifícalo).

Hoy, en hosting compartido, esto es lo más efectivo que puedes hacer por tu cuenta.

🥉 Paso 3: mitigaciones de configuración (aquí manda el proveedor)

Importante: El advisory oficial de PHP aclara que session.upload_progress.enabled = 0 tiene que aplicarse antes de que PHP procese la petición, o sea, en el php.ini del servidor o en el pool de PHP-FPM, reiniciando los workers. En PHP-FPM no se debe confiar en .user.ini para esto.

En hosting compartido eso significa que la mitigación real la tiene que aplicar tu proveedor, no tú. Por eso los pasos 1 y 2 son la prioridad.

Lo que tiene que hacer el hosting (a nivel de servidor o pool):

Insertar CODE, HTML o PHP:

session.upload_progress.enabled = 0
memory_limit = -1   (con límite de memoria externo por cuenta: LVE/cgroups)
fatal_error_backtraces = 0   (solo PHP 8.5)

y reiniciar todos los workers de PHP.

Texto para el ticket, por si tu hosting no responde:

Insertar CODE, HTML o PHP:

Asunto: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) - solicitud urgente

Mi cuenta sigue en PHP [VERSIÓN], sin el parche publicado el 21/10
(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).

Mientras compilan la versión corregida, solicito aplicar a nivel de
servidor o pool de FPM (no .user.ini) las mitigaciones del advisory
oficial de PHP:

- session.upload_progress.enabled = 0
- memory_limit = -1, con límite de memoria externo por cuenta
- fatal_error_backtraces = 0 (si es PHP 8.5)

y reiniciar los workers. Por favor indíquenme fecha estimada del parche.

¿Y lo que puedo hacer yo desde mi cuenta?

Poco, siendo honestos. Puedes dejar esto en tu .user.ini (o desde cPanel → MultiPHP INI Editor):

Insertar CODE, HTML o PHP:

session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Si tu sitio necesita subir archivos pesados, usa post_max_size = 32M y deja upload_max_filesize un poco por debajo.

Pero tengan claro que, en PHP-FPM, esto no te protege de esta vulnerabilidad: se aplica tarde. Lo dejas como capa extra, no como solución.

No metas php_value / php_flag en el .htaccess si tu PHP corre como FPM/CGI. Te tumba el sitio con error 500. Para saber cómo corre, crea sapi.php con <?php echo php_sapi_name();, ábrelo y bórralo. Si sale fpm-fcgi, cgi-fcgi o litespeed, nada de php_value en .htaccess.

Si tienes Plesk: en dominio → PHP Settings → "Additional configuration directives" puedes pegar las directivas del bloque del proveedor. Según cómo tenga configurado Plesk tu hosting, eso puede quedar a nivel de pool, pero confírmalo con soporte antes de darlo por mitigado.

🤔 ¿Por qué memory_limit = -1? ¿Eso no es peligroso?

Buena pregunta. Una de las vulnerabilidades se activa cuando el atacante hace que PHP llegue a su límite de memoria. Al quitar el límite se cierra esa vía, pero no todas: PHP deja claro que no es una mitigación completa.

Y tiene su propio riesgo: una sola petición podría comerse toda la RAM. Por eso solo tiene sentido si existe un límite de memoria externo por cuenta (LVE/cgroups en CloudLinux). No es algo para poner a ciegas, y por eso va en la lista de lo que tiene que aplicar el proveedor.

Cuando PHP esté actualizado, el memory_limit tiene que volver a un valor normal (256M, por ejemplo).

🧹 Paso 4: limpia tus .htaccess y .user.ini viejos (esto sí depende de ti)

Uno de los dos disparadores confirmados del ataque son los warnings que generan ajustes de PHP inválidos u obsoletos aplicados por petición. Muchos tenemos .htaccess heredados de hace años con directivas que ya no existen.

Revisa todas las carpetas, no solo la raíz (plugins, subdominios, carpetas viejas), y quita cosas como:

Insertar CODE, HTML o PHP:

magic_quotes_gpc
register_globals
safe_mode
allow_call_time_pass_reference

y cualquier otra directiva de PHP que no reconozcas o que sea de versiones antiguas.

✅ Paso 5: revisa tu configuración (sin confiarte)

Crea check.php en la raíz, ábrelo en el navegador y bórralo apenas lo veas:

Insertar CODE, HTML o PHP:

<?php
header('Content-Type: text/plain');
foreach (['session.upload_progress.enabled','memory_limit','post_max_size','upload_max_filesize'] as $k) {
    echo $k, ' = ', var_export(ini_get($k), true), PHP_EOL;
}
echo 'PHP ', PHP_VERSION, ' / ', php_sapi_name(), PHP_EOL;

Importante: esto solo confirma qué versión de PHP tienes y que las directivas están puestas sin dar error. No prueba que la mitigación esté activa en el momento del ataque: un .user.ini puede mostrar "0" aquí y aun así no proteger nada. Lo que de verdad importa es que la versión sea una de las corregidas.

Resumen rápido:

¿Tu panel ya tiene la versión parcheada? → Cámbiala y listo.
¿No la tiene? → Cloudflare delante + ticket al proveedor para que aplique las mitigaciones a nivel de servidor.
Limpia directivas viejas en todos tus .htaccess / .user.ini.
.user.ini con upload_progress = 0 como capa extra, sin confiarte.
Cuando actualicen PHP: confirma la versión con check.php y regresa el memory_limit a la normalidad.

Si tu hosting tarda días en reaccionar a algo de 9.2 con ataques activos, eso también dice bastante de él.

Cualquier duda, me dejan su caso aquí abajo con la versión de PHP que les sale y les echo una mano. 🤝

Tronlar · Ayer a las 09:58

Buen aporte. Solo matizaría una cosa del paso 3 por lo que indica PHP en el advisory oficial.

Para session.upload_progress.enabled = 0, PHP advierte que en PHP-FPM no se debe confiar en .user.ini como mitigación, porque esa configuración tiene que aplicarse antes del procesamiento de la petición. Recomiendan hacerlo desde php.ini, la configuración del pool de FPM o la configuración del servidor y reiniciar los workers.

Por eso, aunque un check.php muestre session.upload_progress.enabled = 0, no necesariamente confirma que esa mitigación esté actuando en el momento necesario para bloquear esta vulnerabilidad.

También indican que memory_limit = -1 reduce una de las vías de explotación, pero no es una mitigación completa y puede tener sus propios riesgos si no existe un límite de memoria externo.

En hosting compartido al final estamos bastante en manos del proveedor.
Las medidas temporales pueden ayudar, pero PHP deja claro que la solución completa es actualizar a las versiones corregidas.

Daniel Muñoz · Ayer a las 10:08

Tronlar dijo:
Buen aporte. Solo matizaría una cosa del paso 3 por lo que indica PHP en el advisory oficial.

Para session.upload_progress.enabled = 0, PHP advierte que en PHP-FPM no se debe confiar en .user.ini como mitigación, porque esa configuración tiene que aplicarse antes del procesamiento de la petición. Recomiendan hacerlo desde php.ini, la configuración del pool de FPM o la configuración del servidor y reiniciar los workers.

Por eso, aunque un check.php muestre session.upload_progress.enabled = 0, no necesariamente confirma que esa mitigación esté actuando en el momento necesario para bloquear esta vulnerabilidad.

También indican que memory_limit = -1 reduce una de las vías de explotación, pero no es una mitigación completa y puede tener sus propios riesgos si no existe un límite de memoria externo.

En hosting compartido al final estamos bastante en manos del proveedor.
Las medidas temporales pueden ayudar, pero PHP deja claro que la solución completa es actualizar a las versiones corregidas.

Gracias por el matiz. Es importante y corrijo el post.

El punto clave es este: con PHP-FPM, el .user.ini se aplica tarde para esta vulnerabilidad. La subida multipart se procesa antes de que esa configuración entre en juego, así que aunque el check.php diga session.upload_progress.enabled = 0, eso solo confirma que el valor está puesto cuando corre tu script, no que estuviera activo en el momento del ataque. El check sirve para ver que la directiva no da error, nada más.

Lo mismo con memory_limit = -1: cierra una vía, no todas. Y sin un límite de memoria externo (LVE/cgroups del hosting) cambias un riesgo por otro.

En resumen, para hosting compartido con FPM, lo que de verdad sirve hoy es:

Cambiar a la versión parcheada si tu panel ya la ofrece (revisen varias veces al día).
Cloudflare / WAF delante, que filtra antes de que la petición llegue a PHP.
Presionar al proveedor para que ponga las mitigaciones a nivel de servidor (php.ini o pool de FPM) y reinicie los workers, mientras compila el parche.

El .user.ini no hace daño si está limpio, pero no hay que contar con él como protección.

Les dejo un texto para el ticket, por si su hosting no responde:

Insertar CODE, HTML o PHP:

Asunto: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) - solicitud urgente

Mi cuenta sigue en PHP [VERSIÓN], sin el parche publicado el 21/10
(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).

Mientras compilan la versión corregida, solicito aplicar a nivel de
servidor o pool de FPM (no .user.ini) las mitigaciones del advisory
oficial de PHP:

- session.upload_progress.enabled = 0
- memory_limit = -1, con límite de memoria externo por cuenta
- fatal_error_backtraces = 0 (si es PHP 8.5)

y reiniciar los workers. Por favor indíquenme fecha estimada del parche.

Y sí, al final en compartido estamos en manos del proveedor. Si el tuyo tarda días en reaccionar a algo de 9.2 con ataques activos, eso también dice bastante de él.

Tutorial: Como mitigar PHP2Shell (CVE-2026-109618 / 109619)

Daniel Muñoz

Tronlar

Daniel Muñoz

Temas similares