PHP2Shell, qué es y cómo saber si tu sitio está expuesto

El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas que permiten ejecutar código en un servidor sin necesidad de credenciales. Este artículo resume lo que se sabe de ellas, qué versiones afectan y cómo comprobar con certeza si tu sitio necesita intervención.

Lo que se sabe de las dos fallas

PHP2Shell es el nombre con el que se conocen las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, ambas calificadas con 9.2 sobre 10 en la escala CVSS v4.0, un puntaje que solo reciben los problemas que combinan facilidad de explotación con un impacto total sobre el sistema afectado.

Lo que las hace especialmente delicadas es su ubicación dentro del propio intérprete de PHP. Al tratarse de errores del lenguaje y no de un componente añadido, cualquier aplicación que corra sobre una versión vulnerable queda expuesta, por sencilla que sea y sin importar si usa WordPress, Laravel o código escrito a mano. Los fallos aparecen en la forma en que PHP gestiona ciertos errores fatales, sobre todo los de memoria insuficiente, e involucran el seguimiento del progreso de subida de archivos en el módulo de sesiones y la memoria compartida de OPcache. Encadenados, permiten que un atacante sin cuenta en el sitio termine ejecutando código propio en el servidor.

El hallazgo corresponde al equipo de investigación de Wiz, que trabajó apoyado en modelos de inteligencia artificial y demostró el ataque contra instalaciones actuales de WordPress, Drupal y Joomla. Como además se reportaron intentos de explotación anteriores al anuncio público, la ventana para actualizar antes de recibir tráfico malicioso es mucho más corta de lo habitual.

Qué versiones están afectadas

Prácticamente todas las versiones publicadas desde PHP 5.4 son vulnerables. La tabla resume, para cada rama con soporte, la última versión afectada y la primera que incluye la corrección.

Las ramas 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP. Hay correcciones adaptadas para 7.4, 8.0 y 8.1, aunque aplicarlas obliga a compilar el intérprete o a depender de un proveedor que las haya incorporado en sus paquetes. En un sitio en producción conviene tratarlas como una medida transitoria mientras se planifica la migración a una rama con soporte vigente.

Conviene tener presente que distribuciones como Debian, Ubuntu o Red Hat suelen incorporar la corrección en paquetes que conservan un número de versión anterior, de modo que un servidor que reporta una versión aparentemente vulnerable puede estar protegido. Antes de concluir nada hay que revisar el registro de cambios del paquete instalado y confirmar que menciona los dos identificadores CVE.

Cómo revisar la versión que realmente sirve tu sitio

Muchos diagnósticos fallan porque se revisa una versión distinta de la que atiende las visitas. Es frecuente que un servidor tenga varias versiones de PHP instaladas a la vez, y la que responde en la línea de comandos no tiene por qué coincidir con la que ejecuta el sitio a través de PHP-FPM o del módulo de Apache.

Con acceso al servidor, php -v sirve como primera referencia, pero la confirmación está en la configuración del pool de PHP-FPM o del virtual host correspondiente. Un archivo temporal que contenga <?php phpinfo();, publicado en el mismo sitio, muestra la versión exacta que procesa las peticiones; debe eliminarse en cuanto se haya consultado, porque expone detalles de la configuración que no deben quedar públicos.

Cuando solo se dispone de la URL, algunas configuraciones revelan la versión en la cabecera X-Powered-By de la respuesta HTTP. Muchas otras la ocultan deliberadamente, y en ese caso el resultado debe tratarse como desconocido y no como una señal de que el sitio está a salvo. En los hostings administrados, el panel de control suele indicar la versión de PHP asignada a cada dominio, y lo prudente es pedir al proveedor una confirmación por escrito de que ya aplicó el parche del 21 de octubre.

En servidores Debian o Ubuntu con varias versiones de PHP 8 instaladas, la actualización habitual se hace con estos comandos.

sudo apt update
sudo apt install --only-upgrade 'php8.*'

Terminada la actualización hay que reiniciar PHP-FPM o el servidor web, porque los procesos que ya estaban en ejecución mantienen cargado en memoria el binario anterior y seguirán atendiendo peticiones con el código vulnerable hasta que se reinicien.

Si no puedes actualizar hoy

Aplicar el parche oficial es la remediación definitiva, y todo lo demás debe entenderse como una forma de ganar tiempo. Si el sitio pasa por proveedores de red o de nube como Cloudflare, Fastly, Vercel o Google, vale la pena verificar que estén activas las reglas de protección que publicaron para PHP2Shell. Algunos equipos optaron además por desactivar temporalmente session.upload_progress en la configuración de PHP, lo que cierra una de las vías de ataque aunque no deja el intérprete corregido. Mientras tanto, restringir el acceso público a paneles administrativos y aplicaciones internas reduce la superficie expuesta.

Señales de que alguien lo intentó

Dado que hubo intentos de explotación antes del anuncio, es recomendable revisar los registros del servidor al menos desde mediados de octubre. Los investigadores asocian estos ataques con peticiones de subida de archivos poco habituales seguidas de errores por límite de memoria, ráfagas de respuestas HTTP 500, cookies PHPSESSID de tamaño o formato anómalo y procesos de PHP que se reinician sin causa aparente. Cada uno de estos indicios puede tener explicaciones inocentes, pero su coincidencia en el mismo periodo es motivo suficiente para una revisión forense del servidor.

Versiones sin soporte y gestión de actualizaciones

Este incidente pone en evidencia un problema que venía de antes, y es la cantidad de sitios que siguen operando sobre versiones de PHP sin soporte, para las cuales no existe un parche oficial cuando aparece una falla de esta gravedad. PHP 8.2 dejará de recibir correcciones de seguridad el 31 de diciembre de 2026, por lo que quienes estén en esa rama tienen poco más de dos meses para planificar la migración a 8.3 o a una versión posterior.

Las organizaciones que responden bien a este tipo de anuncios suelen tener un inventario de las versiones que corren en cada servidor, un calendario de actualizaciones y una persona responsable de seguir los boletines de seguridad. Con esa disciplina, una alerta como PHP2Shell se resuelve en horas y no en semanas.

Fuentes
The Hacker News, parches de emergencia de PHP para PHP2Shell
Wiz Research, análisis técnico de PHP2Shell
Datadog Security Labs, detección y remediación de PHP2Shell
Herramienta de verificación php2shell-checker

Imágenes generadas con IA.