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

> PHP2Shell (CVE-2026-109618 y CVE-2026-109619): versiones afectadas, cómo comprobar la tuya y qué hacer si no puedes actualizar PHP en una web antigua.

URL: https://webintacta.com/guias/php2shell-vulnerabilidad-php
Última actualización: 2026-10-23

**En resumen:** Tu web está afectada si funciona con PHP (WordPress, PrestaShop, WooCommerce, Joomla, Drupal o Magento) y su versión es anterior a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 según la rama, o si sigue en PHP 8.1 o anterior, que no tiene versión oficial corregida. PHP2Shell son dos fallos críticos publicados el 21 de octubre de 2026 (CVE-2026-109618 y CVE-2026-109619, CVSS 9,2) que permiten ejecutar código en el servidor sin contraseña. Lo que hay que hacer hoy es actualizar PHP desde el panel del hosting o pedírselo a tu proveedor; si tu web no funciona con un PHP más nuevo, pide al hosting una versión con el parche (backport), aplica las medidas temporales en el servidor y planifica la migración con fecha.


Por Jose Soriano (WebIntacta) · publicada el 2026-10-22

El 21 de octubre de 2026 el equipo de PHP publicó un aviso con un titular poco habitual: fallos críticos de ejecución remota de código, actualiza ya. Como casi todas las webs de pymes y tiendas que reviso funcionan con PHP, esta guía va al grano: si te afecta, cómo saber qué versión tienes, a cuál actualizar y qué hacer si tu web no puede funcionar con un PHP más nuevo, algo muy habitual en tiendas PrestaShop antiguas. No explico cómo se aprovecha el fallo: para protegerte no hace falta.

## 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.

> Al publicarse, la CISA (la agencia de ciberseguridad de Estados Unidos) no había observado ataques reales aprovechando estos fallos. Eso puede cambiar en cuanto hay tantas webs sin actualizar, así que no conviene esperar, pero tampoco hay motivo para el pánico: para la mayoría de webs es una actualización de mantenimiento, y para las que no pueden actualizar hay un plan por capas más abajo.

## ¿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

| Rama de PHP | Corregido en | Qué hacer |
| --- | --- | --- |
| 8.5 | 8.5.12 | Actualizar a 8.5.12 o superior |
| 8.4 | 8.4.27 | Actualizar a 8.4.27 o superior |
| 8.3 | 8.3.36 | Actualizar a 8.3.36 o superior |
| 8.2 | 8.2.35 | Actualizar a 8.2.35 o superior, y planificar el cambio de rama: 8.2 deja de tener soporte el 31 de diciembre de 2026 |
| 8.1, 8.0 y 7.x | Sin versión oficial | Pasar a una rama con soporte (8.3 o superior). PHP solo ha publicado parches mínimos en código fuente para 7.4, 8.0 y 8.1; algunas distribuciones de Linux y proveedores de soporte extendido publican sus propios parches. Si la web no admite un PHP más nuevo, sigue el plan de abajo |

Según el aviso de php.net del 21 de octubre de 2026 y los avisos GHSA del repositorio oficial de PHP.

> Si tu versión aparece con un añadido detrás, como `8.1.2-1ubuntu2.20` o `8.2.28-1~deb12u1`, es un paquete de una distribución de Linux. Esas distribuciones a veces corrigen el fallo sin cambiar el número principal, así que la versión **probablemente** está afectada, pero solo tu proveedor puede confirmar si ya aplicó su parche. Pídeselo por escrito.

## 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](https://webintacta.com/analisis-seguridad-web-gratis) 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](https://webintacta.com/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:

> Todo lo de este apartado es **temporal y no es una solución completa**. Sirve para ganar tiempo con el riesgo acotado, no para quedarse así.

