Una versión de PHP que parece vulnerable no siempre cuenta toda la historia. En octubre de 2026 consulté a BanaHosting por PHP2Shell. La respuesta ilustra una diferencia importante: el número que muestra WordPress no siempre revela qué corrección contiene el paquete del servidor.

PHP2Shell no es un fallo de WordPress que se resuelva actualizando un plugin. Afecta al intérprete PHP que atiende el sitio; en un hosting compartido quizá no tengas acceso al paquete que ejecuta el proveedor.

Qué es PHP2Shell

PHP2Shell es el nombre informal de dos vulnerabilidades críticas divulgadas el 21 de octubre de 2026: CVE-2026-109618 y CVE-2026-109619. El aviso oficial de PHP indica que pueden permitir ejecución remota de código sin autenticación.

  • CVE-2026-109618: si PHP se queda sin memoria durante una petición, puede dejar parte de su estado interno a medio preparar y manejarlo mal al cerrar esa petición.
  • CVE-2026-109619: un worker puede conservar una referencia a datos de una petición anterior, incluso después de liberar esa memoria, y usarla al procesar otra petición.

PHP considera afectadas las instalaciones que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo y las condiciones de explotación varían según el servidor y la configuración; PHP demostró un ataque especialmente directo en mod_php. «PHP2Shell» es un nombre informal, no el nombre oficial de los avisos.

Versiones corregidas

El proyecto PHP publicó estas versiones corregidas para las ramas mantenidas:

Rama Primera versión corregida
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

Las versiones anteriores de esas ramas deben considerarse afectadas si el proveedor no confirma que su paquete incluye el arreglo. PHP 8.1 y anteriores ya no reciben versiones oficiales corregidas del proyecto, aunque PHP publicó parches mínimos de código fuente para 7.4, 8.0 y 8.1. En esas ramas, depende de cada distribución o proveedor incorporarlos y mantenerlos.

PHP 8.3.35 en WordPress: el ejemplo de BanaHosting

Según la respuesta privada que recibí, BanaHosting puede mostrar PHP 8.3.35 en WordPress aunque afirme haber incorporado al paquete de CloudLinux la corrección publicada por PHP en 8.3.36. El proveedor atribuyó esa diferencia a un backport: llevar el arreglo a un paquete que conserva su número base anterior.

Eso describe lo que BanaHosting dijo sobre sus propios entornos; no es una auditoría independiente ni una garantía para cualquier servidor que muestre 8.3.35. Ese mismo número, sin confirmación del proveedor, no demuestra que la instalación tenga el parche. CloudLinux también explica que algunos paquetes conservan una versión base anterior tras recibir una corrección y recomienda comprobar el paquete y su registro de cambios (estado y guía de CloudLinux).

Un backport es precisamente eso: aplicar una corrección a un paquete anterior sin cambiar necesariamente el número principal que comunica PHP. Por eso una versión visible antigua no confirma ni descarta el parche. En servidores CloudLinux administrados por ti, el registro de cambios del paquete puede servir para verificarlo; en hosting compartido, pídele esa confirmación al proveedor.

Cómo comprobar el PHP de tu sitio

En cPanel

En Software → MultiPHP Manager, busca el dominio. cPanel muestra la versión asignada al virtual host y si hereda la configuración predeterminada (documentación de MultiPHP Manager). Algunos hostings ofrecen Select PHP Version en su lugar.

Ese es el PHP configurado para el sitio. No lo confundas con el PHP que cPanel usa internamente para sus propias interfaces y servicios: esa versión no identifica el runtime del dominio. Tampoco la versión de MultiPHP permite verificar por sí sola un backport.

En WordPress

Ve a Herramientas → Salud del sitio → Información → Servidor. WordPress muestra la versión de PHP que atiende esa instalación (documentación de Salud del sitio). Sirve para identificar el runtime web, pero no para comprobar el historial de parches del paquete.

Desde una terminal

Con acceso SSH puedes ejecutar:

php -v

El comando muestra la versión del PHP de línea de comandos (manual de PHP). Puede ser distinto del asignado al dominio; en cPanel también pueden coexistir varios binarios. No uses ese resultado como prueba del PHP que atiende WordPress ni del estado del backport.

Evita dejar un archivo phpinfo() accesible públicamente: expone detalles del servidor y tampoco demuestra qué cambios de seguridad contiene el paquete.

Qué pedirle al proveedor

Si el proveedor no confirma los parches, considera el estado no verificado, no automáticamente vulnerable ni protegido. Pregunta por escrito si el paquete asignado a tu dominio incluye CVE-2026-109618 y CVE-2026-109619, qué paquete o rama está usando, cuándo aplicaron la corrección y si reiniciaron los workers PHP. Si habla de backport, pide la revisión del paquete o el registro de cambios que lo respalda.

Si no puede confirmarlo, solicita que actualice el paquete o que te indique una rama corregida compatible para tu sitio. Un WAF o una respuesta genérica de «estamos protegidos» no sustituye esa confirmación.

Un WAF ayuda, pero no corrige PHP

Un firewall de aplicaciones web puede bloquear patrones de ataque conocidos. CloudLinux describe las reglas de Imunify360 como una mitigación temporal: el código vulnerable sigue instalado y las reglas no necesariamente cubren otras variantes.

BanaHosting también me indicó que usa Imunify360, que aplicó una medida preventiva de configuración y que sus revisiones no hallaron indicios de explotación. No especificó el cambio ni compartió registros o una auditoría. Son declaraciones del proveedor, no una comprobación independiente. PHP señala que instalar una versión o paquete que incluya la corrección es la solución completa.

Planifica la migración de ramas sin soporte

Un backport puede corregir este problema puntual, pero no devuelve el mantenimiento regular a una rama fuera de soporte. PHP 8.2, por ejemplo, tenía soporte de seguridad hasta el 31 de diciembre de 2026; PHP 8.1 y anteriores ya estaban fuera del soporte regular al divulgarse estos CVE (versiones con soporte).

Si dependes de una rama antigua, planifica y prueba la migración con tu WordPress, temas y extensiones antes de cambiar producción.

En resumen

Comprueba qué PHP atiende tu dominio, pero no juzgues la protección solo por el número visible. Pide al hosting confirmación del paquete y de ambos CVE; si no puede respaldarla, solicita una actualización o una ruta de migración. Mantén los WAF como defensa adicional, no como sustituto del parche.

Fuentes

La consulta y respuesta de BanaHosting citadas arriba fueron privadas y no tienen una URL pública. Se presentan como testimonio de soporte recibido en octubre de 2026, no como fuente técnica independiente.