PHP2Shell (CVE-2026-109618 y CVE-2026-109619): qué es y cómo saber si tu web está afectada

Qué es PHP2Shell

Es el nombre con el que se conocen dos vulnerabilidades del propio PHP, el lenguaje con el que funcionan WordPress, PrestaShop y la mayoría de gestores de contenidos: la CVE-2026-109618 (aviso GHSA-w8hw-w9fx-j79w) y la CVE-2026-109619 (aviso GHSA-6wmf-4rv5-p3rp). Las dos tienen una gravedad de 9,2 sobre 10 (CVSS 4.0) y se pueden aprovechar sin usuario ni contraseña, enviando peticiones a la web.

«Ejecución remota de código» quiere decir que quien lo consiga puede ejecutar su propio código en tu servidor: instalar una puerta trasera, leer la base de datos con tus clientes o meter un script que copie las tarjetas en el pago. Por eso el aviso oficial no da rodeos: la única solución completa es actualizar PHP.

¿A quién afecta?

A cualquier instalación de PHP que atienda peticiones web, con independencia de lo que tengas instalado encima:

• WordPress y WooCommerce, PrestaShop, Joomla, Drupal y Magento: todos funcionan con PHP.
• Webs a medida en PHP (Laravel, Symfony, CodeIgniter o código propio).
• Todas las formas de ejecutar PHP en el servidor: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto lo tiene Apache con mod_php, porque el fallo puede activarse antes de que llegue a ejecutarse el código de tu web; con PHP-FPM o LiteSpeed el riesgo es menor, pero también hay que actualizar.

No te afecta directamente si tu tienda está en una plataforma alojada como Shopify o Wix: ahí no gestionas PHP y el servidor es cosa del proveedor.

Versiones afectadas y versiones corregidas

Cómo saber qué versión de PHP tiene tu web

1. En el panel del hosting. Busca «Versión de PHP», «Seleccionar versión de PHP» o «MultiPHP Manager» (cPanel) o «Configuración de PHP» (Plesk). Ahí ves la rama y, a veces, la versión completa.
2. Desde tu web. En WordPress: Herramientas → Salud del sitio → Información → Servidor. En PrestaShop: Parámetros avanzados → Información. En Joomla: Sistema → Información del sistema. En Drupal: Informes → Informe de estado.
3. Con el análisis gratuito. Si tu servidor anuncia la versión de PHP en sus cabeceras, el análisis gratuito la lee y te dice si está afectada. Si la tiene oculta (que es lo recomendable), te dirá que desde fuera no se puede comprobar.
4. Con el conector de solo lectura. El conector lee la versión exacta desde dentro, sin depender de lo que anuncie el servidor, y también cómo se ejecuta PHP (mod_php o FPM).

Hay quien sube un archivo phpinfo() para verlo. Funciona, pero muestra mucha información interna del servidor: si lo haces, bórralo en cuanto hayas mirado la versión.

Qué hacer hoy

1. Actualiza PHP a la versión corregida de tu rama o a una rama superior. En muchos hostings eliges la rama en el panel y el proveedor instala las correcciones dentro de cada rama; si no ves la versión exacta, pregúntale si ya tiene 8.5.12, 8.4.27, 8.3.36 u 8.2.35.
2. Comprueba la versión después, por cualquiera de las vías de arriba. Si el panel la cambió pero el servidor sigue usando procesos antiguos, la versión no cambia hasta que se reinician.
3. Prueba la web como lo haría un cliente: portada, formularios y, si es una tienda, una compra completa hasta el pago.
4. Si tu web no puede funcionar con un PHP más nuevo (o tu hosting no te lo ofrece), sigue el plan por capas del apartado siguiente y fija una fecha para actualizar.

Actualización del 23 de octubre: CVE-2026-115560

Dos días después, PHP publicó otro aviso: CVE-2026-115560, un fallo en el seguimiento de subidas de las sesiones (session.upload_progress). Es muy distinto de PHP2Shell: PHP lo considera poco probable, porque solo afecta a aplicaciones que cambian session.serialize_handler a php mientras se ejecutan, algo poco habitual. Todavía no tiene versión corregida y las actualizaciones de PHP2Shell no lo arreglan.

Qué hacer: deja session.upload_progress.enabled = 0 en la configuración del servidor, aunque ya hayas actualizado PHP. Es la misma medida del apartado siguiente, así que si ya la aplicaste no tienes que hacer nada más; solo no la quites al actualizar. Actualizaré esta guía cuando salga la versión que lo corrige.

