PHP2Shell: vulnerabilidad crítica en PHP y cómo actualizar

El 21 de octubre de 2026, el equipo de PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas que permiten ejecutar código en el servidor sin autenticarse. Se las conoce como PHP2Shell. Si tu web, tu tienda online o tu aplicación funciona con PHP, como todas las hechas con WordPress, Drupal o Joomla, tienes que comprobarlo. Te cuento qué ha pasado, qué versiones están corregidas, cómo comprobar la tuya y qué hacer si hoy no puedes actualizar.

Qué es PHP2Shell y qué ha pasado

El 20 de octubre, PHP avisó en su web de que al día siguiente, a las 14:00 UTC, saldría una actualización de seguridad para dos vulnerabilidades críticas. El 21 publicó las versiones corregidas y los detalles. Son estas:

CVE-2026-109618, «RCE via OOM corruption» (aviso GHSA-w8hw-w9fx-j79w). Cuando PHP se queda sin memoria a mitad de una petición, puede dejar datos internos a medio preparar, y la limpieza del final de la petición los trata como buenos.
CVE-2026-109619, «RCE via stale global state» (aviso GHSA-6wmf-4rv5-p3rp). Parte del estado interno de una petición sobrevive después de liberarse su memoria, y una petición posterior que atiende el mismo proceso puede usarlo antes de que se reinicie.

En los dos casos, el resultado es el mismo: alguien sin usuario ni contraseña puede ejecutar código en tu servidor con los permisos con los que funciona la web. Según PHP, están en riesgo todas las instalaciones que sirven páginas: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto lo ve en mod_php, donde hay un ataque demostrado: una petición sin autenticar puede desencadenarlo antes de que se ejecute nada de la aplicación.

El nombre, PHP2Shell, viene de Wiz, una de las empresas que las descubrieron: php2shell es su exploit, el programa que junta los fallos para atacar un servidor. En los avisos oficiales se llaman por lo que hacen: ejecución remota de código por corrupción al quedarse sin memoria y por estado global obsoleto.

¿Un 10 sobre 10? La puntuación oficial

Habrás leído que es un fallo de 10 sobre 10. Ninguna fuente oficial lo dice:

PHP, que es quien registra los dos CVE, les da un 9,2 en CVSS 4.0.
El NVD, la base de datos de vulnerabilidades del Gobierno de Estados Unidos, les da un 9,8 en CVSS 3.1.

Son dos escalas distintas, y en las dos la gravedad es «crítica», la más alta. Para ti no cambia nada: hay que actualizar ya.

Versiones vulnerables y versiones corregidas

Esto dicen el aviso de PHP y el registro de los dos CVE, rama por rama:

PHP 8.5: vulnerable hasta la 8.5.11. Corregida en la 8.5.12.
PHP 8.4: vulnerable hasta la 8.4.26. Corregida en la 8.4.27.
PHP 8.3: vulnerable hasta la 8.3.35. Corregida en la 8.3.36.
PHP 8.2: vulnerable hasta la 8.2.34. Corregida en la 8.2.35.
PHP 8.1, 8.0, 7.4 y anteriores: sin versión corregida, porque ya no tienen soporte. El NVD da por vulnerable cualquier versión anterior a la 8.2.35. Por la gravedad, PHP ha publicado unos parches mínimos de código para la 7.4, la 8.0 y la 8.1, pensados para quien compila PHP por su cuenta, y algunas distribuciones y proveedores de soporte extendido tienen los suyos.

Si tu web sigue en PHP 8.1 o anterior, este es el momento de pasarla a una versión con soporte. Y ojo con la 8.2: PHP recuerda que deja de recibir parches de seguridad el 31 de diciembre de 2026.

Lo que he hecho por mis clientes

He trabajado de urgencia junto a mis proveedores de servicio para actualizar todos los servidores, contenedores y servicios de mis clientes a las versiones corregidas. Esta misma web ya funciona con una versión corregida.

Por qué compensa tener a alguien pendiente

Un fallo así no da semanas de margen: PHP lo anunció un día y lo publicó al siguiente. Quien tiene un servicio de mantenimiento informático no tiene que enterarse por las noticias ni buscar a alguien con urgencia: su proveedor ya lo sigue, sabe qué versión tiene cada servidor y actualiza en cuanto sale el parche. Lo que recibe es el aviso de que está hecho. Contar con una empresa proactiva es lo que te quita estos quebraderos de cabeza.

