Vulnerabilidad de PHP: parche de PHP2Shell y cómo comprobar la versión de PHP (WordPress)

Entorno de prueba Familia RHELAlmaLinux 9.8PHP 8.3 · WordPress 7.1.3Verificado el 2026-10-22

PHP2Shell es el nombre de dos vulnerabilidades de PHP (CVE-2026-109618 · CVE-2026-109619) cuyos parches se publicaron el 21 de octubre de 2026. Son fallos de ejecución remota de código que permiten ejecutar código en el servidor incluso con una petición sin iniciar sesión, así que lo primero es comprobar qué versión de PHP usa tu sitio y actualizarla a una versión parcheada. En un servidor Nginx + Apache con WordPress 7.1.3, comprobé la versión de PHP en Salud del sitio, actualicé solo los paquetes php a la versión parcheada y volví a comprobarla.

Índice

2 min de lectura

1️⃣ PHP2Shell, la vulnerabilidad de PHP: cómo funcionan los fallos y a quién afectan

Los fallos están dentro del motor de PHP, que lee la petición antes de que se ejecute el código de WordPress, así que siguen ahí aunque mantengas los plugins y temas al día si no actualizas PHP. Según el aviso de CERT-EU, los dos tienen una puntuación CVSS de 9,2; los detalles técnicos se han hecho públicos y se están debatiendo, y ya empieza a circular código inicial de prueba de concepto.

CVE-2026-109618 es un fallo por el que, cuando una petición supera el límite de memoria (memory_limit) y se interrumpe, el proceso de limpieza trata como válidos unos datos de la petición inicializados solo a medias. CVE-2026-109619 es un fallo por el que el estado de la memoria liberada tras un error fatal persiste y se reutiliza antes de inicializarse en la siguiente petición que atiende el mismo worker.

Según el anuncio de php.net, afecta a todas las instalaciones de PHP que atienden peticiones web, y Apache mod_php se considera la configuración más peligrosa. El motivo es que en mod_php se demostró que una sola petición sin iniciar sesión desencadena el ataque antes de que se ejecute el código de la aplicación.

Modo de ejecución de PHP	Impacto	Notas
Apache mod_php	🔴 Afectado · el más peligroso	Demostración en la que una sola petición sin iniciar sesión desencadenó el ataque antes de ejecutarse el código de la aplicación
PHP-FPM	🔴 Afectado	—
php-cgi	🔴 Afectado	—
FrankenPHP	🔴 Afectado	—
LiteSpeed	🔴 Afectado	—

Las versiones corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12, y todas las versiones anteriores de las ramas 8.2 a 8.5 están afectadas. PHP 8.1 y anteriores son ramas que el proyecto PHP ya no mantiene, así que no tienen versión parcheada oficial; se cubren con las correcciones que trasladan las distribuciones y los proveedores de hosting (backports).

Cuando CISA publicó su aviso el 21 de octubre no se había confirmado ninguna explotación real, pero consideró peligroso dejar los sistemas sin parchear y recomendó parchear de inmediato, empezando por los sistemas expuestos a internet. Ese mismo día, en su aviso, CERT-EU concluyó que, al empezar a circular código de prueba de concepto, había aumentado la probabilidad de que los atacantes ya estuvieran explotando los fallos.

2️⃣ Comprobar la versión de PHP: Salud del sitio › Información › Servidor

Aunque conozcas los fallos, no sabrás qué hacer hasta saber con qué versión de PHP funciona tu sitio. En el panel de administración, abre [Herramientas › Salud del sitio] y despliega la sección [Servidor] de la pestaña [Información]: la fila [Versión de PHP] muestra la versión de PHP que realmente atiende las peticiones de tu sitio.

Pantalla de la pestaña Información de Salud del sitio: menú izquierdo Herramientas › Salud del sitio y filas Arquitectura del servidor, Servidor web, Versión de PHP y PHP SAPI de la sección Servidor — la versión de PHP es la referencia para comprobar el parche de la vulnerabilidad de PHP PHP2Shell (WordPress 7.1.3)