Si no puedes actualizar PHP (PrestaShop antiguo, módulos o plugins incompatibles…)

Es la situación de muchas tiendas y webs que reviso: un PrestaShop 1.6 o 1.7 con módulos o un tema que no funcionan con un PHP más nuevo, un WordPress con plugins antiguos, código a medida o un hosting que no ofrece otra versión. Actualizar sigue siendo la única solución completa, y para PHP 8.1 y anteriores no hay versión oficial corregida. Pero entre «actualizar hoy» y «no hacer nada» hay un plan por capas que reduce el riesgo mientras preparas la migración. En este orden:

1. Pregunta a tu hosting si su PHP ya lleva el parche

php.net menciona parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1, y que algunas distribuciones de Linux y proveedores de soporte extendido publican sus propios parches (lo que se llama «backport»): la misma versión de PHP con la corrección aplicada. Como el número de versión no cambia, desde fuera no se ve: hay que preguntarlo.

• Qué preguntar: si el PHP de tu web incluye el parche de CVE-2026-109618 y CVE-2026-109619, en qué paquete y versión exacta, y dónde lo puedes ver.
• Cómo lo deben confirmar: con el registro de cambios del paquete o el aviso de seguridad de la distribución o del proveedor, donde aparezcan los dos CVE. Un «estamos protegidos» sin más no basta.
• De dónde suele salir el parche: de las actualizaciones de seguridad de la distribución (Debian, Ubuntu o la familia de Red Hat), de los proveedores de PHP con soporte extendido que usan muchos hostings o, en un VPS propio, de compilar PHP con los parches que menciona php.net. Pregunta si es tu caso: no doy por hecho que ningún proveedor lo haya hecho ya.

2. Medidas temporales en la configuración del servidor

Las publican php.net y el aviso del repositorio oficial de PHP para las instalaciones que no pueden actualizar. Van en el pool de PHP-FPM, en la configuración de Apache o en el php.ini principal, nunca en tu web:

• Fijar memory_limit=-1 con php_admin_value, para que ninguna aplicación pueda cambiarlo. Es la medida principal, pero tiene un coste: un script desbocado puede comerse la memoria del servidor, así que hay que acompañarla de un límite de memoria del servicio o del contenedor (cgroup) y de límites de tamaño de petición en el servidor web.
• Reducir post_max_size a 8M si la web no recibe subidas de archivos, o a 32M si las recibe, con upload_max_filesize por debajo, y limitar también el tamaño de las peticiones en nginx o Apache.
• Bajar max_input_nesting_level y acotar max_input_vars y max_file_uploads.
• Desactivar session.upload_progress.enabled (ponerlo a 0). En PHP 8.5, además, fatal_error_backtraces=0.
• Si la web no usa formularios con subida de archivos, bloquear esas peticiones en el servidor web antes de que lleguen a PHP. Cuidado: el panel de PrestaShop y el de WordPress sí suben imágenes así; hay que probarlo antes.
• Reiniciar todos los procesos de PHP y comprobar, pool por pool, que ningún ajuste vuelve a poner un límite en memory_limit. El aviso desaconseja usar RLIMIT_AS o RLIMIT_DATA como sustituto.

; En el pool de PHP-FPM de la web (nunca en .user.ini)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 16M
php_admin_flag[session.upload_progress.enabled] = off

En un hosting compartido no puedes tocar esa configuración: se la tienes que pedir al proveedor. En un VPS o servidor propio lo hace quien lo administre. El paquete de remediación del informe incluye el correo para el hosting, la configuración para PHP-FPM, Apache y nginx, y cómo comprobar que se ha aplicado.

3. Un cortafuegos por delante

Un WAF o una CDN con cortafuegos delante de la web filtra parte de las peticiones anómalas. La CISA lo considera solo una protección parcial: suma como capa, no sustituye al parche.

4. Vigilancia diaria para enterarte pronto

Si algo se cuela, cuanto antes lo veas, menos daño. La CISA recomienda vigilar los procesos de PHP que lanzan comandos del sistema o descargan herramientas; eso lo ve el hosting en sus registros. Por tu parte:

• Una comprobación diaria de cambios en los archivos, con aviso si aparece algo nuevo: es lo que hacen el conector y el mantenimiento.
• Atención a archivos .php nuevos en carpetas de subidas o de imágenes, administradores que nadie creó y tareas programadas nuevas.
• Una copia de seguridad diaria guardada fuera del servidor.

