PHP2Shell, dos vulnerabilidades críticas en PHP que ponen en riesgo tu WordPress y cómo solucionarlas

El equipo de desarrollo de PHP publicó el 21 de octubre de 2026 varias actualizaciones de seguridad para corregir dos vulnerabilidades críticas que permiten la ejecución remota de código en determinadas configuraciones de servidores web. Los fallos están identificados como CVE-2026-109618 y CVE-2026-109619, y ambos cuentan con una puntuación CVSS de 9,2 sobre 10. Fuente oficial de PHP.

Estas vulnerabilidades son especialmente relevantes para los administradores de servidores web, ya que PHP es uno de los componentes fundamentales de WordPress y de muchas otras aplicaciones web.

En este artículo veremos qué implican estos fallos, cómo comprobar si un servidor está afectado y qué medidas aplicar para actualizar PHP de forma segura.

¿En qué consisten las vulnerabilidades?

Las dos vulnerabilidades afectan al propio intérprete de PHP y pueden permitir que un atacante ejecute código de forma remota sin necesidad de autenticarse previamente, si el servidor utiliza una configuración vulnerable.

Los fallos identificados son:

CVE-2026-109618: relacionado con la gestión de memoria cuando se produce una situación de falta de memoria (Out of Memory o OOM).
CVE-2026-109619: relacionado con el uso de estado interno obsoleto después de liberar memoria.

En determinadas circunstancias, estos errores pueden provocar que PHP gestione incorrectamente datos internos de una petición HTTP y termine ejecutando código controlado por un atacante.

El impacto potencial es considerable. Dependiendo de los permisos del proceso PHP y de la configuración del servidor, un ataque exitoso podría permitir acceder a información sensible, modificar archivos de la aplicación, instalar código malicioso o utilizar el servidor como punto de entrada para nuevos ataques.

La documentación oficial de PHP confirma que ambas vulnerabilidades pueden provocar ejecución remota de código sin autenticación. También advierte de que no existe una mitigación completa que sustituya a la actualización.

¿A quién afecta este problema?

El riesgo no se limita a WordPress. Afecta a las instalaciones de PHP que atienden peticiones web mediante configuraciones como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed.

En el caso de WordPress, es importante entender que actualizar los plugins, el tema o el propio WordPress no corrige una vulnerabilidad presente en el intérprete de PHP.

Por tanto, una web que tenga todos sus componentes actualizados puede continuar expuesta si el servidor utiliza una versión vulnerable de PHP.

Los administradores deberían revisar especialmente:

Sitios WordPress alojados en servidores VPS o dedicados.
Servidores Apache o Nginx que ejecuten aplicaciones PHP.
Instalaciones que utilicen versiones antiguas de PHP.
Servidores que mantengan varias versiones de PHP para diferentes aplicaciones.
Entornos de producción, pruebas y staging que sean accesibles desde Internet.

1. Comprobar la versión de PHP

Antes de actualizar, debemos identificar qué versión utiliza realmente nuestra aplicación.

Desde el panel de WordPress

Si administras una web WordPress, puedes consultar la versión desde el propio panel:

Accede al escritorio de WordPress.
Entra en Herramientas → Salud del sitio.
Abre la pestaña Información.
Despliega el apartado Servidor.
Localiza el campo correspondiente a la versión de PHP.

Anota la versión completa, incluido el último número de revisión.

Desde un servidor Linux

Si tienes acceso SSH al servidor, ejecuta:

php -v

El resultado mostrará la versión de PHP instalada para la línea de comandos.

Importante: esta versión puede ser diferente de la que utiliza WordPress. Por ejemplo, PHP ejecutado desde la terminal puede ser una versión distinta de la configurada en PHP-FPM o Apache.

Para comprobar los servicios PHP-FPM disponibles en sistemas Debian o Ubuntu:

systemctl list-units --type=service --all | grep php

También puedes consultar los paquetes instalados:

dpkg -l | grep -E 'php[0-9]+\.[0-9]+-(fpm|cli)'

Si utilizas Nginx con PHP-FPM, revisa además qué socket o dirección está configurado en el bloque fastcgi_pass del sitio web. Así podrás identificar qué versión de PHP atiende realmente las peticiones.

2. ¿Qué versiones de PHP corrigen las vulnerabilidades?

Según el aviso oficial publicado por el equipo de PHP el 21 de octubre de 2026, las versiones corregidas son:

Rama de PHP	Versión corregida
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Si utilizas una de estas ramas, debes instalar como mínimo la versión indicada en la tabla o una revisión posterior que incluya las correcciones.

Si utilizas PHP 8.1 o una versión anterior, no basta con buscar una actualización menor: debes planificar la migración a una rama que reciba actualizaciones de seguridad.

Recomendación: cuando sea compatible con tu aplicación, prioriza una rama de PHP que siga recibiendo soporte de seguridad. PHP 8.2 tiene previsto finalizar su ciclo de soporte el 31 de diciembre de 2026.

Puedes consultar los detalles y las descargas en el sitio oficial de PHP.

3. Cómo solucionar el problema en un hosting

Si tu WordPress está alojado en un proveedor externo, normalmente podrás cambiar la versión de PHP desde su panel de administración.

El procedimiento habitual es el siguiente:

Realiza una copia de seguridad de los archivos y de la base de datos.
Accede al panel de control del hosting.
Busca la sección de configuración de PHP, que puede aparecer como «PHP Selector», «Configuración PHP» o «Versión de PHP».
Selecciona una versión corregida compatible con tu WordPress, tema y plugins.
Guarda los cambios y espera a que se apliquen.
Comprueba la versión desde Salud del sitio de WordPress.
Verifica que la web funciona correctamente, incluidos el acceso al panel, los formularios y las tareas programadas.

Si el proveedor no permite cambiar la versión, contacta con su soporte técnico y solicita la actualización del intérprete PHP que utiliza tu sitio.

No des por concluida la tarea hasta confirmar la versión efectiva que ejecuta la web.

4. Cómo actualizar PHP en un servidor propio con Debian o Ubuntu

En un servidor administrado directamente, el procedimiento depende de cómo se haya instalado PHP: paquetes de la distribución, repositorios externos, contenedores o compilación propia.

Antes de modificar nada, identifica la versión activa, el servicio web y los paquetes que dependen de PHP.

Paso 1. Actualizar los índices de paquetes

En sistemas Debian o Ubuntu que utilicen los repositorios configurados:

sudo apt update

Esto actualiza la información disponible de los repositorios, pero no garantiza por sí solo que se instale una versión corregida de PHP.

Paso 2. Comprobar las actualizaciones disponibles

Consulta los paquetes relacionados con la versión de PHP instalada:

apt list --upgradable 2>/dev/null | grep -E 'php[0-9]?\.?[0-9]?'

También puedes comprobar la política de un paquete concreto. Por ejemplo, si utilizas PHP 8.3-FPM:

apt-cache policy php8.3-fpm

Revisa que el repositorio configurado ofrezca una versión que incluya la corrección.

No todos los repositorios proporcionan las mismas versiones. Una distribución puede mantener una versión anterior del paquete e incorporar correcciones mediante parches propios. En ese caso, hay que verificar la información de seguridad de la distribución en lugar de comparar únicamente el número de versión.

Paso 3. Instalar las actualizaciones

Si utilizas paquetes de la distribución y estos contienen la corrección, puedes actualizar los paquetes afectados mediante:

sudo apt upgrade

Si la versión corregida no está disponible, tendrás que revisar los repositorios, las políticas de soporte y las alternativas compatibles antes de realizar una migración.

No añadas repositorios de terceros sin comprobar su procedencia y mantenimiento.

Si necesitas cambiar a otra rama de PHP, planifica la instalación de sus extensiones y la configuración de PHP-FPM, Apache o Nginx. No elimines la versión anterior hasta haber comprobado que las aplicaciones funcionan con la nueva.

Paso 4. Reiniciar o recargar los servicios cuando corresponda

Después de actualizar los paquetes, comprueba si el gestor de paquetes ha reiniciado los servicios necesarios.

Si utilizas PHP-FPM y necesitas reiniciar la instancia correspondiente, por ejemplo PHP 8.3:

sudo systemctl restart php8.3-fpm

Si utilizas Apache con mod_php, puede ser necesario reiniciar Apache:

sudo systemctl restart apache2

En Nginx con PHP-FPM, normalmente debes asegurarte de que el servicio PHP-FPM correcto está actualizado y activo. Un reinicio de Nginx no sustituye a la actualización de PHP.

Comprueba el estado del servicio que corresponda:

sudo systemctl status php8.3-fpm