La fila [PHP SAPI], justo debajo de [Versión de PHP], muestra el modo de ejecución de PHP; fpm-fcgi indica una configuración PHP-FPM. Aquí solo miramos las dos filas [Versión de PHP] y [PHP SAPI] de la sección [Servidor].

🧩 Flujo del ataque PHP2Shell

Diagrama explicativo

①Petición sin iniciar sesiónUna petición web que cualquiera puede enviar

②Petición especialmente manipuladaPHP la lee antes que el código de WordPress

③Fallos de PHPSin memoria → se usan tal cual datos a medio construirCVE-2026-109618La siguiente petición usa el estado de una petición ya terminadaCVE-2026-109619

④Ejecución de código en el servidorToma de control del sitio

✅ Las versiones corregidas bloquean este flujo8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

El ataque empieza con una petición sin iniciar sesión. En la fase en la que PHP lee la petición especialmente manipulada antes que el código de WordPress, la petición activa uno de los dos fallos y termina en la ejecución de código en el servidor. Las versiones corregidas bloquean este flujo, así que lo que hay que hacer es subir el PHP del sitio a una versión corregida o posterior.

[php -v] en la terminal solo muestra la versión del PHP predeterminado de la línea de comandos. En configuraciones que instalan varias versiones de PHP en un mismo servidor, como EA-PHP de cPanel o alt-php de CloudLinux, puede no coincidir con la que usa tu sitio. Por eso la referencia es el valor [Versión de PHP] de Salud del sitio.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ Por debajo de PHP 8.2: confirma con tu hosting si aplicó un backport y, si no, solicítalo

Si la [Versión de PHP] de Salud del sitio es anterior a 8.2 (7.x, 8.0 u 8.1), no hay versión parcheada oficial de php.net. Según la tabla de versiones con soporte de php.net (consultada el 22 de octubre de 2026), solo tienen soporte cuatro ramas, 8.2, 8.3, 8.4 y 8.5, y las versiones oficiales 8.1 y anteriores no reciben parches de seguridad.

