Vulnerabilidad de PHP (PHP2Shell): qué ha pasado, cómo protegerte y cómo actualizar tu servidor

La vulnerabilidad de PHP que se hizo pública el 21 de octubre de 2026 obliga a actualizar servidores cuanto antes: son dos fallos críticos en el propio intérprete que, según el proyecto PHP, pueden permitir a un atacante ejecutar código en un servidor web sin iniciar sesión. Circula con el apodo informal PHP2Shell y alcanza a buena parte de la web, porque PHP está detrás de WordPress, Drupal, Joomla y muchísimas tiendas online.

Esta guía resume qué ha pasado con la vulnerabilidad de PHP, a quién afecta, cómo comprobar tu servidor y los pasos para pasar a una versión segura. La información está comprobada a 22 de octubre de 2026 y puede cambiar en los próximos días: si administras un servidor, consulta siempre el aviso oficial de PHP antes de tocar nada.

Qué ha pasado con la vulnerabilidad de PHP

El proyecto PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos fallos catalogados como CVE-2026-109618 y CVE-2026-109619. Ambos reciben una puntuación de 9,2 sobre 10 en la escala CVSS v4.0, que los sitúa en la categoría de críticos.

El primero, CVE-2026-109618, nace de cómo PHP maneja los errores por falta de memoria: la petición puede quedar a medio inicializar y la limpieza posterior trata esos datos como si fueran válidos. El segundo, CVE-2026-109619, deja en memoria referencias a datos de una petición ya liberados, y otra petición atendida por el mismo proceso puede usarlos antes de que se reinicien.

Los detalles se filtraron antes de tiempo. El 20 de octubre apareció en un foro un mensaje con los identificadores, cuando el proyecto pensaba revelarlos junto con los parches, según Infosecurity Magazine. El aviso previo de PHP ya había advertido de que adelantaría la publicación si los detalles se hacían públicos.

Versiones afectadas y versiones corregidas

Según Google Cloud y Wiz, la vulnerabilidad de PHP afecta a todas las versiones desde la 5.4 hasta la 8.5.11. El proyecto solo ha publicado parches oficiales para las ramas que todavía mantiene:

Ojo con los paquetes de las distribuciones: un parche retroportado puede conservar un número de versión antiguo. Para saber si estás protegido, compara el paquete completo con el aviso de tu proveedor y no te fíes solo del número que devuelve php -v.

Quién corre riesgo con esta vulnerabilidad de PHP

Según el aviso oficial, está en riesgo cualquier instalación que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera que el peligro es mayor con mod_php, donde hay un exploit demostrado que se activa con una sola petición sin autenticar, antes de que se ejecute código de la aplicación.

Si tienes una web con WordPress, WooCommerce, Drupal, Joomla, Magento o PrestaShop, la clave es esta: el fallo no está en el gestor de contenidos ni en un plugin, sino en PHP. Actualizar el CMS, el tema o los plugins no corrige la vulnerabilidad de PHP si el intérprete del servidor sigue sin parchear, algo que subrayan también guías para tiendas online como la de Ecommerce News.

Wiz también demostró que se puede leer memoria de un proceso PHP sin llegar a ejecutar código. Esa memoria puede contener contraseñas, tokens y claves de API, de modo que el riesgo no se limita a perder el control del servidor.

Si eres un usuario normal, no tienes que hacer nada en tu móvil ni en tu ordenador: el problema está en los servidores. Lo que sí puedes hacer es estar atento a los avisos de las webs y servicios donde tengas cuenta.

¿Se está explotando ya la vulnerabilidad de PHP?

Depende de la fuente y de la hora. CISA indicó el 21 de octubre que no había observado explotación cuando publicó su alerta, aunque pidió actualizar de inmediato. Qualys, en una actualización del 22 de octubre, recoge que Cloudflare y Amazon Threat Intelligence han comunicado tráfico de ataque y que Patchstack ha recibido avisos de proveedores de hosting.

En la práctica, conviene tratar la situación como activa. Cloudflare dijo que ya había desplegado reglas de su cortafuegos web (WAF) para los vectores conocidos, disponibles incluso en el plan gratuito, según Help Net Security. Es una capa útil, pero no sustituye al parche.

Cómo comprobar si tu servidor tiene la vulnerabilidad de PHP

Primero localiza todas las instalaciones de PHP: puede haber varias versiones en paralelo, contenedores, paquetes de paneles de hosting y PHP incluido dentro de otros programas. El resultado de php -v puede corresponder a una instalación distinta de la que sirve tu web.

