PHP2Shell: qué versiones de PHP están corregidas y cómo comprobar la suya

En octubre de 2026 el proyecto PHP corrigió 2 vulnerabilidades críticas que pueden permitir a un atacante ejecutar código en un servidor sin iniciar sesión. CISA las denomina "php2shell". Están registradas como CVE-2026-109618 y CVE-2026-109619, y ambas tienen una puntuación de 9,2 en CVSS v4.0. Si alguna parte del servicio en línea de su empresa funciona con PHP, la medida es sencilla: asegúrese de que utiliza PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 o una versión posterior, o bien una compilación del proveedor que incluya la corrección.

En este artículo explicamos qué se ha corregido, qué versiones incluyen la corrección, cómo averiguar qué versión indica su servidor y qué preguntar a quienes gestionan su hosting. También puede comprobar qué versión de PHP indica su sitio web en pocos segundos.

Qué es PHP2Shell

El aviso de seguridad de PHP del 21 de octubre de 2026 describe 2 fallos en la forma en que PHP gestiona los datos internos de las peticiones:

• CVE-2026-109618, corrupción de memoria al agotarse la memoria. Cuando PHP se queda sin memoria, puede interrumpirse mientras los datos internos de la petición solo están inicializados en parte, y la limpieza posterior puede tratar datos no válidos como si fueran válidos.
• CVE-2026-109619, estado obsoleto de la petición. El estado interno que pertenece a una petición puede sobrevivir después de que se haya liberado su memoria, y una petición posterior atendida por el mismo proceso puede llegar a utilizarlo.

Ambos fallos pueden permitir la ejecución remota de código sin autenticación. Según el aviso, se ven afectadas todas las instalaciones de PHP que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera mod_php el caso de mayor riesgo, porque una petición puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación. Esto también significa que la aplicación que funciona por encima (WordPress, una tienda en línea, un portal a medida) no le protege por sí sola: la corrección está en PHP.

Versiones corregidas y cronología

• 21 de octubre de 2026: el proyecto PHP publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 con la corrección. Ese mismo día, el CSIRT nacional eslovaco SK-CERT publicó una advertencia y CISA emitió una alerta.
• 26 de octubre de 2026: CISA añadió ambos CVE a su catálogo de vulnerabilidades explotadas conocidas (Known Exploited Vulnerabilities), la lista de vulnerabilidades con indicios de explotación real.

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP (consulte las versiones con soporte). El aviso señala que algunas distribuciones de Linux y proveedores de soporte a largo plazo trasladan las correcciones a versiones antiguas (backport), y que el equipo de seguridad de PHP publicó backports mínimos del código fuente para 7.4, 8.0 y 8.1 destinados a quienes compilan PHP por su cuenta. Si su servicio utiliza una de estas ramas, pregunte a su proveedor si incluye la corrección y planifique el paso a una rama con soporte.

Cómo averiguar qué versión de PHP utiliza

La respuesta definitiva la da el propio servidor, no una comprobación desde fuera:

• Pregunte a quien gestiona el servicio (su proveedor de hosting, agencia o departamento de TI) por la versión exacta de PHP y si incluye las correcciones del 21 de octubre.
• Si tiene acceso por terminal, ejecute php -v. El servidor web puede usar un binario de PHP distinto al de la línea de comandos, así que compruebe también la versión en el panel de su hosting o en el pool de PHP-FPM.
• Los gestores de paquetes muestran las compilaciones del proveedor: en Debian y Ubuntu dpkg -l | grep php, en RHEL y sistemas similares rpm -qa | grep php. Compare la versión del paquete con el aviso de seguridad de su proveedor, ya que los proveedores suelen mantener el número de versión original y añadir la corrección.

Desde fuera, algunos servidores anuncian su versión en las cabeceras de respuesta HTTP:

X-Powered-By: PHP/8.3.12
Server: Apache/2.4.62 (Debian)

Puede ver sus propias cabeceras con curl -sI https://www.example.com/. Nuestra comprobación de PHP2Shell lee esas mismas 2 cabeceras, X-Powered-By y Server, y compara el número con las versiones corregidas.

Qué puede decirle la cabecera y qué no

Interprete la cabecera con cuidado, en ambos sentidos:

• Un número antiguo no demuestra que el servidor sea vulnerable. Muchos proveedores de hosting aplican la corrección a nivel de sistema y mantienen la cadena de versión original.
• Un número actual es una buena señal, no una prueba. La cabecera puede modificarse o la puede establecer un proxy situado delante del servidor.
• Sin número no hay información. La mayoría de los servidores no envían su versión de PHP. Cuando analizamos 8.221 dominios de empresas eslovacas el 31 de octubre de 2026, solo 332 de los 8.171 que respondieron indicaban una versión de PHP en sus cabeceras (4,1 %). En el resto, la cabecera no dice nada en ningún sentido, y la pregunta debe dirigirse a quien gestiona el servicio.

Qué hacer ahora

1. Actualice PHP a 8.2.35, 8.3.36, 8.4.27, 8.5.12 o una versión posterior, o instale el paquete corregido de su proveedor. Reinicie PHP-FPM o el servidor web para que la nueva versión se ejecute realmente.
2. Pregunte por escrito a su proveedor de hosting qué versión de PHP ejecuta su servicio y si incluye las correcciones de CVE-2026-109618 y CVE-2026-109619. Pregunte lo mismo sobre los servidores de staging y los proyectos antiguos; consulte servidores de staging y de pruebas olvidados.
3. Planifique la salida de PHP 8.1 y versiones anteriores si no hay disponible una corrección trasladada.
4. Deje de anunciar la versión. Configure expose_php = Off en php.ini para eliminar X-Powered-By y limite la cabecera Server (ServerTokens Prod en Apache, server_tokens off en nginx). Esto no corrige nada por sí solo, pero evita ofrecer detalles a los escáneres automatizados. Más información en cabeceras de seguridad HTTP que debería enviar todo sitio web empresarial.

Si no puede actualizar de inmediato, el aviso enumera medidas temporales que reducen vías de ataque concretas, y deja claro que solo la actualización es una solución completa.

Cómo le ayuda Datahorses

Vigilamos su empresa desde fuera cada día, tal como la vería un atacante, y no necesitamos acceso a sus sistemas. Cuando un servidor empieza a anunciar una versión de software desactualizada, el hallazgo llega con pasos concretos para quien lo gestiona. Descubra qué vigilamos o solicite una propuesta.