PHP2Shell: dos fallos críticos en PHP y cómo proteger tu servidor

Dos vulnerabilidades críticas en el núcleo de PHP han puesto en alerta a quienes administran servidores y páginas web. Publicadas el 21 de octubre de 2026 y agrupadas bajo el nombre PHP2Shell, las fallas CVE-2026-109618 y CVE-2026-109619 pueden permitir ejecución remota de código sin que el atacante tenga una cuenta ni necesite iniciar sesión. El problema no depende necesariamente de un plugin vulnerable o de una línea defectuosa del sitio: afecta al propio entorno que ejecuta PHP.

La respuesta prioritaria es actualizar PHP a una versión corregida y reiniciar los procesos que lo mantienen cargado. Si administras una web en un hosting compartido, lo normal será pedir al proveedor que confirme la versión efectiva y aplique la actualización. Si gestionas el servidor, debes inventariar todas las instalaciones, parchear cada runtime y comprobar si hubo señales de compromiso antes de dar el incidente por cerrado.

Este artículo resume lo que se conoce a fecha de 22 de octubre de 2026, diferencia el riesgo técnico de las medidas prácticas y evita confundir una vulnerabilidad crítica con la afirmación de que todas las webs han sido atacadas.

Qué es PHP2Shell y por qué preocupa

PHP es un lenguaje de programación muy utilizado para generar páginas dinámicas y ejecutar aplicaciones web. WordPress, Drupal, Joomla y muchas otras plataformas dependen de él, pero el alcance de PHP2Shell no se limita a un gestor de contenidos concreto. Las vulnerabilidades se encuentran en componentes internos del runtime, de modo que una aplicación sencilla también puede quedar expuesta si se ejecuta sobre una versión vulnerable y recibe solicitudes HTTP.

PHP2Shell es el nombre utilizado para referirse a dos fallos relacionados, identificados como CVE-2026-109618 y CVE-2026-109619. PHP les asigna una puntuación de 9,2 sobre 10 según CVSS 4.0, dentro de la categoría crítica. Los avisos describen escenarios en los que una petición especialmente construida puede provocar ejecución remota de código o exposición de información sensible de la memoria del proceso.

Conviene interpretar con precisión la expresión «sin credenciales». En las pruebas publicadas, el atacante no necesita autenticarse en la aplicación ni obtener una cuenta legítima antes de intentar explotar los fallos. Eso no significa que cualquier petición funcione siempre en cualquier configuración, ni que todos los servidores tengan idéntica probabilidad de explotación: influyen la versión, la forma en que PHP está integrado en el servidor y otros detalles del entorno.

Los dos fallos: qué se sabe técnicamente

CVE-2026-109618: corrupción durante un error de memoria

El primer fallo está relacionado con la gestión de errores de memoria insuficiente, conocida como out of memory (OOM). En determinadas circunstancias, PHP puede interrumpir el procesamiento de una solicitud mientras algunos datos internos todavía no se han inicializado correctamente. Durante la limpieza posterior, otra parte del runtime puede tratar ese estado incompleto como si fuera válido.

El problema pertenece a una familia de errores de seguridad de memoria. Si el estado interno se corrompe en condiciones controladas por una solicitud remota, el proceso puede acabar ejecutando operaciones no previstas. El aviso de PHP identifica esta vulnerabilidad como CVE-2026-109618 y recomienda instalar una versión corregida; no es un fallo que se solucione cambiando el código de una página concreta.

CVE-2026-109619: estado global que conserva una referencia obsoleta

El segundo fallo se relaciona con datos globales que, durante el procesamiento de una petición, pueden apuntar a memoria perteneciente a esa solicitud. En determinadas secuencias, una referencia puede seguir existiendo después de que la memoria correspondiente se haya liberado. Si una operación posterior consulta ese estado antes de inicializarlo de nuevo, puede acceder a información que ya no debería utilizar.