Si no sabes qué versión de PHP tiene tu web ni quién se encarga de actualizarla, escríbeme y lo miramos.

Cómo saber qué versión de PHP tienes

En la consola del servidor: php -v te dice la versión del PHP de la línea de órdenes. Ojo: en un mismo servidor puede haber varias versiones instaladas, y la de la consola no tiene por qué ser la que sirve la web. Si la web va con PHP-FPM, pregunta también a su ejecutable (por ejemplo, php-fpm8.4 -v en Debian y Ubuntu).
En el panel del alojamiento (cPanel, Plesk, DirectAdmin…): en la configuración de PHP de cada dominio aparece la versión que usa.
En WordPress: en Herramientas, Salud del sitio, pestaña Información, apartado Servidor.

Si PHP viene de los paquetes de tu distribución de Linux, el número puede no coincidir con los de esta lista: Debian y Ubuntu, por ejemplo, suelen aplicar el parche sin cambiar la versión de PHP, solo la del paquete. En ese caso, lo que cuenta es el aviso de seguridad de tu distribución. Según PHP, las distribuciones recibieron los parches por adelantado.

Cómo actualizar PHP

Alojamiento compartido: PHP lo actualiza tu proveedor. Comprueba en el panel que ya tienes la versión corregida y, si no, pregúntale cuándo.
Servidor propio o VPS: actualiza los paquetes de PHP con el gestor de tu sistema. Si usas el repositorio de Remi (rpms.remirepo.net), PHP avisó de que el 21 de octubre no tendría las actualizaciones y recomienda pasar a los paquetes de la distribución o compilar.
Contenedores: descarga la imagen base nueva (por ejemplo, la oficial php:8.4-fpm), reconstruye la tuya y vuelve a crear los contenedores. Reiniciar un contenedor no cambia su imagen. Después, comprueba con php -v dentro del contenedor que lleva la versión corregida.
Windows: los binarios corregidos están en la página de descargas de PHP.

Y en todos los casos, reinicia el servicio: PHP-FPM, Apache con mod_php o LiteSpeed. Mientras siga vivo un proceso arrancado antes de actualizar, sigue en memoria el PHP vulnerable.

Si no puedes actualizar hoy: cómo reducir el riesgo

PHP lo deja claro: solo la actualización lo soluciona del todo. Estas medidas, las que da su aviso, cierran caminos de ataque concretos, pero no dejan la instalación a salvo.

Para CVE-2026-109618 (falta de memoria)

memory_limit=-1, puesto de forma que las aplicaciones no puedan cambiarlo, como php_admin_value en el pool de PHP-FPM o en la configuración de Apache. Comprueba que ningún pool, directorio o aplicación vuelve a poner un límite. A cambio, un proceso puede comerse la memoria del servidor: por eso PHP propone poner el límite en el contenedor o en el cgroup, nunca con RLIMIT_AS ni RLIMIT_DATA, que provocan justo el fallo vulnerable.
post_max_size bajo: 8M si la aplicación no recibe ficheros, 32M si los recibe, con upload_max_filesize por debajo. Mejor aún, limita también el tamaño y la complejidad de las peticiones en el servidor web o el proxy.

Para CVE-2026-109619 (estado obsoleto)

session.upload_progress.enabled=0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor, y reinicia todos los procesos. No vale con ini_set() ni con un .user.ini: se aplican demasiado tarde. Si no usas esa función, PHP ve prudente dejarla desactivada aunque actualices.
En PHP 8.5, fatal_error_backtraces=0, también con un reinicio de todos los procesos.
Quita los ajustes no válidos u obsoletos que se aplican en cada petición: ocultar los avisos con error_reporting, display_errors o @ no protege.
Corrige los errores fatales y los tiempos agotados que pueda provocar un atacante, también en las subidas, las importaciones y las tareas de limpieza.

Desconfía de las recetas que circulan estos días: alguna recomienda justo lo que el aviso oficial dice que no sirve.

Sigue el aviso oficial de PHP

Lo más fiable es ir a la fuente. Entra en el archivo de noticias de PHP (se abre en una pestaña nueva) y haz el seguimiento allí: verás el aviso previo del 20 de octubre y, justo encima, el aviso de seguridad con las versiones corregidas y las medidas, que es donde PHP publicará cualquier novedad. Los detalles técnicos de cada fallo están en sus avisos de GitHub, enlazados en las fuentes.

PHP2Shell: la vulnerabilidad crítica de PHP, qué versiones la corrigen y cómo actualizar