PHP2Shell y WordPress: cómo saber si tu web está afectada y qué hacer

Respuesta corta: si tu WordPress recibe peticiones a través de PHP, debes comprobar la versión de PHP del servidor. Actualizar el núcleo, los plugins o el tema de WordPress no corrige PHP2Shell porque las vulnerabilidades están en el intérprete PHP. Las versiones oficiales corregidas son 8.2.35, 8.3.36, 8.4.27 y 8.5.12.

El proyecto PHP publicó el 21 de octubre de 2026 dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecución remota de código sin autenticación. El aviso oficial de PHP considera en riesgo las instalaciones que atienden peticiones web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed.

Estado de esta guía: información comprobada el 22 de octubre de 2026 con los avisos de PHP, WordPress y organismos públicos. Es una explicación práctica para propietarios y desarrolladores; no demuestra si un servidor concreto ha sido comprometido.

Qué es PHP2Shell y por qué afecta a WordPress

PHP2Shell es el nombre utilizado para agrupar dos fallos del runtime de PHP. No son un plugin malicioso ni un error exclusivo de WordPress:

• CVE-2026-109618: un fallo al gestionar situaciones de memoria agotada puede dejar datos internos de una petición en un estado inválido. El proceso de cierre puede interpretar después ese estado de forma insegura.
• CVE-2026-109619: determinados datos globales pueden sobrevivir después de liberar la memoria de una petición y ser utilizados por otra petición atendida por el mismo proceso.

Ambas vulnerabilidades recibieron una puntuación CVSS 9.2 sobre 10 en los avisos de seguridad de PHP. La primera tiene ejecución remota demostrada antes de que empiece el código de la aplicación en configuraciones habituales de Apache con mod_php. PHP también incluye otros modos de ejecución en su advertencia y recomienda actualizar todos los servidores PHP expuestos a peticiones web.

WordPress está escrito en PHP. Cuando alguien solicita una página dinámica, el servidor ejecuta PHP para cargar WordPress, consultar datos y producir la respuesta. Una vulnerabilidad situada en esa capa puede actuar antes o al margen de las defensas del CMS. Por eso WordPress.org confirmó que no hay una actualización de WordPress prevista para resolver estos fallos: debe actualizarse PHP.

Qué versiones de PHP corrigen PHP2Shell

La comparación oficial publicada por PHP es esta:

No compares solo el primer decimal. Tener PHP 8.3 no basta: necesitas conocer la versión completa y, en sistemas Linux, también el identificador del paquete.

Una versión como 8.3.35-0ubuntu0.24.04.1 puede recibir un backport: el proveedor incorpora la corrección sin convertir el paquete en PHP 8.3.36. En ese caso, el número visible no demuestra por sí solo que siga siendo vulnerable. Consulta el aviso de seguridad de la distribución o pide confirmación al hosting.

Cómo saber qué versión de PHP usa WordPress

En el panel de WordPress:

1. Entra en Herramientas > Salud del sitio.
2. Abre la pestaña Información.
3. Despliega el apartado Servidor.
4. Busca Versión de PHP y anota el número completo.

También puedes encontrarlo en el panel del hosting, normalmente dentro de apartados como PHP Manager, MultiPHP Manager, Configuración PHP o Información del servidor.

No publiques un archivo phpinfo() en una URL accesible para comprobarlo. Puede revelar rutas, módulos y configuración interna. Si administras el servidor, compara la versión de la línea de comandos con la que realmente atiende la web: php -v no siempre corresponde al pool de PHP-FPM o al contenedor activo.

Qué hacer según dónde esté alojada tu web

WordPress gestionado

El proveedor suele controlar el sistema operativo y PHP. No des por hecho que ya lo actualizó: abre un ticket y pide tres datos concretos.

1. Versión o paquete de PHP que ejecuta tu web.
2. Confirmación de que incluye los parches para ambos CVE.
3. Fecha en que se reiniciaron o sustituyeron los procesos PHP activos.

Si el proveedor habla solo de reglas WAF, pregunta también por el parche. El aviso de PHP indica que actualizar es la única mitigación completa.

Hosting compartido o cPanel

Haz una copia recuperable antes de cambiar de rama. Selecciona una versión corregida desde el panel y prueba las partes dinámicas: acceso, formularios, buscador, compra, pagos, correos y tareas programadas. Si tu rama actual no ofrece el parche, contacta con soporte en vez de saltar a una versión mayor sin comprobar compatibilidad.

Actualizar dentro de la misma rama —por ejemplo, de 8.3.35 a 8.3.36— suele tener menos impacto que migrar de 8.1 a 8.4, pero ninguna actualización sustituye a una copia y una comprobación real.

VPS o servidor administrado por ti

Actualiza desde el repositorio mantenido de tu sistema, no descargando archivos sueltos sobre una instalación desconocida. Después:

1. Reinicia PHP-FPM, Apache, LiteSpeed o el servicio que corresponda.
2. Comprueba que no quedan procesos antiguos atendiendo tráfico.
3. Verifica la versión a través de la aplicación, no solo con la CLI.
4. Revisa registros, monitorización y estado de los servicios.
5. Confirma la corrección con el aviso de tu distribución si utiliza backports.

El repositorio operativo de NCSC-NL sobre PHP2Shell reúne referencias para distribuciones y productos que incorporan PHP. Es más fiable que deducir el estado de un paquete solo por su nombre.

Docker y otros contenedores

Cambiar la etiqueta en el archivo de configuración no actualiza los contenedores que ya están ejecutándose. Debes obtener una imagen base corregida, reconstruir, desplegar y eliminar las réplicas antiguas. Comprueba el digest y la versión dentro del contenedor final.

