Revisar mi web

Todos los artículos

php2shell: dos fallos críticos de PHP ya están corregidos. Actualice hoy el PHP de su web

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen CVE-2026-109618 y CVE-2026-109619, dos fallos de ejecución remota de código sin autenticación. Quién está afectado, cómo comprobar su versión de PHP y qué hacer ahora.

Radek, ENSOMEDIAPublicado 9 min de lecturaIn EnglishPo polskuAuf DeutschEn français中文بالعربية

El 21 de octubre de 2026 el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Corrigen dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, que pueden permitir a un atacante ejecutar código en un servidor web sin iniciar sesión. El equipo de PHP indica que todos los usuarios de PHP deben actualizar de inmediato (php.net).

Si su web funciona con WordPress, WooCommerce, Joomla, Drupal o cualquier otro software PHP, esto le afecta. Los fallos están en PHP, no en WordPress ni en un plugin, así que actualizar WordPress no los corrige. Hay que actualizar su PHP, normalmente a través de su empresa de hosting.

Qué ha pasado

  • 20 de octubre de 2026: el equipo de seguridad de PHP anunció para el 21 de octubre de 2026 a las 14:00 UTC una versión de seguridad que corrige dos vulnerabilidades críticas con CVSS v4.0 9.2 (php.net).
  • 21 de octubre de 2026, 03:02 UTC: Cloudflare activó para sus clientes, incluido el plan gratuito, reglas de firewall contra el ataque. Cloudflare dice que los detalles se filtraron antes de la publicación oficial y que vio tráfico de ataque contra sus clientes (blog de Cloudflare).
  • 21 de octubre de 2026: PHP publicó las versiones corregidas y dos avisos de seguridad, GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp, ambos valorados como Critical, 9.2.

Los dos fallos se conocen como «php2shell» (blog de Cloudflare, BleepingComputer). El National Cyber Security Centre del Reino Unido pide a las organizaciones que actualicen y que consideren desconectar un sistema si no puede actualizarse o mitigarse con rapidez (NCSC).

Quién está afectado

Según PHP, toda instalación de PHP que atienda peticiones web está en riesgo, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP valora el riesgo como más alto en mod_php, donde un exploit demostrado funciona con una sola petición sin autenticación antes de que se ejecute código de la aplicación (php.net).

Ambos avisos enumeran como afectadas todas las versiones anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). Las ramas más antiguas también lo están: el NCSC habla de PHP 5 en adelante (NCSC) y Cloudflare de PHP 5.4 o posterior (blog de Cloudflare).

Si su web usa PHP y nadie ha actualizado PHP desde la tarde del 21 de octubre, dé por hecho que está afectada.

Cómo comprobar qué versión de PHP usa su web

En WordPress: vaya a Herramientas > Salud del sitio > Información y abra la sección Servidor. Muestra la versión de PHP con la que funciona su web (documentación de WordPress.org). Si Salud del sitio también indica que su web usa una versión de PHP obsoleta, trátelo como urgente.

En el panel de su hosting: la mayoría de los paneles (cPanel, Plesk, DirectAdmin y los propios de cada proveedor) tienen una página para ver o elegir la versión de PHP, a menudo llamada «Versión de PHP», «Selector de PHP» o «Configuración de PHP». Si no la encuentra, pregunte a su proveedor.

Compare lo que vea con las versiones corregidas de más abajo. Una salvedad: las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron los parches con antelación y distribuyen sus propios paquetes (php.net). Su número de versión puede no coincidir con los del proyecto PHP aunque la corrección esté incluida. Si su proveedor usa paquetes de la distribución, la respuesta fiable la da el proveedor, no solo el número.

Qué hacer ahora

1. Pasar a una versión corregida

Su rama de PHP Versión corregida Estado del soporte
8.5 8.5.12 Correcciones de seguridad hasta el 31 dic 2029
8.4 8.4.27 Correcciones de seguridad hasta el 31 dic 2028
8.3 8.3.36 Correcciones de seguridad hasta el 31 dic 2027
8.2 8.2.35 Correcciones de seguridad hasta el 31 dic 2026, después fin de vida
8.1 y anteriores Sin versión oficial Fin de vida, vea más abajo

Versiones corregidas: php.net. Fechas de soporte: versiones de PHP con soporte.

Si usa PHP 8.2, actualice ahora a 8.2.35 y planifique el paso a 8.3 o posterior. PHP 8.2 no recibe correcciones de seguridad después del 31 de diciembre de 2026 (php.net).

2. Si usa PHP 8.1, 8.0, 7.4 o anterior

El proyecto PHP ya no publica actualizaciones para PHP 8.1 ni anteriores. Algunas distribuciones y proveedores de LTS ofrecen correcciones portadas. Por la gravedad, el equipo de seguridad de PHP también publicó backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1, pensados para quienes compilan PHP desde el código fuente o no tienen proveedor de LTS (php.net).

Para una web de empresa típica en hosting compartido o gestionado la respuesta es más sencilla: cambie a una versión con soporte (8.3 o posterior) en el panel de su hosting, o pida a su proveedor que lo haga. Pruebe la web después, porque los plugins y temas antiguos a veces fallan con un PHP más nuevo.

3. Pregunte a su proveedor

Envíe a su proveedor un mensaje breve:

Buenos días: ¿el PHP de mi cuenta (dominio: example.es) ya está parcheado contra CVE-2026-109618 y CVE-2026-109619? ¿Qué versión o paquete exacto de PHP uso y cuándo se aplicará la actualización si todavía no está hecha?

Si gestiona su propio servidor y usa el repositorio rpms.remirepo.net, mantenido por voluntarios, PHP dice que no tendrá actualizaciones el 21 de octubre y recomienda pasar a los paquetes de la distribución o compilar desde el código fuente (php.net).

