¿Tu web usa PHP? Actualiza hoy o puede ser atacada

Alerta crítica · actualizado el 21 de octubre de 2026. PHP ya ha publicado el parche: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Hay explotación activa y, con el código corregido ya público, los ataques automatizados se multiplican. Si tienes PHP expuesto a internet, actualiza hoy.

Vídeo: PHP2Shell, el fallo crítico de PHP que ya se está explotando y cómo protegerte

Se llaman PHP2Shell: CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 9.2 (crítica). Permiten que un atacante sin credenciales ejecute código en el servidor con peticiones HTTP. No hace falta que tu aplicación tenga ningún fallo: el problema está en el propio PHP, y en Apache con mod_php se ha demostrado el ataque antes de que se ejecute una sola línea de tu aplicación.

Última hora

Actualizamos esta sección a medida que salen novedades. Horas en horario peninsular español.

23-oct, 15:00 · Hubo ataques cuatro días antes del aviso, y PHP pide mantener desactivado upload_progress.

Amazon (Amazon Threat Intelligence) detectó en su red de honeypots un intento de explotación el 17 de octubre, cuatro días antes de que se hiciera público el fallo, y "intentos amplios" desde el 21. Aún no hay ningún compromiso real confirmado.
Recomienda revisar los logs desde el 17 de octubre, no desde el día del parche, y buscar peticiones POST que contengan PHP_SESSION_UPLOAD_PROGRESS. Publica varias IP de origen, pero son redes de anonimización compartidas: úsalas para investigar, no para bloquear a ciegas.
PHP (aviso informativo del 23-oct) recomienda mantener session.upload_progress.enabled=0 incluso después de actualizar, hasta la próxima versión. Ha encontrado otro posible fallo de ejecución de código (CVE-2026-115560), poco probable: solo afecta si la aplicación cambia session.serialize_handler con ini_set() antes de session_start(). Si ya lo desactivaste el día 21, déjalo así.
Sin cambios: Debian sigue sin paquete para bookworm (php8.2) y CISA no la ha incluido en su catálogo KEV.

22-oct, 20:05 · Más de 28.000 servidores en España siguen anunciando una versión de PHP sin el parche.

Una búsqueda en Shodan, el buscador que indexa servidores expuestos a internet, hecha el 22 de octubre por la mañana devuelve 28.364 servidores en España que responden con la cabecera X-Powered-By: PHP y una versión distinta de las corregidas (8.5.12, 8.4.27, 8.3.36 y 8.2.35). Por ciudades: Madrid (8.421), Zaragoza (3.713), Valencia (2.005), Barcelona (1.543) y Getafe (1.164). Entre los resultados aparecen versiones como PHP 8.3.14 y PHP 7.4.13, esta última sin soporte desde hace años.
Es una aproximación, no un recuento exacto. Por un lado sobran servidores: las distribuciones parchean sin cambiar el número de versión (un Ubuntu 24.04 ya corregido sigue diciendo PHP 8.3.6), así que algunos ya están protegidos. Por otro faltan: los servidores que ocultan la cabecera no aparecen.
Lo que sí demuestra es que a un atacante le resulta muy fácil sacar la lista de servidores que anuncian una versión vulnerable. Si tu servidor publica la versión de PHP, ocúltala con expose_php = Off en php.ini. No te protege del fallo, pero te saca de esa lista. Lo que te protege es actualizar.

22-oct, 18:40 · Red Hat empieza a publicar paquetes y avisa de que también afecta a sus contenedores.

Red Hat (boletín RHSB-2026-013, actualizado el 22-oct): afecta a RHEL 8, 9 y 10, a OpenShift Dev Spaces y a todo lo que use el paquete php de RHEL, incluidas las imágenes de contenedor UBI. Ya hay algunas actualizaciones disponibles y otras en camino. Si usas contenedores basados en RHEL o UBI, hay que reconstruirlos cuando se actualice la imagen base.
Según Red Hat, con PHP-FPM (lo habitual en RHEL) la ejecución de código es difícil en la práctica, porque el worker termina antes de llegar a los datos corruptos. Los servidores con mod_php están en mayor riesgo. Aún no ha publicado una mitigación propia.
Repositorio de Ondřej Surý (hilo de seguimiento): el mantenedor aclara que Ubuntu 16.04 no tendrá paquetes. También avisa de que el supuesto exploit que circula como php-up-2026.tar.gz no está validado y debe tratarse como no fiable: no lo ejecutes en tus servidores.
Sin cambios: Debian sigue sin paquete para bookworm (php8.2), PHP no ha publicado nuevas versiones ni regresiones y CISA no la ha incluido en su catálogo KEV.

21-oct, 22:40 · Ataque demostrado en WordPress, Drupal y Joomla, y cómo revisar la protección de Cloudflare.

