Respuesta rápida: CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell, son dos vulnerabilidades críticas de PHP (CVSS 9,2) que permitían ejecutar código en un servidor sin autenticación. La solución llegó el 21 de octubre de 2026 con PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, además de parches retroportados para versiones antiguas. Hay que actualizar PHP y reiniciar sus procesos.
Actualizado el 26 de octubre de 2026, cinco días después de los parches. El estado de la explotación y de las versiones se ha contrastado con fuentes publicadas hasta el 25 de octubre; conviene revisarlo si lees esto más adelante, porque sigue evolucionando.
Qué pasó con CVE-2026-109618 y CVE-2026-109619
En pocos días PHP pasó de la alerta a la solución. PHP es el lenguaje que hay detrás de WordPress, Drupal, Joomla, Magento o Laravel, y los dos fallos no estaban en tu web ni en un plugin: estaban en el intérprete de PHP que ejecuta tu web en el servidor. Según BleepingComputer, los descubrieron investigadores de Calif, Wiz y OpenAI.
Así se desarrolló, según las fuentes consultadas:
- 17 de octubre. Amazon registra en sus honeypots el primer intento de explotación, cuatro días antes de la divulgación pública, según Tenable.
- 20 de octubre. El equipo de seguridad de PHP anuncia en php.net una versión de seguridad para el día siguiente. Los detalles se filtran antes de la divulgación coordinada, watchTowr confirma que los fallos son reales y PHP adelanta la publicación un día, según el relato de Alexandre Daubois, del equipo de seguridad de PHP.
- 21 de octubre. PHP publica las versiones corregidas. Ese mismo día, la Comisión Europea, ENISA, CERT-EU, Europol EC3 y la red de CSIRT europeos emiten un comunicado conjunto pidiendo actuar de inmediato, y Ubuntu y cPanel publican sus correcciones.
- 22 de octubre. Cloudflare ya registra millones de intentos de explotación, y se detecta una regresión de SimpleXML en dos de las versiones nuevas, que se corrige en el código ese mismo día.
Qué son CVE-2026-109618 y CVE-2026-109619
Son dos vulnerabilidades de ejecución remota de código (RCE) en el núcleo de PHP. Podían explotarse sin autenticación y el código se ejecutaba con los privilegios del proceso web, según el aviso de INCIBE-CERT.
| CVE | Tipo | Qué ocurre, en palabras sencillas | Aviso técnico |
|---|---|---|---|
| CVE-2026-109618 | RCE por corrupción de memoria al agotarse (OOM) | Si falta memoria en mitad de una petición, PHP interrumpe el proceso con datos a medio inicializar. Al cerrar la petición puede tratar esos datos inválidos como correctos. | GHSA-w8hw-w9fx-j79w |
| CVE-2026-109619 | RCE por uso de estado global obsoleto | Parte del estado interno de una petición sobrevive después de liberarse su memoria. Una petición posterior atendida por el mismo proceso puede usarlo antes de que PHP lo reinicie. | GHSA-6wmf-4rv5-p3rp |
En el caso de CVE-2026-109618, el atacante puede provocar ese fallo de memoria mediante peticiones de subida de archivos (multipart), según Daubois.
PHP consideró que el riesgo era mayor en Apache con mod_php, donde hay un exploit demostrado que actúa antes de que se ejecute código de la aplicación. En PHP-FPM, el aviso describe rutas confirmadas para CVE-2026-109619, mientras que para CVE-2026-109618 el análisis de código lo considera susceptible, aunque INCIBE indica que no se ha demostrado un exploit completo para esa ruta.
A quién afectaban
Según PHP, estaban en riesgo todas las instalaciones que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Sobre las versiones hubo cifras contradictorias. Se habló de «PHP 5.4 o posterior», pero según Daubois el mecanismo viene de PHP 5.3, los parches oficiales cubren solo de la 8.2 a la 8.5 y no se ha mostrado un exploit en versiones antiguas. La conclusión práctica no cambia: si tu PHP no incluye la corrección, conviene tratarlo como vulnerable.
Qué solución se dio
La solución es actualizar PHP a una versión corregida y reiniciar sus procesos. PHP publicó el 21 de octubre estas versiones:
| Rama de PHP | Versión corregida | Situación |
|---|---|---|
| 8.5 | 8.5.12 | Rama mantenida |
| 8.4 | 8.4.27 | Rama mantenida |
| 8.3 | 8.3.36 | Rama mantenida |
| 8.2 | 8.2.35 | Solo correcciones de seguridad; fin de vida el 31 de diciembre de 2026 |
| 7.4, 8.0 y 8.1 | Sin versión oficial | Parches mínimos de código fuente y correcciones retroportadas de terceros (ver más abajo) |
Según Daubois, el parche convierte memory_limit en un límite blando y añade un nuevo ajuste, memory_hard_limit_percent (200 % por defecto). Un PHP parcheado sigue terminando el proceso cuando se agota la memoria, pero ya sin corrupción.
PHP 7.4, 8.0 y 8.1: parches de terceros y qué opciones tienes
PHP no ha publicado versiones numeradas nuevas para estas ramas. Lo que sí ha publicado son parches mínimos de código fuente, pensados para quien compila PHP por su cuenta. Para PHP 7.3 y anteriores, el proyecto no ha publicado nada, aunque algunos proveedores han parcheado por su cuenta, según ComputingForGeeks.
Además, varios proveedores han retroportado la corrección a estas ramas. Estas son las vías que hemos localizado; la disponibilidad depende de tu sistema y de tu proveedor, y puede cambiar de un día para otro:
| Vía | Qué cubre | Condiciones y avisos |
|---|---|---|
| Canonical (Ubuntu) | Ubuntu 22.04 LTS: paquete php8.1 versión 8.1.2-1ubuntu2.28, en los repositorios estándar. Ubuntu 20.04 LTS: php7.4 versión 7.4.3-4ubuntu2.29+esm5. También hay paquetes para PHP 7.2 (18.04), 7.0 (16.04) y 5 (14.04). Según su ficha de seguridad, PHP 8.0 no figura. | El de 20.04 y los anteriores requieren Ubuntu Pro (ESM); 16.04 y 14.04, además, el complemento Legacy Support. Ubuntu solo parchea las versiones que cada release incluye |
| Ondřej Surý (ppa:ondrej/php y packages.sury.org) | Ondřej Surý indicó que la corrección debía estar disponible para todas las versiones PHP del repositorio, con paquetes para las versiones de Debian y Ubuntu compatibles. Según ma.ttias.be, el PPA ya incluye las ramas 5.6 a 8.1 con el parche mínimo. | Los paquetes llegan según se compilan: primero amd64, después arm. En los primeros días, el repositorio packages.sury.org iba por delante del PPA de Launchpad, que daba errores 503. Son fuentes aparte que hay que añadir al servidor |
| cPanel (EasyApache 4) | La versión 25.91 del 21 de octubre incluye el backport para ea-php74, ea-php80 y ea-php81, según el registro de cambios de cPanel. | Hay que actualizar EasyApache 4 y comprobar que cada dominio usa realmente esa versión de PHP |
| Debian | Debian 12 recibe PHP 8.2.35 (8.2.35-1~deb12u1), según ma.ttias.be. Para Debian 11 (PHP 7.4), la vía es Freexian ELTS, según ComputingForGeeks. | ELTS es de pago. Otros avisos de Debian no estaban claros a 22 de octubre |
| Remi (RHEL, AlmaLinux, Rocky) | Según ComputingForGeeks, el repositorio ofrece PHP 7.4.33-31, 8.0.30-21 y 8.1.34-6 con la corrección. | El 21 de octubre PHP advirtió de que no habría actualizaciones ese día, así que conviene verificar el registro de cambios del paquete |
| TuxCare y Zend (soporte extendido) | TuxCare (ELS for Runtimes) cubre PHP 8.1, 8.0, 7.0 a 7.4 y 5.x, y publicaba los parches rama por rama y plataforma por plataforma desde el 21 de octubre. Zend también ofrece soporte a largo plazo. | Son servicios comerciales. TuxCare no publica precios en esa página |
Nota informativa: la información sobre los repositorios de Ondřej Surý, Remi y Debian procede de hilos y guías de terceros, no de comunicados oficiales de esos proveedores, y puede cambiar a diario. Verifica el estado en tu sistema antes de aplicar nada.
Un detalle importante: con estos parches, el número de versión de PHP no cambia, así que php -v no te dice si estás protegido. La comprobación fiable es buscar ambos CVE en el registro de cambios del paquete: con zgrep en Debian y Ubuntu, o con rpm -q --changelog en sistemas RPM.
Una consecuencia práctica: según ComputingForGeeks, el parche de php.net desactiva por completo el progreso de subida de sesión aunque php.ini diga lo contrario, no incluye un límite de memoria estricto y, al superar memory_limit, el proceso termina de inmediato. Con PHP-FPM, el visitante puede ver un error 502 o 503. Si tu aplicación usa barras de progreso de subida, dejarán de funcionar.
Con estos parches quedan cubiertos los dos CVE de octubre, así que son una solución válida mientras planificas la migración. Pasar a PHP 8.4 u 8.5 sigue siendo lo recomendable como buena práctica, para seguir recibiendo correcciones en el futuro.
Cómo está la situación a día de hoy
¿Se explotaron CVE-2026-109618 y CVE-2026-109619?
Hubo intentos de explotación masivos, pero las fuentes consultadas describen sobre todo escaneo y no confirman compromisos generalizados:
- Volumen de intentos. Según The Hacker News, Cloudflare reportó decenas de miles de intentos 45 minutos después del anuncio, cientos de miles en dos horas y millones a primeras horas del 22 de octubre.
- Qué lograron. Talos, Wordfence y otras firmas describen actividad centrada en escaneo y reconocimiento, y Previdian no observó ejecuciones remotas exitosas, según la misma fuente. También se intentó desplegar una variante de la botnet Mirai, aunque Sophos opina que los atacantes tienen dificultades para crear exploits fiables.
- CISA. Actualizó su alerta el 23 de octubre: no ha observado explotación y ninguna de las dos CVE figuraba entonces en su catálogo de vulnerabilidades explotadas (KEV), según Tenable. Amazon, en cambio, afirma que se están explotando ampliamente, así que las fuentes no coinciden del todo.
- Dificultad técnica. VulnCheck demostró un bypass de ASLR que permite ejecutar código en x86-64 con la configuración de producción recomendada, según The Hacker News.
- Margen sin actualizar. Censys cifraba en más de 34,4 millones los servicios PHP aún vulnerables a 23 de octubre.
Efecto secundario del parche: regresión de SimpleXML
Las versiones 8.4.27 y 8.5.12 introdujeron una regresión (php-src#24488): cuando objetos de SimpleXML quedan en un ciclo de referencias, el proceso puede caerse con el error zend_mm_heap corrupted, según el manual de hosting de WordPress. Pueden verse afectados importadores, lectores de feeds y plugins que usen SimpleXML. Las versiones 8.3.36 y 8.2.35 no están afectadas.
La corrección se incorporó al código de PHP el 22 de octubre, pero en las fuentes consultadas todavía no constaba una versión publicada con ella. El propio hilo advierte de que no conviene volver a una versión sin parche; lo prudente es esperar a la próxima versión de corrección.
Qué se dijo y no era exacto
Daubois recoge dos precisiones útiles. La puntuación oficial es de 9,2, no de 10, aunque la gravedad crítica es correcta. Y el consejo más repetido, desactivar session.upload_progress.enabled, corresponde a CVE-2026-109619; la mitigación que PHP ponía primero para CVE-2026-109618 era memory_limit=-1.
Por qué actualizar WordPress no corrige estos CVE
Si tu web usa WordPress, Drupal, Joomla o Magento, el fallo no se corrige actualizando el CMS, un tema o un plugin. Reside en PHP, por debajo de todo eso. El parche tiene que llegar desde quien gestiona el servidor: tu empresa de hosting, el paquete de tu distribución Linux o la imagen de tu contenedor. Después hay que reiniciar los procesos de PHP para que el intérprete nuevo se cargue.
El problema pesa más porque mucha gente sigue en versiones antiguas. Según estadísticas de WordPress.org recogidas por CybelAngel, el 35,1 % de los sitios WordPress usa una versión de PHP que el proyecto ya no mantiene, y un 16,46 % sigue en PHP 7.4.
También hay exposición menos visible: según Huntress, citada por ITDaily, los paneles de hosting como cPanel o Plesk y los dispositivos con PHP embebido pueden estar afectados.
Esto plantea una pregunta que conviene responder antes de que llegue la siguiente vulnerabilidad: ¿quién se responsabiliza de actualizar los componentes de tu web? Es un tema que desarrollamos en nuestro artículo sobre crear una web profesional con WordPress, donde explicamos qué implica el mantenimiento a largo plazo.
Qué hacer si aún no has actualizado PHP
- Localiza todo el PHP que tienes expuesto. Webs corporativas, tiendas online, intranets, paneles de hosting, aplicaciones de terceros y equipos con PHP integrado.
- Actualiza a la versión corregida de tu rama (8.5.12, 8.4.27, 8.3.36 u 8.2.35) o instala el paquete que publique tu distribución o tu proveedor de soporte.
- Reinicia PHP-FPM, Apache y cualquier proceso de larga duración. Sin reinicio, el intérprete antiguo sigue en memoria.
- Prioriza lo que está expuesto a internet y coordina con tu proveedor de hosting.
- Vigila señales de intrusión. Según SOC Prime, un indicador habitual son procesos de PHP que lanzan procesos hijo inusuales.
- Si no puedes actualizar un sistema expuesto, aíslalo de las redes públicas hasta aplicar la corrección, tal como recomienda INCIBE-CERT.
Si usas el repositorio voluntario rpms.remirepo.net, PHP advirtió el 21 de octubre de que no tendría actualizaciones ese día y recomendó usar los paquetes de la distribución o compilar desde el código fuente. Comprueba su estado antes de depender de él.
Si detectas indicios de que tu servidor ha sido comprometido, trátalo como tal: aíslalo, conserva los registros y cambia credenciales y claves. Y si hay datos personales afectados, recuerda que el RGPD (art. 33) exige notificar la brecha a la autoridad de control, con carácter general, en un plazo de 72 horas. Consulta con tu delegado de protección de datos o tu asesor legal.
Mitigaciones temporales: qué cubren y qué no
PHP publicó medidas para reducir la exposición mientras no se puede actualizar. Su propio aviso es claro: reducen rutas de ataque concretas, pero no hacen segura la instalación.
| Medida | A qué CVE afecta | Limitaciones |
|---|---|---|
| memory_limit=-1, aplicado de forma administrativa (no modificable por las aplicaciones) | CVE-2026-109618 | No es una solución completa y puede aumentar el consumo de memoria. Un memory_limit=128M no desactiva la vulnerabilidad |
| post_max_size bajo (8 MB sin subida de archivos, 32 MB si es necesaria) y límites en servidor web o proxy | CVE-2026-109618 | No usar RLIMIT_AS ni RLIMIT_DATA: pueden provocar el fallo de asignación que activa la ruta vulnerable |
| session.upload_progress.enabled=0 y reinicio de todos los procesos | CVE-2026-109619 | Bloquea las rutas de sesión confirmadas, no otras variantes. Debe ir en php.ini, el pool de FPM o la configuración del servidor, no en ini_set() ni .user.ini |
| fatal_error_backtraces=0 (solo PHP 8.5) | CVE-2026-109619 | Bloquea únicamente la ruta de trazas de error fatal |
Un cortafuegos de aplicaciones web (WAF) puede ayudar, y es una de las capas que recomendamos para proteger tu web del tráfico automatizado, pero no sustituye al parche: un desarrollador del núcleo de PHP advirtió de que ninguna mitigación bloquea por completo los ataques, según BleepingComputer.
Preguntas frecuentes sobre CVE-2026-109618 y CVE-2026-109619
¿Qué son CVE-2026-109618 y CVE-2026-109619?
CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell, son dos vulnerabilidades críticas del propio PHP. Permitían que un atacante ejecutara código en un servidor que procesa peticiones web sin necesidad de autenticarse. Ambas tienen una puntuación CVSS v4.0 de 9,2 y se corrigieron el 21 de octubre de 2026.
¿Qué solución se dio?
PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen ambos fallos. Para las ramas sin soporte (7.4, 8.0 y 8.1) hay parches mínimos de código fuente y correcciones retroportadas de proveedores como Ubuntu, cPanel o TuxCare. En todos los casos hay que reiniciar los procesos de PHP para que el cambio surta efecto.
¿Actualizar WordPress corrige CVE-2026-109618 y CVE-2026-109619?
No. El fallo está en el intérprete de PHP del servidor, no en WordPress, en un tema o en un plugin. La corrección llega con una versión de PHP parcheada, que instala quien gestiona el servidor: tu hosting, tu distribución Linux o tu imagen de contenedor. Después hay que reiniciar los procesos de PHP.
¿Qué versión de PHP debo instalar?
La versión corregida de tu rama: PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. La rama 8.2 solo recibirá correcciones de seguridad hasta el 31 de diciembre de 2026, así que conviene planificar el salto a una rama más reciente. Si usas paquetes de tu distribución, comprueba que incluyen la corrección.
¿Cómo sé qué versión de PHP usa mi web?
En WordPress, entra en Herramientas, Salud del sitio, pestaña Información y abre la sección Servidor. También puedes consultarlo en el panel de tu hosting o ejecutar php -v en el servidor. Si tu proveedor aplica una corrección retroportada, el número de versión puede no cambiar: pídele confirmación por escrito.
¿Mi hosting compartido está protegido?
Depende de tu proveedor. En hosting compartido no puedes instalar el parche tú mismo: debe hacerlo la empresa de hosting. Pregúntale qué versión de PHP corre en tu plan, si ya ha aplicado la corrección y si ha reiniciado los procesos. Si no puede confirmártelo, valora cambiar de plan o de proveedor.
¿Qué hago si mi web usa PHP 7.4 u 8.1?
Esas ramas ya no reciben versiones oficiales de PHP. El proyecto solo ha publicado parches mínimos de código fuente, y han salido correcciones retroportadas de Canonical (PHP 8.1 en Ubuntu 22.04 y PHP 7.4 en Ubuntu 20.04 con Ubuntu Pro), cPanel, el repositorio de Ondřej Surý, Remi, TuxCare y otros proveedores. Pregunta a tu hosting cuál aplica y pídele confirmación por escrito; la solución duradera es migrar a PHP 8.4 u 8.5 tras probar tu web y sus plugins.
¿Sigue habiendo riesgo hoy?
Si tu PHP no se ha actualizado y reiniciado, sí. Hubo intentos de explotación masivos, aunque a 25 de octubre las fuentes consultadas no confirmaban compromisos generalizados y CISA no incluía estas CVE en su catálogo KEV. Con PHP actualizado y reiniciado, ambos CVE quedan cubiertos.
¿Puede la actualización romper mi web?
En 8.4.27 y 8.5.12 se detectó una regresión de SimpleXML que puede provocar caídas con el error zend_mm_heap corrupted en plugins o importadores que usen esa extensión. Las versiones 8.3.36 y 8.2.35 no están afectadas. La corrección ya está en el código de PHP y llegará con la próxima versión; no se recomienda volver a una versión sin parche.
Cómo podemos ayudarte desde Addmira
Si no sabes qué versión de PHP ejecuta tu web, quién la mantiene o si tu hosting ya ha aplicado la corrección, nosotros podemos ayudarte a comprobarlo y a planificar una migración ordenada a una rama de PHP con soporte. Es un trabajo que hacemos a menudo: en la tienda WooCommerce de una galería de arte de Barcelona, el servidor corría una versión antigua de PHP, y actualizarla formó parte del trabajo de optimización que llevó su puntuación móvil de PageSpeed de 26 a 88.
Puedes ver cómo trabajamos en nuestros proyectos.
Fuentes consultadas
- PHP.net: aviso de seguridad y versiones publicadas
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618) y GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- INCIBE-CERT: Múltiples vulnerabilidades en PHP
- ENISA: comunicado conjunto sobre las vulnerabilidades críticas de PHP
- Alexandre Daubois: lo que los rumores de PHP2Shell no explicaban bien
- Tenable: preguntas frecuentes sobre PHP2Shell
- The Hacker News: intentos de explotación de PHP2Shell
- BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
- Ubuntu: ficha de seguridad de CVE-2026-109618
- cPanel: registro de cambios de EasyApache 4
- WordPress Hosting Handbook: regresión de SimpleXML
