PHP2Shell: dos vulnerabilidades críticas en PHP permiten tomar el control de servidores web

• Qué pasó: el 21 de octubre de 2026, el proyecto PHP publicó parches para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Ambas tienen una puntuación CVSS 4.0 de 9.2.
• El riesgo: un atacante sin usuario ni contraseña puede llegar a ejecutar código en tu servidor web y tomar el control.
• A quién afecta: a cualquier instalación de PHP que atienda peticiones web, incluidos los sitios hechos con WordPress, Drupal, Joomla o Laravel.
• Qué hacer hoy: actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si usas PHP 8.1 o anterior, migrar a una versión soportada.

PHP es el lenguaje con el que funciona una parte enorme de la web: WordPress, la mayoría de las tiendas en línea con WooCommerce, foros, intranets y miles de aplicaciones a medida. Cuando aparece una falla en el propio PHP, no en un plugin ni en un tema, el problema alcanza a todos los sitios que lo usan, sin importar lo bien mantenido que esté el resto.

El 20 de octubre, el equipo de PHP anunció una actualización de seguridad crítica para el día siguiente. El 21 de octubre publicó las versiones corregidas y un aviso con un mensaje directo: actualiza ya. Ese mismo día, el centro de ciberseguridad de las instituciones europeas (CERT-EU) y el INCIBE-CERT de España emitieron sus propias alertas, ambas con nivel crítico.

Según CERT-EU, ya circulan pruebas de concepto públicas y es posible que los atacantes las estén usando. El exploit demostrado necesita una sola petición sin autenticar, y puede activarse antes de que se ejecute cualquier línea del código de tu aplicación. Por eso no basta con tener un sitio bien programado: la falla está en la capa de abajo.

CVE-2026-109618: corrupción de memoria al quedarse sin memoria

PHP limita la memoria que puede usar cada petición con la directiva memory_limit. Cuando se alcanza ese límite, PHP interrumpe la ejecución de forma abrupta. El problema es que esa interrupción puede ocurrir mientras PHP todavía está procesando los datos de la petición, por ejemplo durante la subida de un archivo desde un formulario. Al limpiar, PHP puede liberar memoria que nunca terminó de inicializarse, y esa corrupción puede aprovecharse para ejecutar código.

INCIBE señala que la ejecución remota de código se validó contra Apache con mod_php, y que PHP-FPM se considera susceptible, aunque no se ha demostrado un exploit completo por esa vía.

CVE-2026-109619: estado global que sobrevive entre peticiones

Un mismo proceso de PHP atiende muchas peticiones seguidas. Esta falla hace que parte del estado interno de una petición siga existiendo después de que su memoria se libera, por ejemplo tras un error fatal. La siguiente petición atendida por ese mismo proceso puede usar ese estado antes de que se reinicie, lo que puede provocar fuga de información y ejecución de código. Hay rutas de explotación confirmadas en Apache mod_php y en PHP-FPM, y en PHP 8.5 existe una vía adicional relacionada con los rastros de errores fatales.

De acuerdo con CERT-EU, está en riesgo toda instalación de PHP que sirva peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El propio equipo de PHP considera que mod_php es la configuración de mayor riesgo.

• PHP 8.5: afectadas las anteriores a 8.5.12. Versión corregida: 8.5.12.
• PHP 8.4: afectadas las anteriores a 8.4.27. Versión corregida: 8.4.27.
• PHP 8.3: afectadas las anteriores a 8.3.36. Versión corregida: 8.3.36.
• PHP 8.2: afectadas las anteriores a 8.2.35. Versión corregida: 8.2.35 (fin de soporte: 31 de diciembre de 2026).
• PHP 8.1 y anteriores: todas afectadas. Sin actualización oficial; hay parches mínimos en código fuente para 7.4, 8.0 y 8.1, pero lo recomendable es migrar.

El impacto ya se nota. Según RedesZone, Cloudflare reportó los primeros ataques y desplegó reglas de su firewall de aplicaciones (WAF) para todos sus clientes, incluido el plan gratuito. Varios sitios gubernamentales de Finlandia y los Países Bajos, la Universidad de Viena y la Universidad de Friburgo desconectaron servicios de forma preventiva. El mismo medio cita una estimación de la firma Mallory de unos 884.000 servidores expuestos que todavía usan PHP 8.1 o anterior.

• Revisa la versión de PHP. Si tienes acceso al servidor, ejecuta php -v. En un hosting compartido, búscala en el panel de control (cPanel, Plesk u otro), normalmente en la sección «Versión de PHP».
• Compárala con la lista. Si es anterior a la versión corregida de su rama, o es 8.1 o más antigua, tu sitio está expuesto.
• No olvides los productos que traen PHP integrado. Algunos paneles, aplicaciones y appliances incluyen su propio PHP. El NCSC de los Países Bajos mantiene una lista pública de productos afectados.
• Si no sabes cómo revisarlo, pregunta a tu proveedor de hosting. Pídele por escrito la versión exacta de PHP de tu cuenta y la fecha en que aplicará el parche.

• Actualiza PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, según tu rama. Es la única solución completa.
• Si usas los paquetes de tu distribución Linux (Debian, Ubuntu, Red Hat y otras) o de un proveedor con soporte extendido, confirma que la actualización ya incluye la corrección. Los distribuidores recibieron los parches con anticipación.
• Si usas el repositorio rpms.remirepo.net, ten en cuenta que no tendrá la actualización el día de la publicación. PHP recomienda cambiar a los paquetes de tu distribución o compilar desde el código fuente.
• Si sigues en PHP 8.1, 8.0, 7.4 o anterior, planifica la migración a una versión soportada. Los parches mínimos para 7.4, 8.0 y 8.1 son una solución puente, no definitiva.
• Si no puedes actualizar un sistema expuesto a internet, sepáralo de la red pública hasta que el parche esté aplicado y verificado, como recomienda CERT-EU.
• Reinicia todos los procesos de PHP (PHP-FPM y el servidor web) después de actualizar o de cambiar la configuración.

Si necesitas unas horas para actualizar, el aviso oficial y CERT-EU describen medidas que reducen la exposición pero no la eliminan. Aplícalas solo como puente y con ayuda de quien administre tu servidor:

Para CVE-2026-109618

• Configurar memory_limit=-1 de forma que la aplicación no pueda cambiarlo (por ejemplo, con php_admin_value en PHP-FPM o Apache) y verificar que ningún otro ajuste vuelva a fijar un límite. Un valor como memory_limit=128M no desactiva la vulnerabilidad.
• Mantener post_max_size lo más bajo posible: 8M si el sitio no recibe archivos, 32M si los necesita, con upload_max_filesize por debajo.
• Limitar la memoria con el contenedor o un cgroup, no con RLIMIT_AS ni RLIMIT_DATA, que pueden activar la ruta vulnerable.
• Limitar el tamaño y la cantidad de campos de las peticiones en el servidor web o el proxy.

Para CVE-2026-109619

• Configurar session.upload_progress.enabled=0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor, y reiniciar todos los procesos. CERT-EU advierte que no basta con ini_set() ni con .user.ini.
• En PHP 8.5, configurar además fatal_error_backtraces=0.
• Eliminar directivas obsoletas o inválidas y corregir errores fatales y tiempos de espera que un visitante pueda provocar. Ocultar los errores con display_errors o @ no protege.

Si tu sitio está detrás de Cloudflare, sus reglas de WAF añaden una capa extra mientras actualizas, pero tampoco sustituyen al parche.

2021: una puerta trasera en el código fuente de PHP

El 28 de marzo de 2021, alguien comprometió el servidor Git oficial de PHP (git.php.net) y subió dos cambios maliciosos al código fuente haciéndose pasar por dos de sus principales desarrolladores, Rasmus Lerdorf y Nikita Popov. Los cambios se disfrazaron como una corrección menor («Fix typo») e incluían una puerta trasera: ejecutaba el código enviado en una cabecera HTTP manipulada si el texto empezaba con la palabra «zerodium». Los mantenedores lo detectaron y revirtieron rápidamente, y el proyecto trasladó su repositorio oficial a GitHub.

La lección: el riesgo no siempre está en tu código. También puede estar en la cadena de suministro del software que usas.

2024: CVE-2024-4577, la falla de PHP-CGI en Windows