4. Un firewall da unos días, no es la solución

Cloudflare desplegó reglas para los métodos de ataque conocidos en todos los planes con WAF, incluido el gratuito (blog de Cloudflare). El CTO de Cloudflare las describió como una medida provisional y pidió a los administradores que apliquen el parche (Tenable). El propio PHP dice que no hay mitigaciones completas y que actualizar es la única opción segura (php.net).

Dos límites. Las reglas cubren patrones de ataque conocidos, y los atacantes ya estaban cambiando sus cargas para esquivarlas (blog de Cloudflare). Además, las reglas no protegen nada si los atacantes pueden llegar a su servidor directamente por su dirección IP, así que el servidor de origen solo debería aceptar tráfico web procedente de Cloudflare (Sansec).

5. Si no puede actualizar hoy

PHP enumera cambios de configuración que reducen la exposición a las vías de ataque conocidas, pero no hacen seguro un servidor (php.net). Son ajustes del servidor, de modo que en hosting compartido tiene que aplicarlos su proveedor. Entregue esta lista a su desarrollador o proveedor:

  • Para CVE-2026-109618: establezca memory_limit=-1 de modo que las aplicaciones no puedan modificarlo (por ejemplo php_admin_value en el pool de FPM o en la configuración de Apache), fije un post_max_size bajo (8M sin subidas, 32M con subidas) con upload_max_filesize por debajo, y limite el tamaño de la petición, el número de campos, las partes multipart y las cabeceras en el servidor web o el proxy. No use RLIMIT_AS ni RLIMIT_DATA.
  • Para CVE-2026-109619: establezca session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor y reinicie todos los workers (ini_set() y .user.ini no funcionan para esto). En PHP 8.5, establezca además fatal_error_backtraces=0 y reinicie todos los workers. Elimine los ajustes por petición no válidos u obsoletos que generan avisos.

Detalles técnicos

Los dos fallos nacen del mismo tipo de problema: cuando una petición termina de forma anormal, PHP puede dejar memoria en un estado roto en el que confía un paso posterior (BleepingComputer, blog de Cloudflare).

CVE-2026-109618, RCE por corrupción de memoria cuando falta memoria (OOM) (GHSA-w8hw-w9fx-j79w). PHP usa longjmp() para abortar una petición cuando se queda sin memoria. En algunos puntos la memoria de la petición es accesible antes de estar totalmente inicializada. Si en ese momento falla cualquier asignación, el cierre de la petición puede leer los datos a medio construir. Los atacantes pueden forzar la falta de memoria con peticiones multipart: un cuerpo sin una longitud de contenido utilizable, una parte con un número enorme de cabeceras o muchos campos de archivo vacíos con nombres anidados. Con Apache mod_php esto ocurre durante el análisis automático del cuerpo, antes de que se ejecute código de la aplicación. Se confirmó la ejecución remota de código con la cuenta del worker web contra mod_php con los límites de entrada y de memoria por defecto. Según el análisis del código fuente, FPM se considera susceptible, aunque no se demostró un exploit completo para FPM. El parche sustituye longjmp() ante falta de memoria por una parada suave diferida en un punto seguro y un _exit() forzoso en un umbral mayor.

CVE-2026-109619, RCE por estado global obsoleto (GHSA-6wmf-4rv5-p3rp). Un worker de PHP conserva cierto estado global (de errores, sesión, objetos y extensiones) que apunta a memoria propiedad de una petición. Un error fatal, incluida la falta de memoria o Maximum execution time exceeded, puede saltarse el reinicio de ese estado. La siguiente petición que atienda el mismo worker puede entonces usar la memoria liberada antes de la inicialización normal, es decir, un uso después de liberar (use after free). Se han confirmado dos consumidores tempranos: los avisos de ajustes INI por petición aplicados antes de la inicialización, y el progreso de subida de sesión, que está activado por defecto y no exige que la aplicación llame a session_start(). La vía de fatal_error_backtraces de PHP 8.5 es la base del exploit confirmado contra mod_php. La vía de sesión se validó contra mod_php y FPM. Ocultar errores con error_reporting, display_errors o @ no protege.

Ambos avisos puntúan 9.2 con el vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: ataque por red, sin privilegios, sin interacción del usuario, complejidad de ataque alta e impacto total en la confidencialidad, la integridad y la disponibilidad del servidor.

Qué comprueba ShieldWave

Desde fuera, nadie puede saber si un servidor tiene el parche. Lo que un análisis puede ver es la versión de PHP que el servidor anuncia de sí mismo.

  • El análisis gratuito de shieldwave.io lee la cabecera de respuesta X-Powered-By. Si el servidor informa de una versión de PHP anterior a la versión corregida de su rama, o de una rama que no recibe ninguna corrección, el informe incluye un hallazgo php2shell con los dos números CVE y la versión que necesita. Muchos proveedores ocultan esta cabecera y las distribuciones aplican parches sin cambiar el número, de modo que un hallazgo significa «pregunte a su proveedor», y la ausencia de hallazgo no prueba que el servidor esté parcheado.
  • El plugin Ensomedia Security para WordPress muestra la versión de PHP con la que funciona la web y si esa rama sigue teniendo soporte (página del plugin). Con ello detecta el peor caso de este incidente: una web en PHP 8.1, 8.0, 7.4 o anterior, que no recibe corrección oficial. El plugin es gratuito, no requiere cuenta y está en el directorio de WordPress.org. En su escritorio, vaya a Plugins > Añadir nuevo y busque «Ensomedia Security».

Para conocer el nivel exacto de parcheo, use Salud del sitio y la tabla de arriba, y confírmelo con su proveedor.

Fuentes

Oficiales:

Otras: