CiberseguridadPHPWordPress

PHP2Shell: las dos vulnerabilidades críticas de PHP, ya explotadas, y qué hacer hoy

Por Abant SistemasPublicado el 21 de octubre de 2026Actualizado el 30 de octubre de 2026

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades críticas en el propio PHP, el lenguaje con el que funcionan WordPress, PrestaShop, Drupal, Magento, Laravel y buena parte de las webs de empresa. Están registradas como CVE-2026-109618 y CVE-2026-109619 y permiten a un atacante, sin usuario ni contraseña, ejecutar su propio código en el servidor que aloja la web. El 21 de octubre de 2026 el equipo de PHP publicó versiones corregidas de urgencia. La única solución completa es actualizar PHP, y conviene hacerlo hoy.

Actualizar WordPress o sus plugins no corrige PHP2Shell. El fallo está en PHP, la capa que hay debajo, y lo actualiza quien administra el servidor: su proveedor de hosting o usted, si el servidor es suyo.

Actualización del 25 de octubre: los ataques empezaron antes del aviso oficial (el primer intento registrado es del 17 de octubre) y desde el 21 se explota de forma generalizada. Si su web corre sobre PHP 7.4, 8.0 u 8.1, no hay versión oficial corregida: vea el apartado específico más abajo.

Actualización del 28 de octubre: ya hay ataques confirmados que consiguen ejecutar código, no solo intentos, y la agencia de ciberseguridad de Estados Unidos (CISA) ha incluido PHP2Shell en su catálogo de vulnerabilidades explotadas. Además, PHP ha avisado de un tercer fallo, CVE-2026-115560, todavía sin parche: la misma medida temporal que ya recomendábamos lo bloquea.

Actualización del 30 de octubre: Synology ha confirmado que PHP2Shell afecta a varios paquetes de sus NAS, entre ellos Synology Calendar, Mail Station y los paquetes de PHP que se instalan desde el Centro de paquetes. Ya hay versiones corregidas, salvo para PHP 7.3. Lo explicamos en el apartado de NAS Synology.

Qué ha pasado

El 20 de octubre el proyecto PHP anunció una actualización de seguridad para dos fallos que calificó como críticos, con una puntuación de 9,2 sobre 10 en la escala CVSS 4.0. Los identificadores y parte de los detalles empezaron a circular antes de tiempo, y las versiones corregidas se publicaron el 21 de octubre.

Ese mismo día Cloudflare informó de que ya veía los primeros ataques contra sus clientes, y circulan en GitHub supuestos exploits que nadie ha verificado de forma independiente. Varias administraciones europeas, entre ellas las de Países Bajos, Finlandia, Dinamarca y Francia, desconectaron algunas webs públicas de forma preventiva mientras las actualizaban. Según W3Techs, PHP está detrás de cerca del 70 % de las webs cuyo lenguaje de servidor se conoce, de ahí el revuelo.

Qué ha cambiado desde el 21 de octubre

Primeros ataques con éxito confirmados. Hasta el 25 de octubre, las firmas de seguridad hablaban de intentos masivos que no llegaban a funcionar. El fin de semana del 25 y 26 de octubre, un investigador de Perplexity confirmó una ejecución remota de código real en un señuelo con Apache y mod_php sobre PHP 8.4.26, la versión inmediatamente anterior a la corregida. Es decir: los atacantes ya tienen un exploit que funciona.
CISA lo declara explotado. El 26 de octubre, CISA añadió las dos vulnerabilidades a su catálogo de fallos explotados activamente (KEV) y dio de plazo a las agencias federales hasta el jueves 29 para corregirlas. Ese catálogo es la referencia que usa medio mundo para decidir qué parchear primero.
Un tercer fallo, todavía sin parche. El 23 de octubre, PHP publicó un aviso sobre CVE-2026-115560, otra posible ejecución remota de código relacionada con el progreso de subida de ficheros en las sesiones. Sólo se da con una combinación poco habitual de configuración y código, no hay explotación conocida y se corregirá en la próxima versión ordinaria de PHP. Mientras tanto, la medida es la misma que ya recomendábamos para CVE-2026-109619: desactivar session.upload_progress.enabled. Si ya lo hizo, está cubierto.
Se explotaba antes de conocerse. Amazon detectó en sus señuelos un primer intento de ataque el 17 de octubre, cuatro días antes del aviso oficial, y más intentos de varios atacantes distintos en las horas previas a la publicación del parche. Por eso, la fecha a partir de la cual hay que revisar es el 17 de octubre, no el 21.
Ataques masivos y automatizados. Varias firmas de seguridad, entre ellas Amazon, watchTowr y VulnCheck, confirman explotación activa desde el 21 de octubre. VulnCheck ha registrado herramientas de escaneo que recorren internet buscando servidores vulnerables y al menos un intento de instalar una puerta trasera (web shell) en el servidor.
Millones de servidores expuestos. Según VulnCheck, hay unos 2,6 millones de servidores con PHP accesibles desde internet y prácticamente todos eran vulnerables o probablemente vulnerables en el momento del aviso. Cerca del 42 % usan ramas de PHP sin soporte, para las que no hay versión oficial corregida.
Cientos de exploits falsos. En GitHub han aparecido cientos de repositorios que dicen ser exploits de PHP2Shell, y según VulnCheck sólo una mínima parte son reales. Nuestro consejo no cambia: no descargue ninguno para probar su web.
Las mitigaciones no bastan. Amazon recuerda que ningún cambio de configuración cubre los dos fallos a la vez; la única solución completa es actualizar PHP. La agencia de ciberseguridad de Estados Unidos (CISA) publicó el 21 de octubre una alerta pidiendo parchear de inmediato.