En su lugar, a veces las distribuciones y los proveedores de hosting publican paquetes que mantienen el número de versión y solo incorporan la corrección (backports). Los paquetes 7.4.33, 8.0.30 y 8.1.34 de un servidor de prueba de un hosting gestionado son un ejemplo. Su registro de cambios incluía la línea [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Aunque el número de versión sea el mismo, para saber si la corrección está incluida busca el número de CVE en el registro de cambios del paquete. En Debian y Ubuntu se busca con algo como [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. En sistemas RPM la forma es [rpm -q --changelog php-common | grep 109618]; ajusta el número de versión del nombre del paquete a la versión que usa tu sitio.

Por eso, si estás por debajo de 8.2, primero pregunta a tu proveedor de hosting si ha aplicado el backport y, si no lo ha hecho o no puede confirmarlo, pídele que te suba a una versión con soporte (8.2 o posterior). Después, vuelve a comprobar el valor [Versión de PHP] en Salud del sitio.

CISA recomendó a las organizaciones que usan 8.1 o anterior y no pueden actualizar de inmediato que mantengan sus sistemas basados en PHP sin conexión hasta parchearlos o actualizarlos.

Si administras tú mismo el servidor y usas 8.1 o anterior, puedes instalar los paquetes con backport de tu distribución o aplicar los parches de código fuente para 7.4, 8.0 y 8.1 que publicó el equipo de seguridad de PHP. Aun así, son ramas sin soporte, así que la solución de fondo es pasar a una versión con soporte.

4️⃣ PHP 8.2 o posterior: actualiza a la versión parcheada y vuelve a comprobar

Si tienes 8.2 o posterior pero por debajo de la versión parcheada, actualiza el propio PHP. En los hostings gestionados y compartidos, el proveedor aplica el parche a todo el servidor, así que confirma con sus avisos o con soporte si ya lo aplicó y qué compilación tienes, y comprueba si ha cambiado la [Versión de PHP] en Salud del sitio. Según su página de estado, Cloudways empezó a aplicar el parche a todas las versiones de PHP que admite (5.6 a 8.4) el 21 de octubre a las 22:19 UTC. El 22 de octubre a las 10:11 UTC anunció que había terminado.

🪐ReferenciasPHP2Shell 2

📡[Urgente] Emergencia en PHP, que usa el 70 % de los sitios web | La vulnerabilidad y qué hacer ya (en coreano) 🌌Hosting gestionado de Cloudways

En un servidor que administras tú, actualiza con los paquetes del repositorio de tu distribución o de un proveedor LTS, como indica el anuncio de php.net. Antes de actualizar, revisa en una vista previa la lista de paquetes que cambiarán para comprobar que solo se actualizan los que empiezan por php y que no se arrastra ningún otro, y no lo mezcles con otras actualizaciones del sistema operativo.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (se omiten las líneas de paquetes de extensiones como php-gd · php-intl)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (se omiten las líneas de paquetes de extensiones)

Complete!

En esta prueba solo se actualizaron a la versión parcheada los paquetes que empiezan por php, y php-fpm se reinició solo al terminar la instalación de los paquetes. La versión corregida no se aplica hasta que se reinician los workers de php-fpm, así que en entornos sin reinicio automático ejecuta tú mismo [systemctl restart php-fpm].

Después de actualizar, comprueba que tanto [php -v] como la fila [Versión de PHP] de la pestaña [Información] de Salud del sitio muestran la versión parcheada o posterior, y revisa también el estado del servicio php-fpm y la respuesta del sitio. Si solo cambió el valor de la línea de comandos y [Versión de PHP] sigue igual, reinicia php-fpm y vuelve a comprobar.

Pantalla de la pestaña Información de Salud del sitio: después de actualizar, se comprueba de nuevo que la fila Versión de PHP de la sección Servidor está en la versión parcheada o posterior — menú izquierdo Herramientas › Salud del sitio y filas Versión de PHP y PHP SAPI de la sección Servidor (WordPress 7.1.3)

Después de la actualización, despliega de nuevo la sección [Servidor] en la pestaña [Información] de la misma pantalla [Herramientas › Salud del sitio] y mira la fila [Versión de PHP]. Si el valor ha cambiado a la versión a la que actualizaste, los workers de php-fpm también se ejecutan ya con la nueva versión.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

En los paquetes cuyo número de versión sube, el parche se confirma por el nuevo número de versión; en los paquetes con backport que mantienen el número, por el número de CVE del registro de cambios. Este servidor era del primer tipo, así que [rpm -q --changelog php-common] no tenía ninguna línea con el número de CVE, y lo confirmé por el nuevo número de versión de la primera línea del registro de cambios.

5️⃣ Si no puedes actualizar de inmediato: las medidas temporales que indica php.net

Para los servidores que no se pueden actualizar de inmediato, php.net indica los siguientes ajustes como medidas temporales, aunque aclara que solo reducen rutas de ataque concretas y no hacen segura la instalación. También advierte que no se limite la memoria con RLIMIT_AS o RLIMIT_DATA en su lugar, porque eso puede provocar precisamente los fallos de asignación vulnerables.

Ajustes	Valor	Dónde	Qué bloquea
memory_limit	-1	php_admin_value en el pool de FPM o en la configuración de Apache (para que la aplicación no pueda revertirlo)	CVE-2026-109618 · ruta de fallo por límite de memoria (no completa)
post_max_size	8M (32M si necesitas subir archivos) · upload_max_filesize por debajo de ese valor	php.ini · configuración del pool	CVE-2026-109618
session.upload_progress.enabled	0 + reiniciar todos los workers	php.ini · pool de FPM · configuración del servidor (no con ini_set() ni .user.ini)	CVE-2026-109619 · solo la ruta de sesión confirmada
fatal_error_backtraces	0 + reiniciar todos los workers (solo PHP 8.5)	Igual que arriba	CVE-2026-109619 · solo la ruta de backtrace confirmada

php_admin_value es un ajuste del lado del servidor que la aplicación no puede revertir, así que los usuarios de hosting compartido a menudo no pueden cambiarlo por sí mismos y, también en ese caso, acaban pidiéndoselo al proveedor de hosting. php.net recomienda además poner límites, también en el servidor web o el proxy, al tamaño del cuerpo de la petición, al número de campos de entrada, al número de partes multipart, al número de cabeceras y a la profundidad de anidamiento.

🔢 FAQ & contenido recomendado

Las actualizaciones automáticas de WordPress solo abarcan el núcleo, los plugins, los temas y las traducciones; PHP es un programa instalado en el servidor, así que lo actualiza el administrador del servidor o el proveedor de hosting. Las actualizaciones automáticas del núcleo, los plugins y los temas se activan en la pantalla Actualizaciones de WordPress y en las pantallas de plugins y temas, respectivamente, y en ninguna de ellas aparece la versión de PHP.

Todos los detalles técnicos están en los dos avisos de seguridad de GitHub que el anuncio de php.net enlaza junto a los números de CVE. CVE-2026-109618 corresponde a GHSA-w8hw-w9fx-j79w y CVE-2026-109619, a GHSA-6wmf-4rv5-p3rp. El aviso de CERT-EU cita esos mismos dos avisos como referencias, y en este artículo no se incluyen detalles para reproducir el ataque.

CISA recomienda vigilar si los procesos worker de PHP abren shells o descargan herramientas. También indica que, hasta aplicar el parche, un firewall de aplicaciones web puede ofrecer cierta protección. Como PHP suele ir integrado como componente de otro software y pasa desapercibido, CISA recomendó empezar por hacer una lista de los sistemas en los que se ejecuta PHP.

🔗 Contenido recomendado

Seguridad Seguridad en WP: seguridad de wp-admin Ajustes que protegen el panel de administración cambiando la URL de acceso, limitando los intentos de inicio de sesión y bloqueando XML-RPC. Ver artículo →

Seguridad de wp-admin: entradas al acceso de WordPress

Seguridad Vulnerabilidades de seguridad de wp-config.php Cómo evitar que el archivo wp-config.php quede expuesto y reforzar sus ajustes de seguridad.

Diagrama de ataques en el registro de acceso de xmlrpc.php

Seguridad XML-RPC de WordPress Cómo detectar ataques a xmlrpc.php en los logs y tres formas de desactivarlo.

Simulador de la ruta de peticiones de php-fpm max_children

Servidor aviso de php-fpm max_children Una prueba real que encuentra la causa del aviso en los logs antes de añadir workers.

🪐ReferenciasPHP2Shell 6

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡CISA: Critical Vulnerabilities in PHP Require Immediate Patching (2026-10-21) 📡CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP 📡Aviso de seguridad de GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) 📡Aviso de seguridad de GitHub GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) 🛰️Sansec: PHP2Shell — PHP RCE (CVE-2026-109618, CVE-2026-109619)

ℹ️ Aviso de afiliados
El contenido de este sitio incluye enlaces de afiliado. Cuando un visitante compra un producto o servicio a través de uno de ellos, el sitio recibe una comisión del vendedor. El importe que paga el comprador^{(baja durante las promociones ↓)}no aumenta. Los precios, descuentos y existencias publicados corresponden al momento de redacción y pueden variar, así que confírmalos con el vendedor antes de comprar. Los productos se eligen y evalúan con criterios propios, y las comisiones no influyen en el orden ni en el contenido de las reseñas.