5. Un plan de migración con fechas

Las medidas anteriores compran tiempo; la salida es poder usar un PHP con soporte. Ponle fecha a cada paso (probar en una copia, actualizar la web, cambiar PHP y verificar), porque la versión de tu web manda:

• PrestaShop 1.7 funciona como mucho con PHP 7.4, y PrestaShop 8 hasta PHP 8.1. Para usar un PHP con soporte hay que pasar a PrestaShop 9, que funciona con PHP 8.1 a 8.4 (8.5 desde 9.1). Lo explico en actualizar PrestaShop y en ¿es seguro PrestaShop 1.7?. Si para ese salto pasas por PHP 8.1, que sea un paso de pruebas de unas horas, no el destino.
• WordPress funciona con PHP 8.3 desde la versión 6.4 y con 8.4 desde la 6.7. El núcleo suele ir bien; lo que falla son plugins y temas antiguos que nadie ha actualizado en años.
• Webs a medida y módulos muy antiguos pueden usar funciones que PHP ha retirado: hay que probarlas en una copia antes de cambiar.

El esfuerzo varía mucho: en un WordPress con plugins al día pueden ser unas horas; en un PrestaShop 1.6 o 1.7 con tema y módulos a medida, días o semanas. La CISA recomienda, si no se puede parchear una web con PHP 8.1 o anterior, valorar desconectarla hasta actualizarla. Para una tienda que vende cada día no siempre es viable, así que las fechas del plan tienen que ser cortas.

Es justo el tipo de trabajo que hago: compruebo tu versión, pido el parche a tu hosting, aplico o gestiono con él las medidas temporales en el servidor, dejo la vigilancia diaria en marcha y te preparo el plan de migración con fechas.

Lo que no basta

• Un .user.ini o un ini_set() en el código. Las medidas tienen que estar fijadas por el servidor y con los procesos reiniciados; por carpeta o desde la aplicación no sirven.
• Un plugin de seguridad de WordPress o un módulo de PrestaShop. El fallo está en PHP, por debajo de tu web; con mod_php puede activarse antes de que el plugin llegue a ejecutarse.
• Un cortafuegos de aplicación (WAF). La CISA lo considera solo una protección parcial: ayuda, pero no sustituye a la actualización.
• Cambiar contraseñas. Siempre es buena idea, pero este fallo no necesita ninguna.

¿Y si ya me han atacado?

Actualizar PHP cierra la puerta, pero no echa a quien ya hubiera entrado. Revisa estas señales, sobre todo si tu web estuvo días con una versión afectada:

• Archivos .php que no reconoces, en la raíz o en carpetas de subidas e imágenes.
• Administradores o empleados que nadie ha creado.
• Tareas programadas nuevas en el panel del hosting.
• Conexiones del servidor hacia dominios desconocidos, o procesos de PHP que lanzan comandos del sistema (la CISA recomienda vigilar precisamente eso; tu hosting puede verlo en sus registros).

Tienes la lista completa en cómo saber si mi web está hackeada. Si encuentras algo, no actualices encima ni borres a ciegas: los pasos están en recuperar una web hackeada.

Cómo te puedo ayudar

Empieza por el análisis gratuito: en unos minutos sabrás si tu servidor anuncia una versión afectada. Si quieres que lo resuelva yo, la puesta a punto (299 € para una web corporativa; tiendas, en la página de precios) incluye el informe de seguridad completo con el conector, la corrección de lo urgente (hasta 3 horas: actualizar PHP o, si la web no lo admite, pedir el parche a tu hosting y aplicar o gestionar con él las medidas temporales, y comprobar la compatibilidad) y un nuevo análisis para verificarlo. Si la web necesita un salto de versión de PrestaShop o WordPress para poder subir PHP, te dejo el plan de migración con fechas y te lo presupuesto aparte, con precio cerrado. Precios IVA no incluido.

Fuentes

• php.net: aviso del 21 de octubre de 2026 «Critical remote code execution vulnerabilities, update now» (versiones corregidas, ramas sin versión oficial, parches en código fuente y medidas temporales).
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), avisos del repositorio oficial de PHP (incluidas las medidas para instalaciones que no pueden actualizar).
• NVD: CVE-2026-109618 y NVD: CVE-2026-109619.
• Aviso de PHP del 23 de octubre de 2026 sobre CVE-2026-115560 (session upload progress), recogido por The Hacker News y Security Affairs.
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 de octubre de 2026).