• Debian o Ubuntu: dpkg -l | grep php muestra los paquetes instalados.
• Red Hat, Fedora y derivadas: rpm -qa | grep php.
• Apache: apachectl -M | grep php (en Debian y Ubuntu, apache2ctl) indica si se carga mod_php.
• PHP-FPM: php-fpm -v; el nombre del binario varía según la distribución, por ejemplo php-fpm8.3.
• Contenedores: revisa la etiqueta de la imagen y reconstruye sobre una base ya parcheada.

En un hosting compartido o gestionado no tienes acceso a esas órdenes, así que pregunta a tu proveedor si ya ha aplicado el parche. Según un repaso de hosttest.es, Hetzner informó de que había actualizado PHP 7.4 y de la 8.0 a la 8.5 en sus servidores de hosting web y gestionados, pero en VPS y servidores dedicados con acceso root debe hacerlo el propio administrador.

Cómo corregir la vulnerabilidad de PHP: pasos para actualizar

Estos pasos siguen las recomendaciones del NCSC británico, de PHP y de Qualys. Ajusta cada uno a tu sistema operativo y a tu proveedor.

1. Haz un inventario. Localiza todas las instalaciones de PHP, empezando por los servidores expuestos a Internet. No te limites a las versiones viejas: el NCSC advierte de que pueden estar afectadas todas.
2. Copia de seguridad. Guarda archivos y base de datos y, si puedes, prueba la actualización en un entorno de pruebas. Un parche dentro de la misma rama suele tener poco riesgo, pero conviene probar las webs con código antiguo.
3. Actualiza con el gestor de paquetes. Instala la versión corregida que indique el aviso de tu distribución. Según Qualys, el 21 de octubre ya había avisos de Ubuntu, Fedora, Red Hat, Gentoo, Arch Linux y Alpine.
4. Compilando desde el código fuente. Descarga 8.5.12, 8.4.27, 8.3.36 u 8.2.35 de php.net y vuelve a compilar. Si dependes del repositorio voluntario rpms.remirepo.net, PHP avisó de que no tendría actualizaciones ese día y recomienda cambiar a paquetes de la distribución o compilar.
5. Contenedores y nube. Reconstruye la imagen con una base parcheada y vuelve a desplegar; actualizar el servidor anfitrión no arregla la imagen.
6. Reinicia los servicios. Reinicia Apache, PHP-FPM y cualquier servicio PHP, porque los procesos en marcha pueden seguir con el código vulnerable hasta que se reinicien.
7. Verifica. Comprueba que el servicio que atiende la web usa la versión corregida y que no quedan procesos antiguos.
8. Revierte las medidas de emergencia. Si aplicaste memory_limit=-1, vuelve a un límite razonable. Qualys avisa de que, con PHP ya parcheado, un proceso puede terminar de golpe al alcanzar su límite de memoria, así que prueba cómo se comporta tu aplicación bajo presión.

Qué hacer si no puedes actualizar hoy

PHP insiste en que solo actualizar resuelve el problema por completo. Si necesitas ganar tiempo frente a la vulnerabilidad de PHP, estas medidas reducen la exposición a vías de ataque concretas, pero no hacen segura una instalación sin parchear:

• Pon session.upload_progress.enabled=0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor, y reinicia todos los procesos. No sirve ponerlo con ini_set() ni en .user.ini.
• En PHP 8.5, pon fatal_error_backtraces=0 a nivel de administrador y reinicia.
• Fija memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (con php_admin_value, por ejemplo). Es temporal y aumenta el riesgo de agotar recursos.
• Limita el tamaño de las peticiones: post_max_size=8M si no hay subidas de archivos y 32M si las hay, con upload_max_filesize por debajo. Aplica límites equivalentes en el servidor web o en el proxy.
• En PHP-FPM, valora pm.max_requests=1 si el coste de rendimiento es asumible.
• Pon un cortafuegos web (WAF) delante, sabiendo que es una capa extra y no un parche.

Qué hacer si usas PHP 8.1 o anterior

Es el caso más incómodo. PHP no publica binarios ni versiones corregidas para esas ramas, pero ha puesto a disposición retroportes mínimos del código de 7.4, 8.0 y 8.1 para quien compila desde el código fuente o no tiene un proveedor LTS. Tienes tres caminos: pedir el paquete corregido a tu distribución o proveedor de soporte, aplicar el retroporte, o saltar a una rama soportada.

A medio plazo, la salida sensata es migrar. Y ojo con 8.2: aunque ya tiene parche, deja de recibir correcciones de seguridad el 31 de diciembre de 2026, así que quizá merezca la pena ir directamente a 8.4 u 8.5 si tu aplicación lo permite. Esa vulnerabilidad de PHP deja claro lo caro que sale quedarse en una versión sin soporte.

Cómo saber si te han atacado con la vulnerabilidad de PHP

Estos fallos actúan por debajo de la aplicación, así que los registros de tu web pueden dar poca pista. Wiz señala algunas señales que justifican investigar, aunque ninguna prueba por sí sola una intrusión:

• Peticiones multipart inusuales seguidas de errores de límite de memoria o de respuestas HTTP 500 repetidas.
• Cookies PHPSESSID en las respuestas que sean anormalmente largas o tengan un formato extraño.
• Reinicios inexplicables de procesos PHP.

Si tu servidor estuvo expuesto sin parchear, mi consejo es ir más allá: revisa archivos modificados recientemente y busca scripts que no reconozcas, ya que el NCSC recomienda buscar puertas traseras instaladas por un atacante. Como la memoria de PHP puede contener secretos, plantéate rotar contraseñas, claves de API y tokens. Si no te sientes seguro, pide ayuda a un proveedor de respuesta a incidentes.

El papel de la IA en esta vulnerabilidad de PHP

Hay un detalle que interesa especialmente en un blog de inteligencia artificial. Wiz cuenta que usó Gemini 4 Argon, GPT-5.6 Sol y su herramienta Wiz Atlas durante la investigación, y asegura que los modelos de IA redujeron mucho el trabajo necesario para convertir fallos antiguos en un exploit que funcione en distintos entornos.

Conviene leerlo con cautela: es la versión de una empresa que vende seguridad y que protagonizó el hallazgo, y Google DeepMind lo presenta como un ejemplo de IA para la defensa. Lo que sí es verificable es que PHP, CISA y el NCSC piden parchear. Si la tesis de Wiz es correcta, los fallos complejos dejarán de estar protegidos por su dificultad, y por eso importa tanto actualizar rápido. Si te interesa cómo se están usando los agentes de IA en otros terrenos, tienes nuestra guía sobre agentes de IA disponibles en España.

Consejos para no volver a quedar expuesto

• Activa las actualizaciones de seguridad automáticas en el sistema operativo y suscríbete a los avisos de tu distribución y de PHP.
• Mantén solo versiones con soporte. La vulnerabilidad de PHP alcanza versiones de hace más de diez años; anota las fechas de fin de vida de tu rama en el calendario.
• Reduce lo expuesto. No dejes públicos paneles de administración ni páginas de diagnóstico como phpinfo(), y desactiva funciones que no uses.
• Pon un WAF o CDN delante como capa adicional, no como sustituto del parche.
• Separa y limita. Usa un usuario con pocos permisos para PHP y guarda las claves fuera del código siempre que puedas.
• Copias de seguridad fuera del servidor y probadas, para poder restaurar si algo sale mal.
• Monitoriza errores 500, picos de memoria y reinicios de procesos PHP.
• Prepara un plan de contingencia. Si tu negocio depende de un proveedor externo, te servirá lo que contamos en nuestro análisis de la caída de Revolut y qué hacer si no puedes pagar.

En resumen, la vulnerabilidad de PHP exige actuar hoy: localiza tus instalaciones, instala la versión corregida, reinicia los servicios y revisa si hubo intrusión. Mientras no puedas, aplica las mitigaciones del aviso oficial y valora aislar el servicio.

Preguntas frecuentes

Los modelos que ayudaron a encontrar estos fallos son también los que más hay que vigilar: OpenAI ha decidido entrenar los suyos sin internet tras varios incidentes, como contamos en OpenAI entrenará sus modelos sin internet.

Fuentes

1. PHP.net: Security advisory, critical remote code execution vulnerabilities (21 de octubre de 2026)
2. CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 de octubre de 2026)
3. NCSC (Reino Unido): Critical security issue affecting PHP (21 de octubre de 2026)
4. Wiz Research: PHP2Shell, AI uncovers critical RCE vulnerabilities (21 de octubre de 2026)
5. Qualys: PHP2Shell, PHP patches two critical RCE vulnerabilities (actualizado el 22 de octubre de 2026)
6. Help Net Security: PHP2Shell, critical PHP vulnerabilities patched (21 de octubre de 2026)
7. Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
8. Infosecurity Magazine: Critical PHP vulnerabilities leaked ahead of scheduled security patches
9. hosttest.es: Vulnerabilidad crítica en PHP, qué deben saber los clientes de hosting web
10. Ecommerce News: PHP2Shell, guía urgente para tiendas online