Este patrón suele describirse como use-after-free: el programa utiliza una referencia a memoria cuyo ciclo de vida ya ha terminado. El aviso CVE-2026-109619 señala que determinadas rutas del procesamiento de solicitudes, incluidas funciones vinculadas al progreso de las cargas, pueden intervenir en el problema. La corrección debe aplicarse en PHP; desactivar una función concreta no constituye una solución universal.

Ambos fallos son distintos, aunque comparten un riesgo general: una petición remota puede influir en el estado interno del proceso que ejecuta PHP. La consecuencia más grave demostrada es la ejecución remota de código con los permisos de ese proceso. También se ha documentado la posibilidad de exponer fragmentos de memoria que podrían contener datos sensibles, dependiendo del caso.

PHP2Shell agrupa dos vulnerabilidades distintas en el runtime de PHP.

Qué servidores y versiones están afectados

El aviso oficial del equipo de PHP indica que el riesgo alcanza a las instalaciones que sirven solicitudes web, entre ellas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. La documentación oficial considera especialmente preocupante el escenario con mod_php, donde se ha demostrado que una petición no autenticada puede activar el ataque antes de que se ejecute el código de la aplicación. En ese escenario, una comprobación dentro de WordPress o de otro CMS no puede impedir que el runtime vulnerable falle primero.

Las notas de seguridad de CVE-2026-109618 y el aviso de CVE-2026-109619 identifican las correcciones publicadas el 21 de octubre de 2026. Las versiones corregidas son:

• PHP 8.5.12 o posterior dentro de la rama 8.5.
• PHP 8.4.27 o posterior dentro de la rama 8.4.
• PHP 8.3.36 o posterior dentro de la rama 8.3.
• PHP 8.2.35 o posterior dentro de la rama 8.2.

Estas cifras corresponden a las versiones oficiales publicadas por PHP. En sistemas operativos y servicios gestionados puede haber paquetes con parches retroportados por el distribuidor, de modo que el número mostrado no siempre coincide exactamente con la versión upstream. En ese caso, el administrador debe comprobar el aviso de seguridad del proveedor del sistema operativo o del hosting, no asumir que el equipo está desprotegido solo por ver un número distinto.

PHP 8.1 y las ramas anteriores están fuera de soporte oficial y no reciben necesariamente una versión nueva del proyecto principal. Algunos distribuidores pueden publicar correcciones propias o retroportadas, pero no debe darse por hecho. Si el servidor depende de una rama sin soporte, hay que acordar una migración a una versión mantenida; mientras tanto, el proveedor debe aclarar por escrito qué parche se ha aplicado y qué cobertura ofrece.

¿Una web WordPress está en peligro aunque no tenga plugins vulnerables?

Sí, puede estar expuesta si el servidor ejecuta una versión vulnerable de PHP. En este caso, el defecto se encuentra en el runtime y no requiere que exista un plugin específico con un fallo propio. Eso no implica que WordPress, Drupal o Joomla sean por sí mismos la causa del problema: son ejemplos de aplicaciones que pueden utilizar el entorno afectado.

Actualizar el CMS, cambiar la contraseña del administrador o instalar un plugin de seguridad no sustituye la actualización de PHP. Esas medidas pueden seguir siendo importantes para la seguridad general, pero no corrigen el código vulnerable del intérprete. Tampoco es suficiente que el panel de WordPress indique que todo está actualizado si el PHP que ejecuta las peticiones continúa en una versión afectada.

Para una web profesional, el punto decisivo es averiguar qué runtime atiende realmente el tráfico. La guía interna sobre seguridad de WordPress en 2026 amplía las medidas generales de mantenimiento que conviene mantener junto a este parche. Puede existir una versión de PHP para la línea de comandos y otra distinta en el servidor web. Además, un mismo alojamiento puede contener varias webs, subdominios, contenedores o pools de PHP-FPM con versiones y configuraciones diferentes. La comprobación debe abarcar todas las rutas, no solo el sitio principal.

