En resumen: La vulnerabilidad de PHP PHP2Shell afecta a las ramas 8.2 a 8.5 hasta las versiones del 21 de octubre de 2026 y, según la prensa especializada, a casi todas las versiones hasta PHP 5.4. Está corregida en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales, sino solo backports mínimos de código fuente para 7.4, 8.0 y 8.1.
¿Qué versiones ha afectado la vulnerabilidad de PHP?
PHP2Shell abarca las dos vulnerabilidades CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS v4.0 de 9.2. Las dos permiten ejecutar código malicioso de forma remota sin autenticación. El 21 de octubre de 2026 a las 14:00 UTC (16:00 hora alemana), el proyecto PHP publicó correcciones para todas las ramas con soporte.
| Rama de PHP | Último estado antes de la corrección | Corregido desde | Soporte |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | con soporte oficial |
| 8.4 | 8.4.26 | 8.4.27 | con soporte oficial |
| 8.3 | 8.3.35 | 8.3.36 | con soporte oficial |
| 8.2 | 8.2.34 | 8.2.35 | termina el 31/12/2026 |
| 8.1, 8.0, 7.4 | todos los estados | sin versión oficial | solo backports mínimos de código fuente |
| 7.3 a 5.4 | según la prensa especializada, casi todas afectadas | sin actualización | sin soporte desde hace años |
Los datos sobre 8.2 a 8.5 proceden de los avisos de php.net. La afirmación sobre las versiones hasta PHP 5.4 procede de la prensa especializada; no existe una lista oficial completa para las versiones antiguas.
Para quienes no son técnicos, en pocas frases: si en su servidor figura una versión de la columna «Corregido desde» o superior y después se han reiniciado todos los procesos de PHP, PHP2Shell está cerrada. Si aparece un número anterior, o hay un backport de por medio que su proveedor debe confirmar, o la vulnerabilidad está abierta. En caso de duda, pregunte a su departamento de TI o a su proveedor de hosting exactamente por estos tres puntos: versión, backport, reinicio.
Modos de ejecución afectados
El número de versión es solo media respuesta. Están afectadas todas las formas habituales de operar PHP en un servidor web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera que el riesgo es mayor en mod_php, porque allí se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Los detalles figuran en Por qué mod_php soporta el mayor riesgo.
La aplicación no ofrece ninguna protección: ya sea WordPress, Shopware, TYPO3, Laravel o un desarrollo propio, una actualización de la aplicación no cierra la vulnerabilidad de PHP.
Backports: cuando el número de versión engaña
Muchas distribuciones de Linux y proveedores de hosting entregan PHP en paquetes propios. En lugar de saltar a una versión nueva de origen, incorporan la corrección como backport en su versión existente. Esto tiene una consecuencia práctica: el número mostrado sigue siendo antiguo. Un ejemplo de la situación actual es Plesk, que puede seguir mostrando 8.2.34 aunque el fallo esté corregido.
Para usted significa: la tabla anterior vale para las versiones oficiales de php.net. En los paquetes de su distribución o del proveedor de hosting deciden el estado del paquete y la confirmación del proveedor. Cómo comprobar ambas cosas se muestra en Comprobar correctamente la versión de PHP y el estado del parche. Para la prueba rápida en la línea de comandos:
php -v
apt policy php8.3-fpm # Debian/Ubuntu, el nombre del paquete varía según la versión y la fuente
dnf info php-fpm # familia RHEL
Que haya un número de versión corregido en el disco no significa todavía que esté en ejecución. Solo tras reiniciar todos los procesos de PHP trabaja el servidor con el código corregido.
¿Qué ocurre con PHP 8.1 y anteriores?
Para PHP 8.1, 8.0 y 7.4 solo hay backports mínimos de código fuente, es decir, correcciones en el código fuente que alguien debe adoptar y compilar por sí mismo. No aparecen versiones oficiales. Algunas distribuciones con mantenimiento a largo plazo incorporan esas correcciones en sus paquetes; si esto se aplica a su sistema, solo puede aclararse mediante el changelog del paquete o con el proveedor.
A largo plazo no hay forma de evitar una versión con soporte. Qué versión de PHP admite su CMS o su tienda, compruébelo según los requisitos del sistema del fabricante, por ejemplo en wordpress.org, shopware.com o typo3.org. Más información en PHP 8.1 y anteriores: qué rige ahora.
¿Y CVE-2026-115560?
El 23 de octubre, php.net publicó un aviso sobre una tercera vulnerabilidad. Solo actúa con una configuración de sesión poco habitual. Según el estado del 25 de octubre, todavía no hay una versión corregida; hasta la próxima versión ordinaria de corrección de errores, la solución es session.upload_progress.enabled=0. Una lista de versiones se espera solo con el aviso completo.
¿Cómo ayuda PHP SOS en concreto?
- Inventario: registramos todas las versiones de PHP de sus servidores, también las segundas instalaciones para sitios web concretos, que se pasan por alto con facilidad.
- Contraste: para cada instalación aclaramos si existe una versión oficial, un backport de la distribución o ninguna corrección.
- Actualización con justificante: con el servicio de parcheo de PHP instalamos la corrección y reiniciamos todos los procesos.
- Plan de migración: para versiones sin actualizaciones oficiales, planificamos el paso con la migración de PHP 8.1 y anteriores y protegemos el servidor hasta entonces.
Preguntas frecuentes
¿Es seguro todavía PHP 8.3.35?
No, salvo que su proveedor haya incorporado un backport. 8.3.35 es el último estado antes de la corrección; PHP2Shell está corregida en la rama 8.3 desde 8.3.36. En los paquetes de distribuciones el número puede seguir igual aunque el fallo esté corregido. Entonces cuenta el changelog del paquete o la confirmación del proveedor.
¿Está PHP 7.4 afectado por PHP2Shell?
Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4. Para 7.4, 8.0 y 8.1 solo hay backports mínimos de código fuente y ninguna versión oficial. Pasar a una versión con soporte es el camino fiable.
¿Por qué muestra Plesk 8.2.34 aunque se haya parcheado?
Las distribuciones y los proveedores de hosting incorporan en ocasiones las correcciones como backport en sus paquetes existentes. Entonces el número de versión sigue igual y el fallo está corregido igualmente. Compruebe el estado del paquete o pida al proveedor que le confirme el parche.
¿Qué versión de PHP debería elegir ahora?
Una versión con soporte que su aplicación autorice según los requisitos del sistema del fabricante. PHP 8.2 llega el 31/12/2026 al fin del soporte; quien cambie ahora de todos modos debería tenerlo en cuenta.