Evita etiquetas ambiguas como latest si después no puedes demostrar qué imagen está en producción. Una etiqueta mutable puede apuntar a una imagen nueva en el registro mientras tu despliegue sigue utilizando una capa almacenada en caché.

Web estática sin PHP

Una web publicada como archivos HTML, CSS y JavaScript estáticos no ejecuta PHP y no está afectada por estos dos fallos. Este portfolio, por ejemplo, se genera con Astro y se sirve como contenido estático.

Eso no convierte Astro en una solución universalmente más segura que WordPress. Cambia la superficie de mantenimiento: desaparece el runtime PHP de la web pública, pero siguen existiendo dependencias, integraciones, formularios externos, el proceso de build y la cuenta del hosting. En Astro frente a WordPress explico cuándo tiene sentido cada arquitectura.

El mensaje exacto que puedes enviar al hosting

No necesitas pedir una explicación genérica sobre “si la web es segura”. Una solicitud verificable funciona mejor:

Hola, ¿podéis confirmarme qué versión de PHP ejecuta actualmente mi web y si vuestro paquete incluye las correcciones para CVE-2026-109618 y CVE-2026-109619? Si aún no las incluye, indicadme cuándo se actualizará, qué mitigación temporal habéis aplicado y si debo realizar alguna acción. Confirmad también si los procesos PHP fueron reiniciados después de instalar el paquete. Gracias.

Una respuesta útil debe identificar la versión o el aviso del proveedor. “Tenemos firewall” o “WordPress está actualizado” no responde a la pregunta.

Por qué un WAF o un cambio de configuración no bastan

Un firewall de aplicaciones puede bloquear patrones conocidos y reducir exposición mientras llega el parche. También puede generar falsos positivos o dejar pasar variaciones que no conoce. No modifica el código vulnerable dentro de PHP.

El equipo de PHP publicó mitigaciones temporales para rutas concretas, pero advierte que no hacen segura una instalación vulnerable. No recomiendo copiar cambios de memory_limit, límites de peticiones o reglas de servidor sin entender cómo afectan a tu entorno. Una configuración improvisada puede interrumpir subidas, formularios o procesos legítimos sin resolver todos los caminos del fallo.

La secuencia correcta es:

1. Aplicar el paquete corregido.
2. Reiniciar los procesos que cargan PHP.
3. Verificar la versión efectiva en la web.
4. Mantener WAF y límites razonables como capas adicionales.

Qué comprobar después de actualizar PHP

No des el trabajo por terminado cuando el panel muestre otro número. Haz una comprobación corta pero completa:

• Abre la portada y varias páginas sin haber iniciado sesión.
• Entra en la administración de WordPress.
• Envía un formulario real y confirma su recepción.
• Prueba compra, pago o reserva si existen.
• Ejecuta tareas programadas importantes y revisa correos transaccionales.
• Comprueba la API, webhooks y plugins que conectan servicios externos.
• Revisa errores de PHP, Apache/Nginx y del hosting.
• Vacía cachés solo cuando entiendas cuáles intervienen.

Actualizar PHP puede descubrir plugins antiguos o código propio incompatible. Eso no justifica mantener un runtime sin soporte: indica que la deuda de mantenimiento ya existía y necesita un plan.

Cuándo hay que investigar una posible intrusión

Actualizar corrige el código vulnerable a partir de ese momento, pero no demuestra que antes no hubiera actividad. Si el servidor estuvo expuesto con una versión afectada, conserva los registros antes de rotarlos y busca ayuda especializada cuando aparezcan señales como:

• usuarios administradores o claves que nadie reconoce;
• archivos PHP nuevos o modificados sin despliegue conocido;
• tareas programadas, procesos o conexiones salientes inesperadas;
• redirecciones, contenido inyectado o cambios en el comportamiento;
• picos anómalos de errores, memoria, CPU o peticiones multipart;
• alertas del hosting, EDR, WAF o proveedor cloud.

No borres archivos sospechosos antes de conservar evidencias. Tampoco uses una ausencia de indicadores simples como prueba de que no hubo compromiso. Un análisis forense requiere acceso al sistema, registros y contexto que una página pública no puede proporcionar.

La lección no termina en este parche

PHP2Shell deja al descubierto un problema habitual: muchas webs tienen responsable de contenido, pero nadie sabe quién mantiene el runtime, las copias, las dependencias o la respuesta ante una incidencia. Esa responsabilidad debe acordarse al construir la web, no durante una alerta crítica.

Cuando planteo una web profesional, la elección entre WordPress, Astro u otra solución parte de quién necesita editar, qué funciones existen y quién asumirá el mantenimiento. Una arquitectura con menos piezas no elimina el riesgo, pero puede reducir responsabilidades que el proyecto no tiene capacidad de sostener.

Ver cómo planteo una web personalizada y su mantenimiento.

Para ampliar el contexto puedes seguir con la guía de seguridad web para desarrolladores y la lista de comprobaciones antes de publicar una web.

Fuentes y registro de actualización

Fuentes principales utilizadas:

• Aviso oficial del proyecto PHP, 21 de octubre de 2026.
• CVE-2026-109618: RCE via OOM corruption.
• CVE-2026-109619: RCE via stale global state.
• Aviso oficial de WordPress sobre la actualización de PHP.
• Comunicado conjunto publicado por ENISA.
• Información operativa mantenida por NCSC-NL.

22 de octubre de 2026: publicación inicial. Versiones corregidas y alcance contrastados con los avisos anteriores. Actualizaré esta sección si cambia la recomendación oficial o aparecen nuevas ramas corregidas.