Las dos vulnerabilidades, en lenguaje llano

PHP no ha publicado los detalles técnicos completos, pero sí ha explicado en qué consiste cada fallo. Ambos tienen que ver con cómo PHP gestiona la memoria entre una petición y la siguiente.

CVE-2026-109618: corrupción al quedarse sin memoria

Si una petición agota la memoria permitida a mitad de proceso, PHP se interrumpe con datos internos a medio preparar. Al hacer limpieza los trata como si fueran válidos, y un atacante que provoque esa situación a propósito puede aprovecharlo para ejecutar código.

CVE-2026-109619: restos de una petición anterior

El servidor reutiliza los mismos procesos de PHP para atender muchas peticiones seguidas. Por este fallo, cierta información de una petición puede sobrevivir después de liberarse su memoria, y la petición siguiente en ese mismo proceso puede usarla antes de que se reinicie. Ese resto mal gestionado es otra puerta para ejecutar código.

Lo grave es la combinación: no hace falta estar autenticado, basta una petición preparada contra cualquier página que pase por PHP, y en el escenario de más riesgo el ataque se dispara antes de que se ejecute el código de la propia web. Da igual lo bien mantenido que esté el WordPress si el PHP de debajo es vulnerable.

¿Está afectada su web?

Según el aviso oficial, está afectada cualquier instalación de PHP que atienda peticiones web, sea cual sea la forma de conectarlo al servidor: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed. El equipo de PHP considera que el riesgo más alto lo tiene Apache con mod_php, muy habitual en servidores antiguos y en algunos hostings compartidos.

Sí le afecta si su web es un WordPress, un PrestaShop, un Joomla, un Drupal, un Magento, una aplicación en Laravel o Symfony, o cualquier web con formularios o zonas privadas hechas en PHP.
También le afecta si en su servidor hay otras herramientas en PHP: phpMyAdmin, una intranet, un CRM o un webmail como Roundcube.
No le afecta directamente si su web es estática, sin PHP, o si funciona sobre otra tecnología como Node.js, Python o .NET. Aun así, revise si hay algún PHP olvidado en el mismo servidor.

Versiones corregidas

Rama de PHP	Versión corregida	Situación
8.5	8.5.12	Con soporte
8.4	8.4.27	Con soporte
8.3	8.3.36	Con soporte
8.2	8.2.35	Con soporte hasta el 31/12/2026
8.1, 8.0 y 7.4	Sin versión oficial	Solo parches de código fuente o del proveedor
7.3 y anteriores	Sin corrección	Hay que migrar a una rama con soporte

Un matiz importante: las distribuciones de Linux como Debian, Ubuntu o Red Hat, y algunos proveedores de hosting, recibieron los parches antes de que se hicieran públicos y los aplican sin cambiar el número de versión. Un servidor que dice tener PHP 8.2.28 puede estar corregido si su proveedor ha aplicado el parche. Por eso, más que el número, lo que hay que confirmar es que el parche de estas dos CVE está instalado.

Si su web usa PHP 7.4, 8.0 u 8.1

Es la situación más delicada y, por lo que vemos en las búsquedas, la de muchas webs de empresa. Estas ramas ya no tienen soporte oficial de PHP, así que no habrá una versión 7.4 u 8.1 corregida en php.net. Hay tres caminos, de mejor a peor:

Migrar a una rama con soporte. Es la solución de verdad. Mejor a PHP 8.3 u 8.4 que a 8.2, cuyo soporte termina el 31 de diciembre de 2026. Antes conviene comprobar en una copia que la web, sus plugins y su plantilla funcionan con la versión nueva: en webs antiguas suele haber algo que adaptar.
Paquetes con parche del proveedor. Algunos sistemas mantienen versiones antiguas con parches de seguridad: por ejemplo, Ubuntu 20.04 con PHP 7.4 tiene el parche, pero sólo para suscriptores de Ubuntu Pro (ESM), no en las actualizaciones gratuitas. También hay proveedores comerciales que publican PHP antiguo parcheado. En un hosting compartido, pregunte a su proveedor si ha aplicado un parche a su rama o si debe cambiar de versión desde el panel.
Parche manual. El propio proyecto PHP ha publicado correcciones mínimas en código fuente para algunas ramas antiguas. Sólo sirven a quien compila PHP por su cuenta, y es una solución para ganar tiempo, no para quedarse.

Mientras tanto, aplique las mitigaciones temporales que explicamos más abajo y, si la web no es imprescindible, valore desconectarla hasta resolverlo. Una web en PHP 7.4 sin parchear es hoy un blanco fácil y conocido.

Cómo comprobarlo según su alojamiento

Si tiene WordPress

Desde el escritorio de WordPress, en Herramientas, Salud del sitio, pestaña Información y apartado Servidor, verá la versión de PHP que usa la web. Es un primer indicio, con el matiz anterior sobre los parches aplicados sin cambiar de número.

Si está en un hosting compartido

En un hosting compartido usted no actualiza PHP: lo hace el proveedor. Lo práctico es entrar en el panel, ver qué versión de PHP tiene asignada la web y, si el panel lo permite, pasarla a la rama más reciente con la que funcione su aplicación. Y abrir hoy mismo una incidencia preguntando literalmente si sus servidores tienen aplicado el parche de CVE-2026-109618 y CVE-2026-109619. Si la respuesta es vaga o no llega, eso también es información.

Si tiene un servidor propio o un VPS

Aquí la responsabilidad es suya o de quien le administre el servidor. El comando php -v muestra la versión de la línea de comandos, que no siempre es la misma que usa la web; la fiable es la que muestra la propia web. Actualice con el gestor de paquetes de su sistema y, sobre todo, reinicie después todos los procesos de PHP-FPM o Apache: un PHP actualizado en disco no protege nada mientras sigan vivos los procesos antiguos.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade
# Reinicie PHP-FPM (o apache2, según su caso)
sudo systemctl restart php8.3-fpm

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade php\*
sudo systemctl restart php-fpm httpd

Si instaló PHP desde un repositorio de terceros, como Remi o Sury, confirme en su página que ya publica las versiones corregidas para su rama antes de dar el servidor por resuelto.

Si tiene un NAS Synology

Synology publicó el 22 de octubre el aviso Synology-SA-26:14, actualizado el 29. El sistema DSM no figura como afectado y, según el fabricante, el PHP interno del sistema no está expuesto desde fuera, así que el riesgo por esa vía es muy bajo. Sí están afectados Synology Calendar, Mail Station y los paquetes de PHP 7.3 a 8.4 del Centro de paquetes, que son los que usan Web Station y las webs alojadas en el propio NAS.

Abra el Centro de paquetes y actualice todos los que tengan actualización pendiente. Las versiones corregidas son Synology Calendar 3.0.4-21435 y Mail Station 30000002.3.19-20333 o posteriores. Los paquetes de PHP tienen una versión corregida distinta según la rama de PHP y la de DSM. PHP 7.3 no recibirá parche porque está fuera de soporte: si alguna web del NAS lo usa, hay que pasarla a una versión más reciente o dejar de publicarla. Y si el NAS lleva tiempo sin actualizarse, revise también DSM: en octubre hay ataques de ransomware contra Synology desactualizados, que explicamos en un artículo aparte.

Qué hacer hoy, en orden

Haga inventario: qué webs y herramientas en PHP tiene la empresa, dónde están alojadas y quién las administra. Incluya lo olvidado, como una tienda antigua o un subdominio de pruebas.
Actualice PHP a una versión corregida, o pida a su proveedor que confirme por escrito que el parche está aplicado.
Reinicie todos los procesos de PHP y del servidor web tras actualizar.
Si no puede actualizar hoy, aplique las mitigaciones temporales del apartado siguiente y valore poner la web detrás de Cloudflare, que ha publicado reglas para los vectores de ataque conocidos también en su plan gratuito.
Si nada de lo anterior es posible, desconecte temporalmente la web. Es lo que recomienda el centro de ciberseguridad británico (NCSC) para los sistemas que no se pueden corregir, y es preferible a dejar la puerta abierta.
Revise si ya ha habido intrusión. Actualizar cierra la puerta, pero no echa a quien haya entrado antes.

Mitigaciones temporales si no puede actualizar

El propio equipo de PHP ha publicado unas medidas que reducen la exposición mientras se actualiza, con una advertencia clara: no hacen segura una instalación, solo bloquean los caminos de ataque confirmados. Deben configurarse en php.ini, en el pool de PHP-FPM o en la configuración del servidor, nunca con ini_set() ni con ficheros .user.ini, y después hay que reiniciar todos los procesos.

; Contra CVE-2026-109619 (y contra CVE-2026-115560, aún sin parche)
session.upload_progress.enabled = 0
; Solo en PHP 8.5
fatal_error_backtraces = 0

; Contra CVE-2026-109618: limitar el tamaño de las peticiones
post_max_size = 8M        ; 32M si la web necesita subir ficheros
; upload_max_filesize debe quedar por debajo de post_max_size

La primera línea merece mantenerse incluso después de actualizar PHP: es la que bloquea CVE-2026-115560 hasta que salga su corrección. Si la aplicación necesita mostrar barras de progreso al subir ficheros, compruebe antes si alguna parte de su código cambia session.serialize_handler con ini_set(); si no lo hace, ese tercer fallo no le afecta.

Para el primer fallo, PHP recomienda además fijar memory_limit a -1 de forma que la aplicación no pueda volver a cambiarlo, y controlar la memoria con un límite del contenedor o del sistema. Es un cambio delicado que exige saber qué más corre en ese servidor, así que no lo aplique a ciegas en producción. Ocultar los errores con display_errors o error_reporting no sirve de nada contra estos fallos.

Cómo saber si ya le han atacado

Los primeros ataques registrados son del 17 de octubre, antes incluso del aviso oficial, así que hay que revisar desde esa fecha hasta el momento en que su servidor quedó actualizado. Merece la pena buscar estos indicios:

Ficheros .php nuevos o modificados en las últimas fechas, sobre todo en carpetas donde no deberían estar, como la de subidas de WordPress (wp-content/uploads).
Usuarios administradores que nadie reconoce, en WordPress o en el panel del hosting.
Tareas programadas (cron) desconocidas, consumo de CPU anómalo o correo saliente en cantidades raras.
Páginas de spam, redirecciones extrañas o un aviso de problemas de seguridad en Google Search Console.
Si tiene acceso a los registros del servidor: peticiones POST con subida de ficheros que contengan el texto PHP_SESSION_UPLOAD_PROGRESS. Amazon lo señala como rastro de los intentos de ataque.

Si encuentra algo, no se limite a borrarlo: lo más probable es que haya más puertas traseras que la visible. Lo correcto es aislar la web, restaurar una copia de seguridad anterior al 17 de octubre sobre un PHP ya corregido, cambiar todas las contraseñas (hosting, FTP, base de datos y administradores) y revisar a qué otros datos tenía acceso ese servidor. Si había datos personales de clientes, valore con su asesor si corresponde notificar a la Agencia Española de Protección de Datos en el plazo de 72 horas.

Errores frecuentes estos días

Pensar que actualizar WordPress o un plugin de seguridad lo arregla. El fallo está en PHP, por debajo de la aplicación.
Dar por hecho que el hosting ya lo ha hecho. Muchos lo harán rápido y otros no; hay que preguntarlo y que lo confirmen.
Actualizar sin reiniciar los procesos de PHP, que siguen ejecutando la versión vulnerable.
Descargar de GitHub un supuesto exploit para probar la propia web. Ninguno está verificado y algunos pueden contener malware.
Fiarse de PHP 7.4 u 8.1 porque la web funciona bien. Son ramas sin soporte oficial; si su proveedor no ha aplicado un parche, siguen siendo vulnerables.

Conclusión práctica

PHP2Shell es de los fallos que justifican dejar lo que se esté haciendo: afecta a la mayoría de las webs de empresa, no exige credenciales y ya hay ataques. La tarea es acotada: saber dónde hay PHP, confirmar que está actualizado y reiniciado, y revisar que nadie haya entrado mientras tanto.

Si no tiene claro quién administra el servidor de su web, o su proveedor no le da una respuesta clara, ese es el primer problema a resolver. Podemos revisarlo con usted, desde la comprobación de la versión hasta la limpieza si hubiera habido intrusión.

Fuentes

Información actualizada a 30 de octubre de 2026. La situación evoluciona rápido; ante cualquier duda, prevalece el aviso oficial de PHP.