Adapta el nombre del servicio a la versión realmente instalada y a tu configuración.

Paso 5. Verificar la versión efectiva

Comprueba la versión de la terminal:

php -v

Después, vuelve a WordPress y revisa Herramientas → Salud del sitio → Información → Servidor.

Si ambas versiones son diferentes, no necesariamente existe un problema: lo importante es confirmar que el intérprete utilizado por las peticiones web está corregido.

No es recomendable publicar un archivo phpinfo() accesible desde Internet para realizar esta comprobación. Si necesitas utilizar una página de diagnóstico temporal, protégela y elimínala inmediatamente después.

5. ¿Qué ocurre si no puedes actualizar inmediatamente?

En este caso, debes tratar el sistema como potencialmente vulnerable hasta que puedas verificar que está corregido.

El aviso oficial de PHP indica que no existen mitigaciones completas que sustituyan a la actualización. Por ello, medidas como instalar un plugin de seguridad de WordPress, bloquear determinadas rutas o añadir reglas al cortafuegos de aplicaciones web no garantizan la protección frente a estos fallos.

Mientras preparas la actualización:

Solicita al proveedor de alojamiento que aplique el parche de seguridad.
Reduce la exposición pública del servicio cuando sea viable y no afecte a servicios esenciales.
Revisa los registros de acceso y errores en busca de actividad sospechosa.
Evita exponer paneles de administración y servicios que no sean necesarios.
Prepara una copia de seguridad verificada y un procedimiento de recuperación.

Estas medidas son complementarias y no deben considerarse una solución definitiva.

6. Comprobar si el servidor ha podido verse comprometido

Actualizar PHP elimina la exposición a estas vulnerabilidades cuando se instala una versión corregida, pero no elimina automáticamente un posible código malicioso que un atacante haya instalado con anterioridad.

Si tu servidor ejecutaba una versión vulnerable y estaba expuesto a Internet, conviene realizar una revisión de seguridad.

En un servidor Linux puedes empezar consultando los registros de acceso y errores de Apache o Nginx. Las rutas habituales incluyen:

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/access.log
/var/log/apache2/error.log

Las rutas pueden variar según la distribución y la configuración.

Busca peticiones anómalas, errores repetidos, patrones de acceso inusuales y actividad que coincida temporalmente con posibles incidentes. No existe una única cadena de texto que permita identificar todos los intentos de explotación.

En WordPress, revisa también:

Usuarios administradores que no reconozcas.
Archivos PHP modificados recientemente sin una explicación válida.
Cambios inesperados en wp-config.php, temas y plugins.
Tareas programadas desconocidas.
Procesos, conexiones o consumo de recursos anómalos.
Alertas de tu proveedor de alojamiento o de tus herramientas de seguridad.

Si encuentras indicios de intrusión, conserva los registros y las evidencias antes de eliminarlas. Valora aislar el servidor, revisar la persistencia del atacante, restaurar desde una copia limpia y cambiar las credenciales que pudieran haberse visto comprometidas.

No asumas que la ausencia de alertas demuestra que el servidor está limpio.

7. Lista de comprobación para administradores

Antes de dar por solucionada la incidencia, verifica los siguientes puntos:

He identificado la versión de PHP que atiende las peticiones web.
He confirmado que la versión instalada contiene las correcciones.
He realizado una copia de seguridad y comprobado que puedo recuperarla.
He actualizado PHP y las extensiones necesarias.
He comprobado el estado de PHP-FPM o del módulo PHP de Apache, según corresponda.
He verificado que WordPress y sus funciones principales siguen operativos.
He revisado los registros si el servidor estuvo expuesto con una versión vulnerable.
He documentado la versión anterior, la nueva versión y la fecha de actualización.

Conclusión

Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 recuerdan que la seguridad de una aplicación web no depende exclusivamente de WordPress, sus plugins o su tema. El intérprete PHP también forma parte de la superficie de ataque y necesita mantenerse actualizado.

La prioridad debe ser identificar la versión realmente utilizada, instalar una versión corregida y comprobar que el servicio sigue funcionando correctamente. En servidores expuestos a Internet, conviene actuar con rapidez y revisar posibles indicios de compromiso si la actualización se ha retrasado.

Mantener PHP actualizado es una tarea esencial de administración de sistemas y una de las medidas más importantes para reducir el riesgo de ejecución remota de código en aplicaciones web.