Alerta PHP2Shell: CVE-2026-109618 y parche PHP para tu web

Qué ha pasado

El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas de ejecución remota de código (RCE) que no requieren autenticación, bautizadas por la comunidad como PHP2Shell:

CVE-2026-109618: un fallo en el manejo de la memoria (corrupción por out-of-memory) que puede dejar los datos internos de una petición inicializados a medias, y el sistema los trata como si fueran válidos.
CVE-2026-109619: un use-after-free: queda estado interno apuntando a memoria ya liberada, y la siguiente petición que procese el mismo worker puede acabar usándola.

La gravedad es alta (CVSS 9,2) y no es teórica: Amazon detectó explotación real antes de la publicación del parche, y la empresa Sansec reprodujo el ataque con éxito contra WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin y Nextcloud. El NCSC británico llegó a recomendar valorar apagar los servicios que no se pudieran parchear.

Versiones con el parche publicado: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Si tu hosting usa cPanel, también hay versión corregida para PHP 7.4 y superiores, y las distribuciones Linux con soporte a largo plazo suelen backportear el arreglo.

Quién está afectado

Prácticamente cualquier web que corra sobre PHP y no se haya actualizado: WordPress, WooCommerce, PrestaShop, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin, Nextcloud y un largo etcétera.

El punto clave es este: es un fallo del lenguaje PHP, no de cada aplicación. Actualizar WordPress o phpMyAdmin no basta por sí solo; hay que actualizar el PHP del servidor y reiniciar php-fpm, Apache o LiteSpeed, porque el parche solo surte efecto cuando se reinician los workers. Si tu web está en un hosting gestionado (WordPress.com, SiteGround y similares), lo normal es que el proveedor ya lo haya hecho, pero merece la pena confirmarlo.

Actualización 23 de octubre: tercer CVE reconocido

El 23 de octubre el proyecto PHP reconoció oficialmente una tercera vulnerabilidad, CVE-2026-115560: otra ejecución remota de código, esta vez ligada a session.upload_progress cuando la aplicación cambia el serializador de sesión con ini_set() antes de session_start(). No es un bypass de los parches del 21 de octubre: es un vector nuevo y estrecho, que PHP describe como poco habitual en despliegues normales. El arreglo llegará en la próxima release regular de cada rama.

Mientras tanto, la mitigación es una línea en el php.ini del servidor (un ini_set() en la aplicación no llega a tiempo: el upload progress corre antes del código de la app), y reiniciar los workers:

session.upload_progress.enabled = 0

Si ya desactivaste upload progress siguiendo el aviso del 21 de octubre, no tienes que hacer nada más para este vector. Si tu aplicación no toca serializadores de sesión, el riesgo es bajo; aun así, desactivar upload progress si no lo usas es una buena práctica.

Además, en las propias versiones parcheadas (8.4.27 y 8.5.12) hay una regresión verificada de SimpleXML (double-free, php-src #24488): puede provocar crashes si tu aplicación usa SimpleXML, pero no es ejecución remota de código. PHP recomienda no revertir los parches del 21 de octubre; el arreglo está en camino (PR #24494).

Fuente: aviso informativo de PHP del 23 de octubre y el kit defensivo de Syhunt.

Qué hacer hoy

Averigua qué versión de PHP usa tu web (más abajo te cuento cómo).
Si es anterior a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, actualiza el PHP del servidor desde el panel de tu hosting o pídeselo a tu proveedor.
Reinicia php-fpm, Apache o LiteSpeed después de actualizar. Sin reinicio, el parche no protege.
Si usas cPanel, elige una versión ea-php74 o superior ya corregida.
Si tu web la mantiene una agencia o un freelance, escríbeles hoy mismo y pide confirmación por escrito de que el PHP está actualizado y los workers reiniciados.
Si hiciste la web con el Kit Digital, contacta con tu agente digitalizador o tu proveedor de mantenimiento y pide la misma confirmación. No es una obligación legal nueva, pero es una comprobación razonable que te corresponde pedir.

Cómo comprobar tu web

Solo en tus propios dominios, nunca escaneando webs ajenas:

WordPress: Escritorio → Herramientas → Salud del sitio → Información → versión de PHP.
Panel de hosting (cPanel, Plesk): busca el selector «Versión PHP».
Por SSH: php -v. Ojo: la versión de la línea de comandos puede diferir de la que usa el servidor web; lo fiable es un phpinfo() temporal o preguntar al hosting.
Preguntar a tu proveedor de hosting directamente.
Comprobadores online (verificados el 22-10-2026): senseforat.cat, una herramienta gratuita y pasiva en catalán que lanza una sola petición desde fuera, sin tocar nada, para saber si una web muestra PHP y con qué versión frente a PHP2Shell; php2shell.sh de Imperva, Brandefense, Arvion y Bugshield. Un aviso honesto: leen la versión PHP que tu servidor expone públicamente, y muchos servidores la ocultan, así que un «no detectado» no significa «seguro». Úsalos solo con dominios propios y confirma con los métodos anteriores.

Node.js y phpMyAdmin

El mismo día, Node.js publicó sus propias actualizaciones de seguridad: 10 vulnerabilidades (4 altas) en las ramas 26.x, 24.x y 22.x, con la más grave siendo ejecución remota de código en el decodificador Brotli. Las versiones corregidas son 26.12.1, 24.22.1 y 22.23.4. Node 18 y Node 20 están fuera de soporte y no recibirán parche: si algo tuyo corre ahí, toca migrar.

phpMyAdmin no tiene parche propio: se protege actualizando el PHP del servidor donde corre, igual que el resto.

Otros que también ayudan

No hace falta que todo salga de aquí. Estos recursos los he verificado hoy y los comparto tal cual:

senseforat.cat — herramienta gratuita y pasiva en catalán: lanza una sola petición desde fuera, sin tocar nada, para saber si una web muestra PHP y con qué versión frente a PHP2Shell. Guarda un registro público de resultados (máximo 10 escaneos por minuto) y vigila además las webs de los 947 municipios de Cataluña con datos abiertos de la Generalitat.
YesWeLab — experimento con fuentes públicas (php.net, BOE, NVD, W3Techs) que estima que unas 115.500 webs del Kit Digital (horquilla 82.900–166.700) siguen en versiones de PHP sin parche para PHP2Shell. Señala que las bases de la solución «Sitio web» (2.000 €) exigían hosting, accesibilidad y SEO, pero la palabra «seguridad» no aparece ni una vez; recoge la recomendación de CISA de desconectar sistemas con PHP 8.1 o anterior; y ofrece un script gratuito para que los agentes digitalizadores inventaríen el CMS y las versiones de su cartera de webs.
transparencia.omitsis.com — un buen ejemplo del modelo, hecho por Omitsis, uno de mis clientes: un evaluador gratuito de transparencia para fundaciones, ONG y asociaciones que revisa hasta 30 páginas y PDFs y entrega un informe con la norma concreta de cada punto.

Somos bomberos, no competidores

Cuando el incendio es de esta magnitud, no se pregunta de qué cuadrilla eres. PHP2Shell no es una oportunidad comercial: es un desastre natural a escala global que puede afectar a miles de millones de personas de forma directa o indirecta — la tienda de abajo, el ayuntamiento del pueblo, la web de la asociación del barrio. Estos días los ingenieros no somos proveedores: somos bomberos. Nadie compite con nadie: todos tiramos de la misma manguera.

Por eso esta página enlaza sin pudor a recursos hechos por otros equipos: si tu web está en riesgo, te sirve igual venga de quien venga. Vamos todos a una.

Fuentes

Si necesitas ayuda con tu web —comprobar la versión de PHP, actualizar con seguridad o revisar el servidor—, escríbeme y te echo una mano.

Alerta PHP2Shell: actualiza el PHP de tu web

Comprueba tu web