### 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](https://webintacta.com/conector) y el [mantenimiento](https://webintacta.com/mantenimiento-web).
- 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](https://webintacta.com/guias/actualizar-prestashop) y en [¿es seguro PrestaShop 1.7?](https://webintacta.com/guias/prestashop-1-7-es-seguro). 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](https://webintacta.com/guias/como-saber-si-mi-web-esta-hackeada). Si encuentras algo, no actualices encima ni borres a ciegas: los pasos están en [recuperar una web hackeada](https://webintacta.com/guias/recuperar-web-hackeada).

## Cómo te puedo ayudar

Empieza por el [análisis gratuito](https://webintacta.com/analisis-seguridad-web-gratis): en unos minutos sabrás si tu servidor anuncia una versión afectada. Si quieres que lo resuelva yo, la [puesta a punto](https://webintacta.com/precios#packs) (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](https://www.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)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) y [GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), avisos del repositorio oficial de PHP (incluidas las medidas para instalaciones que no pueden actualizar).
- [NVD: CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) y [NVD: CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619).
- Aviso de PHP del 23 de octubre de 2026 sobre CVE-2026-115560 (session upload progress), recogido por [The Hacker News](https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html) y [Security Affairs](https://securityaffairs.com/201595/security/php-warns-of-new-code-execution-flaw-days-after-php2shell-patches.html).
- [CISA: Critical Vulnerabilities in PHP Require Immediate Patching](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) (21 de octubre de 2026).

## Preguntas frecuentes

### ¿Mi hosting compartido lo actualiza solo?

Depende del proveedor. En muchos, tú eliges la rama de PHP (8.2, 8.3…) y el hosting instala las correcciones dentro de cada rama, pero no siempre el mismo día, y nunca te cambia de rama sin avisar. Compruébalo tú con la versión exacta o pregúntaselo por escrito.

### ¿Y si tengo el hosting en IONOS, Hostinger u otra empresa grande?

El tamaño del proveedor no cambia lo que tienes que hacer: comprobar la versión exacta de PHP de tu web y, si es anterior a la corregida de su rama, actualizarla desde el panel o pedirlo a soporte. Cada proveedor publica sus actualizaciones a su ritmo; no doy por hecho el estado de ninguno.

### ¿Cómo sé si ya me han atacado?

Busca archivos PHP que no reconoces, administradores nuevos, tareas programadas extrañas y conexiones del servidor hacia dominios desconocidos. El [análisis gratuito](https://webintacta.com/analisis-seguridad-web-gratis) revisa lo visible desde fuera y el [conector](https://webintacta.com/conector), los archivos y los administradores desde dentro.

### Mi PrestaShop no funciona con PHP 8.2, ¿qué hago?

Es lo habitual: PrestaShop 1.7 funciona como mucho con PHP 7.4 y PrestaShop 8 hasta 8.1, y para usar un PHP con soporte hay que pasar a PrestaShop 9. Mientras preparas ese salto, pide a tu hosting que confirme por escrito si su PHP incluye el parche (backport) de CVE-2026-109618 y CVE-2026-109619, que aplique las medidas temporales en la configuración del servidor, vigila los archivos a diario y pon fecha a la migración. Es el plan del apartado «Si no puedes actualizar PHP».

### ¿Sirven los ajustes en .user.ini o un plugin de seguridad?

No. Las medidas temporales tienen que fijarse en la configuración del servidor (php.ini, pool de PHP-FPM o Apache) y reiniciar los procesos de PHP; un .user.ini o un ini_set() no bastan. Y un plugin de seguridad de WordPress o un módulo de PrestaShop funciona por encima de PHP: con mod_php, el fallo puede activarse antes de que llegue a ejecutarse.

### ¿Me protege el cortafuegos del hosting?

Solo en parte. La CISA considera el WAF una protección parcial: es una capa más, junto al parche del hosting y las medidas en el servidor, pero lo que corrige el fallo es actualizar PHP o usar un PHP con el parche aplicado.

## Sobre el autor

[Jose Soriano](https://webintacta.com/quien-soy): Desarrollador fullstack especializado en PrestaShop, WordPress y WooCommerce, con el curso y el examen oficiales de PrestaShop aprobados. Desarrolla tiendas online y módulos desde 2023 y es el fundador de WebIntacta, el servicio de seguridad web con el que analiza, limpia y mantiene él mismo webs de pymes y tiendas online, en remoto desde Ibi (Alicante). Datos de WebIntacta: https://webintacta.com/quien-soy#datos