Wiz, que descubrió los fallos (análisis técnico), ha demostrado la ejecución de código sin autenticar en las últimas versiones de WordPress, Drupal y Joomla. No hace falta ningún plugin vulnerable: basta con que corran sobre un PHP sin parchear. Wiz avisa de que probablemente existan más variantes.
Las señales que propone Wiz para detectar intentos son peticiones multipart raras seguidas de errores de memory_limit, errores 500 repetidos, cookies PHPSESSID anormalmente grandes o malformadas en las respuestas, y reinicios inexplicables de workers de PHP. Los logs de la aplicación pueden no mostrar nada, porque el fallo ocurre por debajo de ella.
Cloudflare (detalle de la protección) activó sus reglas a las 05:02 del 21 de octubre, nueve horas antes del parche. Ha visto a los atacantes modificar los ataques para intentar esquivarlas. En los planes de pago hay que comprobar que el Managed Ruleset está en modo bloqueo. Los bloqueos se pueden revisar en Security → Security Analytics → Events, filtrando por las reglas "Anomalous Execution".
CERT-FR (CERTFR-2026-ALE-014) ha actualizado su alerta con las versiones corregidas (8.2.35, 8.3.36, 8.4.27 y 8.5.12). Insiste en que las mitigaciones temporales no las ha validado y en que hay que aislar las ramas sin soporte.
Sin cambios: Debian aún no tiene paquete para bookworm (php8.2), Red Hat sigue sin publicar paquetes y CISA no la ha incluido en su catálogo KEV.

21-oct, 18:40 · Ubuntu Pro corrige las LTS antiguas y Red Hat se pronuncia (aún sin paquetes).

Ubuntu (USN-8948-2): ya hay paquetes corregidos para 20.04 (php7.4 7.4.3-4ubuntu2.29+esm5), 18.04 (php7.2), 16.04 (php7.0) y 14.04 (php5), pero solo con Ubuntu Pro (en 14.04, con el complemento Legacy Support). Sin suscripción, esas versiones siguen expuestas.
Red Hat (ficha del CVE) lo califica como Important (CVSS 3.1 de 8.1, provisional). Su argumento es que RHEL usa por defecto PHP-FPM y no mod_php, lo que hace más difícil la explotación. Aún no hay paquetes corregidos y, según Red Hat, ninguna mitigación cumple sus criterios: la única solución completa es instalar la versión corregida cuando salga.
watchTowr (FAQ) confirma explotación en internet detectada por su red de honeypots el 21 de octubre, sin dar volumen. CISA todavía no la ha incluido en su catálogo KEV de vulnerabilidades explotadas.
Repositorio de Ondřej Surý (hilo de seguimiento): los usuarios ya ven PHP 8.2.35 en el PPA para Ubuntu 22.04 (amd64). Launchpad ha dado errores 503 por saturación, y los paquetes para ARM siguen sin llegar. No se han reportado regresiones del parche.

21-oct, 16:45 · Ya hay paquetes corregidos en Ubuntu y Debian.

Ubuntu (USN-8948-1): 26.04 LTS con php8.5 8.5.4-0ubuntu1.5, 24.04 LTS con php8.3 8.3.6-0ubuntu0.24.04.13 y 22.04 LTS con php8.1 8.1.2-1ubuntu2.28. Las versiones 20.04 y anteriores siguen "en evaluación".
Debian (DSA-6574-1): trixie con php8.4 8.4.27-1~deb13u1. Para bookworm (php8.2) aún no hay aviso publicado.
Repositorio de Ondřej Surý (sury.org, muy usado en Debian y Ubuntu): el mantenedor confirma parches para todas las ramas del repositorio, también las que ya no tienen soporte, y los usuarios ya reciben paquetes desde PHP 5.6 en amd64. Las compilaciones para ARM y el PPA de Ubuntu van con retraso.
Red Hat: a esta hora no encontramos aviso ni paquetes publicados. Remi no tendrá actualizaciones hoy.
Ojo con los parches para PHP 7.4, 8.0 y 8.1 que ha publicado PHP: no son versiones nuevas que se descarguen de php.net, sino cambios mínimos en código fuente pensados para quien compila PHP a mano y para los proveedores de soporte extendido. Están en GitHub: PHP 7.4 · PHP 8.0 · PHP 8.1. Si no compilas, tu vía es el paquete de tu distribución o proveedor.
CERT-FR (CERTFR-2026-ALE-014) confirma que desactivar session.upload_progress solo reduce la superficie de ataque de una de las dos vulnerabilidades. Recomienda bloquear las peticiones multipart (o vigilarlas si no se pueden bloquear) y aislar ya los servidores con ramas sin soporte.

Por qué esta vez es grave

Los detalles se filtraron antes del parche. PHP tuvo que adelantar el aviso al 20 de octubre y la publicación al 21.
Ya se está explotando. Cloudflare detectó los primeros ataques a las 07:43 UTC del 21 de octubre, horas antes del parche, y Aikido confirmó explotación real esa misma mañana.
Afecta a casi todo. El aviso oficial da por vulnerable cualquier versión anterior a las corregidas. Eso incluye WordPress, WooCommerce, Magento, Shopware, Laravel, Drupal, PrestaShop y cualquier web o panel en PHP.
Ahora el fallo es público. Con el código corregido publicado, cualquiera puede ver exactamente qué se ha arreglado. Sansec esperaba escaneos masivos a los pocos minutos de la publicación.
Hay miles de servidores expuestos en España. Un día después del parche, una búsqueda en Shodan encuentra más de 28.000 servidores en España que anuncian una versión de PHP sin corregir (detalle en la entrada de "Última hora" del 22-oct, 20:05).
Hay organizaciones apagando servicios. En Países Bajos, Tweakers, la Tweede Kamer y el NCSC desconectaron webs por precaución.

¿Está afectado tu servidor?

Tu versión de PHP	Qué instalar
8.5	8.5.12 o superior
8.4	8.4.27 o superior
8.3	8.3.36 o superior
8.2	8.2.35 o superior (fin de soporte el 31-dic-2026)
8.1 · 8.0 · 7.4	No hay versión oficial. El paquete corregido de tu distribución o proveedor de soporte extendido, o compilar con los backports en código fuente que ha publicado PHP en GitHub (PHP 7.4 · PHP 8.0 · PHP 8.1). Y planifica migrar a 8.2+.
7.3 y anteriores	Sin corrección pública. Aísla el servidor y migra.

El riesgo es mayor con Apache y mod_php, donde PHP ha demostrado la explotación completa. PHP-FPM, php-cgi, FrankenPHP y LiteSpeed también están afectados.

Qué hacer hoy, en este orden

Haz inventario ya. Lista todos los servidores, hostings y contenedores con PHP accesible desde internet, incluidos paneles de administración olvidados y webs antiguas.
Actualiza. Instala la versión corregida de tu rama o el paquete actualizado de tu distribución (recibieron el parche por adelantado). Si usas el repositorio de Remi, PHP avisa de que hoy no tendrá actualizaciones: cambia a los paquetes de la distribución o compila.
Reinicia PHP-FPM o Apache. Sin reinicio sigue corriendo el binario vulnerable. Lo mismo para Octane, workers de colas y cualquier proceso PHP de larga duración.
Comprueba la versión que sirve la web, no la de la terminal: php -v puede mostrar otra distinta de la que usa Apache o FPM.
Si hoy no puedes actualizar, aplica las mitigaciones temporales del aviso oficial. Las explicamos paso a paso, con la configuración lista para copiar, en PHP2Shell: mitigarlo si aún no puedes actualizar. Y apaga lo que no sea imprescindible.
Revisa si ya te han entrado. Hubo explotación antes del parche: busca ficheros PHP nuevos o modificados, web shells, usuarios administradores nuevos y conexiones salientes extrañas.

¿Usas hosting compartido? Escribe hoy a tu proveedor y pregunta qué versión de PHP te sirve y cuándo aplicará el parche. No des por hecho que lo hará solo.

Preguntas frecuentes

¿Qué versión de PHP corrige PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026. Cualquier versión anterior es vulnerable. Para PHP 7.4, 8.0 y 8.1 el equipo de PHP ha publicado backports en código fuente, y las distribuciones y proveedores de soporte extendido recibieron los parches por adelantado.

¿Mi servidor es vulnerable a PHP2Shell?

Si sirve PHP por web y no tiene una de las versiones corregidas, sí. Afecta a Apache con mod_php (el caso más grave, con explotación demostrada antes de que se ejecute la aplicación), PHP-FPM, php-cgi, FrankenPHP y LiteSpeed.

¿Qué hago si no puedo actualizar hoy?

Aplicar las mitigaciones temporales del aviso oficial: memory_limit=-1 fijado por el administrador, límites de tamaño de petición, session.upload_progress.enabled=0 y, en PHP 8.5, fatal_error_backtraces=0, reiniciando todos los workers. Bloquear multipart/form-data en el servidor web si la aplicación no lo usa. Ninguna sustituye a la actualización.

Fuentes:

Artículos relacionados:

PHP2Shell (CVE-2026-109618): mitigarlo si aún no puedes actualizar

Consultoría por horas

¿Quieres que revisemos y aseguremos tu entorno?

Revisamos tus servidores con PHP, aplicamos el parche o las mitigaciones y comprobamos que nadie haya entrado. Déjanos tu teléfono o tu correo y te contactamos hoy mismo.

Solo lo usaremos para contactarte sobre esta solicitud. Política de privacidad.