En junio de 2024, el equipo de investigación de DEVCORE reportó una vulnerabilidad de inyección de argumentos en PHP cuando se usa en modo CGI sobre Windows. Por una conversión automática de caracteres de Windows («Best-Fit»), un atacante podía saltarse una protección antigua (de CVE-2012-1823) y ejecutar código de forma remota. Afectaba, entre otras, a la configuración por defecto de XAMPP en Windows. Se corrigió en PHP 8.3.8, 8.2.20 y 8.1.29, recibió una puntuación CVSS de 9.8 y fue explotada activamente poco después de publicarse; la agencia de ciberseguridad de Estados Unidos (CISA) la incluyó en su catálogo de vulnerabilidades explotadas.

La lección: cuando se publica una falla grave, los ataques llegan en días. La ventana para actualizar es muy corta.

• Usa siempre una versión de PHP con soporte. Revisa las fechas en la página oficial de versiones soportadas. PHP 8.2 deja de recibir parches el 31 de diciembre de 2026.
• Ten a alguien responsable de las actualizaciones del servidor, no solo de WordPress y sus plugins.
• Pon un firewall de aplicaciones (WAF) delante de tu sitio. No reemplaza los parches, pero da margen.
• Haz copias de seguridad automáticas y guardadas fuera del servidor, para recuperarte rápido si algo sale mal.
• Vigila tu sitio: cambios inesperados de archivos, usuarios nuevos en el panel o picos de tráfico extraños pueden ser señales de un ataque.

¿Qué es PHP2Shell?

Es el nombre con el que se conoce a dos vulnerabilidades críticas en PHP, CVE-2026-109618 y CVE-2026-109619, publicadas el 21 de octubre de 2026. Ambas tienen una puntuación CVSS 4.0 de 9.2 y pueden permitir que un atacante sin credenciales ejecute código en el servidor web.

¿Qué versiones de PHP corrigen las vulnerabilidades?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.1 y anteriores ya no reciben actualizaciones oficiales; para 7.4, 8.0 y 8.1 hay parches mínimos en código fuente, pero lo recomendable es migrar a una versión soportada.

¿Mi sitio de WordPress está en riesgo?

WordPress funciona sobre PHP, así que cualquier sitio servido con una versión de PHP sin parchear está expuesto, aunque WordPress y sus plugins estén al día. Lo que hay que actualizar es la versión de PHP del servidor o del hosting.

¿Cómo sé qué versión de PHP uso?

En el servidor, con el comando php -v. En un hosting compartido, en el panel de control (cPanel, Plesk u otro), normalmente en la sección de versión de PHP. También puedes preguntarle directamente a tu proveedor de hosting.

¿Las mitigaciones temporales son suficientes?

No. El equipo de PHP, CERT-EU e INCIBE coinciden en que solo la actualización corrige el problema por completo. Las mitigaciones reducen la exposición mientras se aplica el parche.

Mi hosting dice que se encarga de todo. ¿Tengo que hacer algo?

Confírmalo. Pide por escrito qué versión de PHP usa tu cuenta y si ya tiene el parche. Muchos hostings permiten elegir la versión de PHP, y si tu sitio quedó configurado en una rama antigua, la actualización automática no siempre lo cubre.

• PHP. «Security advisory: Critical remote code execution vulnerabilities, update now» y versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 (21 de octubre de 2026). php.net/archive/2026.php
• CERT-EU. «Security Advisory 2026-018: Critical Vulnerabilities in PHP» (21 de octubre de 2026). cert.europa.eu
• INCIBE-CERT. «Múltiples vulnerabilidades en PHP» (21 de octubre de 2026). incibe.es
• RedesZone. «Dos vulnerabilidades críticas en PHP ponen en peligro la web» (21 de octubre de 2026). redeszone.net
• NCSC-NL. Lista de productos afectados por PHP2Shell. github.com/NCSC-NL/php2shell
• PHP. Versiones soportadas. php.net/supported-versions.php
• DEVCORE. «Security Alert: CVE-2024-4577 - PHP CGI Argument Injection Vulnerability» (6 de junio de 2024). devco.re
• NIST. Ficha de CVE-2024-4577 en la National Vulnerability Database. nvd.nist.gov
• CISA. Catálogo de vulnerabilidades explotadas conocidas. cisa.gov
• PHP.Watch. «git.php.net server compromised, move to GitHub, and delayed updates» (marzo de 2021). php.watch
• BleepingComputer. «PHP's Git server hacked to add backdoors to PHP source code» (marzo de 2021). bleepingcomputer.com