Qué debe hacer el propietario de una web en un hosting compartido

Si no administras el sistema operativo ni tienes acceso a PHP-FPM o Apache, no intentes instalar manualmente componentes del servidor desde el panel de WordPress. El proveedor de alojamiento es quien puede confirmar y cambiar la versión del runtime que atiende las peticiones. Contacta con soporte y solicita una respuesta concreta sobre PHP2Shell, las CVE afectadas y la versión corregida que está activa para tu cuenta.

1. Comprueba la versión activa. En WordPress, revisa Herramientas → Salud del sitio → Información → Servidor, si el panel muestra ese dato. También puedes consultarlo en el panel del hosting. No publiques capturas que revelen rutas privadas, nombres internos o información de la cuenta.
2. Pregunta por el parche, no solo por el número. Si el proveedor usa paquetes propios, pídele que confirme si el paquete incluye las correcciones para CVE-2026-109618 y CVE-2026-109619.
3. Solicita la actualización del runtime. Si la versión es vulnerable, pide que la cambien a una versión corregida compatible con tu web. Antes de un cambio de rama mayor, revisa compatibilidad con el CMS, el tema y los plugins; una actualización de seguridad dentro de una rama mantenida suele ser menos disruptiva, pero debe probarse.
4. Confirma que los procesos se han reiniciado. El parche debe estar cargado en los procesos que sirven las peticiones. Pregunta al proveedor si ha reiniciado o recargado los servicios necesarios.
5. Pide una revisión si el servidor estuvo expuesto. Si la instalación permaneció vulnerable desde antes de la divulgación pública, pregunta si el proveedor ha revisado indicadores de compromiso y registros. Instalar el parche evita la explotación futura de esos fallos, pero no elimina por sí mismo una posible intrusión anterior.

Si el proveedor no puede aplicar la corrección inmediatamente, solicita una estimación clara y medidas temporales concretas. La alerta de NHS England Digital recomienda valorar la retirada temporal del servicio vulnerable de Internet hasta poder parchearlo, según el riesgo y las necesidades del negocio. Un cortafuegos de aplicaciones web puede reducir parte del tráfico malicioso, pero no debe presentarse como sustituto del parche.

Qué debe hacer el administrador del servidor

En un servidor propio, la respuesta requiere inventario, actualización y verificación posterior. Empieza por identificar todas las instalaciones de PHP, incluidas las que no están vinculadas al sitio más visible. Revisa paquetes del sistema operativo, contenedores, máquinas virtuales, entornos de pruebas, servidores de integración y servicios de terceros que incorporen PHP.

1. Identificar todas las instancias

Consulta la versión del runtime usado por cada servicio web y contrástala con el gestor de paquetes y el aviso del proveedor. No te limites a ejecutar php -v en una consola: esa orden muestra la versión de CLI y puede no representar la versión usada por Apache, PHP-FPM, un contenedor o un panel de hosting. Comprueba los pools y servicios activos, así como los mapeos de dominios a versiones.

2. Aplicar una actualización oficial o del distribuidor

Instala el paquete corregido de la rama que utilices mediante el canal de actualización mantenido por PHP, tu distribución o el proveedor. Evita descargar binarios de fuentes desconocidas o compilar una versión improvisada en producción sin un proceso de validación. Si la rama está fuera de soporte, planifica la migración a una rama mantenida y confirma qué cobertura temporal ofrece el distribuidor.

3. Recargar los procesos correctos

Después de actualizar, verifica que los procesos que atienden tráfico hayan cargado la biblioteca o el ejecutable corregido. Dependiendo de la arquitectura, puede ser necesario reiniciar o recargar PHP-FPM, Apache, FrankenPHP, LiteSpeed o los contenedores correspondientes. Un archivo actualizado en disco no garantiza por sí solo que los procesos antiguos hayan dejado de ejecutarse.

4. Verificar desde fuera y desde dentro

Revisa la versión efectiva que informa el entorno, el estado de los servicios y los registros de inicio. Comprueba que las páginas principales, formularios, cargas de archivos, tareas programadas y operaciones de la aplicación funcionan con normalidad. Si existe un balanceador o varios nodos, verifica todos ellos: parchear un único servidor deja abierta la exposición en los demás.

5. Registrar el cambio

Documenta qué servidores se han revisado, la versión anterior, el paquete aplicado, la hora de la actualización, los servicios reiniciados y las comprobaciones realizadas. Este registro facilita demostrar que el incidente se ha tratado de forma ordenada y ayuda a detectar instancias que hayan quedado fuera del proceso.

La mitigación exige instalar el parche y confirmar que los procesos utilizan la versión corregida.

Cómo investigar un posible compromiso

La actualización es urgente, pero no demuestra que el servidor esté limpio. La divulgación pública de detalles técnicos suele aumentar el interés de atacantes, y equipos como Cloudflare han descrito medidas de protección desplegadas ante la posibilidad de explotación rápida. A fecha de este artículo, la información disponible incluye informes de intentos tempranos y una expectativa elevada de explotación; eso no permite concluir que una instalación concreta haya sido atacada.

Busca anomalías en los registros de servidor web, PHP y sistema alrededor del periodo de exposición. Son señales que merecen investigación los errores de memoria repetidos, procesos PHP que terminan de forma anormal, ráfagas inusuales de solicitudes POST con formularios multipart y actividad que no encaja con el uso habitual del sitio. Ninguna señal aislada confirma por sí sola PHP2Shell; es necesario correlacionar tiempos, origen de las solicitudes, procesos y cambios del sistema.

Revisa también modificaciones inesperadas en el directorio web, nuevos archivos PHP que no correspondan a una actualización conocida, tareas programadas desconocidas, cuentas añadidas y procesos secundarios que no formen parte del funcionamiento habitual. Una intrusión podría permanecer dentro del propio proceso PHP y no generar necesariamente un proceso externo llamativo, por lo que la ausencia de una alerta del antivirus o del EDR no es prueba concluyente de que no haya ocurrido nada.

Si encuentras indicios razonables de ejecución no autorizada, conserva los registros, limita el acceso del sistema afectado y activa el procedimiento de respuesta a incidentes. Evita borrar archivos o reconstruir el servidor antes de preservar la evidencia necesaria. Según el alcance, puede ser necesario restaurar desde una copia conocida como limpia, rotar credenciales y secretos accesibles desde el servidor, revisar persistencia y determinar si se han consultado datos personales.

Si se sospecha que se han expuesto datos personales, la organización debe valorar sus obligaciones legales y los plazos de notificación aplicables con su responsable de privacidad o asesoría. No conviene afirmar que existe una brecha de datos solo porque el servidor era vulnerable; la decisión debe basarse en la investigación y en la evidencia disponible.

Medidas temporales y controles que no bastan por sí solos

Los avisos oficiales son claros en lo esencial: actualizar PHP es la corrección completa. Las reglas de un WAF, las restricciones de carga de archivos, la reducción de exposición de endpoints y la monitorización pueden ayudar a reducir el riesgo durante la respuesta, pero no reemplazan el parche. Además, algunas rutas de ataque pueden afectar a solicitudes dirigidas a URLs que no parecen relacionadas con la función vulnerable.

No desactives opciones al azar ni copies configuraciones encontradas en redes sociales sin entender sus consecuencias. Cambiar límites de memoria, bloquear todas las solicitudes multipart o desactivar funciones de carga puede interrumpir formularios, tiendas y otros procesos legítimos, y no garantiza cubrir ambas vulnerabilidades. Si el parche no puede aplicarse de inmediato, el administrador debe realizar una evaluación local y decidir si limita o desconecta temporalmente el servicio expuesto.

Una vez corregido el fallo, conserva las defensas de base: permisos mínimos para el usuario del servicio web, separación entre sitios y servicios, secretos fuera del directorio público, copias de seguridad probadas, registros centralizados y un proceso de actualización de seguridad. Para entornos que incorporan automatización, también resulta útil revisar la guía sobre permisos mínimos y control de acciones. Estas medidas no evitan todas las vulnerabilidades del runtime, pero reducen el impacto de una intrusión y hacen más fácil detectar y recuperar el servicio.

Checklist rápido para hoy

• Inventariar todos los servidores, dominios, contenedores y servicios que ejecutan PHP.
• Identificar la versión que atiende realmente las solicitudes web.
• Actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o confirmar el parche retroportado oficial del proveedor.
• Planificar la migración de ramas sin soporte, especialmente PHP 8.1 y anteriores.
• Reiniciar o recargar los procesos necesarios y verificar cada nodo del servicio.
• Revisar logs, procesos, archivos y cuentas si hubo exposición durante el periodo vulnerable.
• Rotar credenciales y secretos si la investigación indica posible acceso no autorizado.
• Documentar la corrección y confirmar por escrito el estado con el hosting o el equipo responsable.

Qué significa PHP2Shell para una web profesional

La lección principal es que la seguridad de una web no termina en el CMS, el tema o los plugins. La aplicación depende de capas inferiores —PHP, servidor web, sistema operativo, bibliotecas y configuración— y una vulnerabilidad en una de ellas puede atravesar las protecciones de la capa superior. Por eso el mantenimiento debe incluir tanto el sitio como el servicio de alojamiento que lo ejecuta.

Para los propietarios de webs, la acción más útil es pedir confirmación verificable al proveedor y no asumir que el problema está resuelto porque WordPress muestra sus componentes al día. Para los administradores, la prioridad es aplicar los paquetes corregidos a todas las instancias y comprobar la posible exposición previa. Si necesitas ayuda con el mantenimiento técnico de una web profesional, conviene separar las tareas de aplicación —WordPress, temas y plugins— de las que corresponden al servidor, para que cada responsable pueda confirmar qué ha revisado.

Preguntas frecuentes

¿PHP2Shell afecta solo a WordPress?

No. WordPress es una de las aplicaciones que pueden ejecutarse sobre PHP, pero el fallo se encuentra en el propio runtime. También puede afectar a Drupal, Joomla y aplicaciones desarrolladas a medida si utilizan una instalación vulnerable.

¿Es necesario tener una cuenta para explotar estas vulnerabilidades?

Las pruebas descritas en los avisos públicos muestran escenarios de explotación remota sin autenticación. Los requisitos y la fiabilidad pueden variar según la vulnerabilidad y la configuración del servidor, por lo que no debe interpretarse como que cualquier petición garantiza el control de cualquier instalación.

¿Actualizar WordPress o instalar un plugin de seguridad lo soluciona?

No. Hay que actualizar el runtime PHP o instalar el paquete corregido del distribuidor. Los plugins de seguridad y las actualizaciones de WordPress son medidas complementarias, no un sustituto de la corrección del núcleo de PHP.

¿Qué versión debo instalar?

Según el aviso oficial del 21 de octubre de 2026, las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. En sistemas gestionados por distribuidores, comprueba si el paquete incluye un parche retroportado y sigue la recomendación del proveedor.

¿Si ya he actualizado, tengo que hacer algo más?

Debes confirmar que los procesos están usando la versión corregida y que no queda ninguna instancia expuesta. Si el servidor estuvo vulnerable, revisa registros e indicadores de compromiso; el parche evita el uso de la vulnerabilidad, pero no elimina una posible persistencia creada anteriormente.

¿Un WAF puede proteger mi web mientras espero?

Puede reducir parte del tráfico malicioso si dispone de reglas específicas, pero no es una solución completa. Si no puedes parchear de inmediato, consulta al proveedor y valora aislar temporalmente el servicio expuesto según el riesgo.