PHP2Shell: el fallo de PHP que afecta a millones de webs, explicado sin tecnicismos y qué hacer hoy

Si tu web funciona con WordPress, WooCommerce, PrestaShop, Joomla, Drupal o cualquier programa a medida, casi seguro que por debajo corre PHP. Y el 21 de octubre de 2026 el equipo de PHP tuvo que publicar parches de emergencia para dos fallos críticos que permiten a un desconocido, sin contraseña ni cuenta, ejecutar órdenes en el servidor donde vive tu web. Los llaman PHP2Shell.

Esta guía está escrita para quien tiene una web y necesita entender qué ha pasado, si le afecta y qué tiene que hacer hoy, sin ser informático. No es un análisis forense línea a línea: es lo que hay que saber, con las fechas y los datos contrastados con las fuentes originales (al final las tienes todas), y con lo que hemos visto nosotros al revisar más de 150 webs.

En 30 segundos. Son dos fallos de PHP (CVE-2026-109618 y CVE-2026-109619), de gravedad 9,2 sobre 10, que se pueden explotar por internet sin identificarse. Ya se están usando. Actualizar WordPress o los plugins no los arregla: hay que actualizar PHP, y eso lo controla tu hosting. Pregúntale a tu proveedor, o míralo tú en su panel, qué versión corre tu web y que sea una de las parcheadas: 8.2.35, 8.3.36, 8.4.27 u 8.5.12 (o superior).

Qué ha pasado, día a día

El patrón es el de siempre en estos casos: los atacantes no esperan a que tú te enteres. Entre que se publica un parche y se empieza a usar el fallo contra webs reales pasan horas, no semanas.

Qué es PHP2Shell, sin tecnicismos

PHP es el motor que ejecuta tu web: recibe cada visita, hace las cuentas, consulta la base de datos y devuelve la página. Para hacerlo, reserva trozos de memoria, los usa y los libera. Los dos fallos están en ese trabajo de bastidores:

• CVE-2026-109618. Si a PHP se le acaba la memoria justo mientras prepara una petición, deja la información a medio construir y, al recoger, la trata como si estuviera completa. Un atacante puede provocar esa situación a propósito y aprovechar el desorden.
• CVE-2026-109619. PHP se deja información de una petición apuntando a memoria que ya ha liberado, y la petición siguiente que atiende ese mismo proceso puede acabar usando esos restos. Es el equivalente a que el siguiente cliente reciba un papel con datos de otro.

Piénsalo como un mostrador de atención al público. Alguien llega y entrega un paquete con una forma que la persona del mostrador no sabe procesar bien; se hace un lío con sus propios papeles, deja cosas sin recoger y el siguiente visitante, que sabe exactamente qué ha pasado, consigue que ejecute sus instrucciones. El visitante no necesita ni tarjeta de socio ni haber entrado nunca: basta con entregar el paquete.

Lo grave es dónde ocurre. Según el propio proyecto PHP, el caso más peligroso (el de Apache con el módulo mod_php) se puede explotar antes de que se ejecute una sola línea de tu web. Por eso no importa lo bien que esté programada tu tienda ni lo fuerte que sea tu contraseña de administrador: el atacante no pasa por ahí.

Los dos fallos puntúan 9,2 sobre 10 en la escala CVSS 4.0. Con ellos, quien ataca puede ejecutar código con los permisos con los que corre PHP en tu cuenta, o leer partes de la memoria del servidor.

Por qué actualizar WordPress y los plugins no te salva

Es lo que más confunde. Durante años el consejo ha sido «mantén al día WordPress, el tema y los plugins», y sigue siendo un buen consejo, pero aquí no basta. El fallo está en el intérprete de PHP, que es una capa por debajo. Investigadores de seguridad han demostrado que se puede obtener acceso a un servidor en versiones concretas de WordPress, Drupal, Joomla y Magento, y también en MediaWiki, Symfony, Laravel y phpBB. Es decir, da igual qué programa uses.

Tampoco lo arreglan un cortafuegos de WordPress ni un plugin de seguridad, porque esos plugins son código PHP que corre dentro del mismo motor afectado. Algunos servicios de red (como el cortafuegos de Cloudflare) han publicado reglas para frenar los intentos más conocidos, pero la propia empresa los describe como un parche provisional que solo protege el tráfico que pasa por ellos.

A quién afecta

A cualquier servidor que sirva páginas con PHP: Apache con mod_php, PHP-FPM (lo más habitual en hostings compartidos), php-cgi, LiteSpeed o FrankenPHP. mod_php es el escenario más peligroso, pero el resto no está a salvo. El código afectado existe, según los investigadores, desde PHP 5.4.0, de modo que hablamos de más de una década de versiones.

PHP está en torno al 69 % de las webs cuyo lenguaje de servidor se conoce. Las estimaciones de servidores expuestos varían muchísimo según cómo se cuente: desde 1,3 millones (una búsqueda concreta de un investigador) hasta más de 22 millones de instancias identificadas por una gran empresa de seguridad. Quédate con la idea, no con la cifra: son muchísimos.

Qué versiones están arregladas

Las ramas 7.4, 8.0 y 8.1 llevan años sin soporte de seguridad regular (7.4 terminó en 2022, 8.0 en 2023 y 8.1 a finales de 2025). Por eso este episodio es un buen momento para dejar de posponer una migración que, antes o después, habrá que hacer.

Cómo saber qué PHP usa tu web

Hay tres caminos, de menos a más técnico:

1. En el panel de tu hosting. Casi todos tienen un apartado «PHP», «Versión de PHP» o «Configuración de PHP» por dominio. Algunos proveedores incluso marcan cada versión como segura o insegura frente a este fallo.
2. En WordPress. Entra en Herramientas, Salud del sitio, Información, Servidor: ahí aparece la versión de PHP que está sirviendo realmente tu web.
3. Preguntándoselo a tu hosting o a quien te mantiene la web. Es lo más rápido y deja constancia por escrito.

Hay una trampa. Que el panel diga «8.3» solo te dice la rama, no el número exacto, y es el proveedor quien decide qué parche concreto instala. Pide que te confirmen que la versión que corre tu web incluye la corrección de los CVE-2026-109618 y CVE-2026-109619. Y fíjate en la versión que sirve la web, no en la de la línea de comandos del servidor, que puede ser otra distinta.

Qué hacer, paso a paso

1. Haz una copia de seguridad de archivos y base de datos, y comprueba que se puede restaurar. Si no tienes una rutina, tienes una guía aparte sobre copias de seguridad.
2. Averigua tu versión actual con alguno de los tres caminos de arriba.
3. Cámbiala a una versión parcheada. En la mayoría de hostings es un desplegable. Si no tienes un motivo para otra cosa, 8.3 u 8.4 es el punto dulce: son estables, están muy soportadas por plugins y temas y tienen años de soporte por delante. La 8.5 es la más reciente y también vale si tu web está al día.
4. Espera a que el cambio se aplique. En algunos paneles no es instantáneo: se solicita y se aplica en unos minutos. Después, los procesos de PHP deben reiniciarse; actualizar el paquete no basta si los antiguos siguen corriendo. Tu proveedor se encarga de ello, pero pregúntalo.
5. Prueba tu web. Recorre la home, un formulario, el área de cliente y, si tienes tienda, un pedido de prueba. Mira el registro de errores. Los temas y plugins muy antiguos son los que suelen dar problemas al saltar de versión.
6. Si algo falla, no vuelvas a una versión vulnerable por comodidad. Actualiza o sustituye ese plugin; si de verdad no hay alternativa a corto plazo, deja la web en una rama parcheada y arregla el problema concreto, o pídenos ayuda.

Un detalle práctico: las versiones 8.4.27 y 8.5.12 tienen un fallo conocido que puede hacer caer algunas aplicaciones que usan la extensión SimpleXML. La corrección ya está aceptada pero, a fecha de 26 de octubre, aún no se ha publicado. Si te afecta, la salida más sencilla es la rama 8.3 parcheada mientras tanto.

Si hoy no puedes actualizar: mitigaciones parciales

El propio proyecto PHP es claro: ningún ajuste de configuración cierra del todo el problema. Lo único completo es actualizar. Aun así, hay dos medidas que reducen el riesgo mientras llega el cambio, siempre que tu hosting te deje tocar la configuración:

session.upload_progress.enabled = 0
memory_limit = -1

Qué hacen y qué cuestan:

• Desactivar el progreso de subida de sesión cierra una de las rutas conocidas del segundo fallo y del tercero. A cambio, desaparecen las barras de progreso de subida de archivos de algunas aplicaciones (poco frecuentes).
• Quitar el límite de memoria reduce la oportunidad de provocar el primer fallo, pero también elimina una protección útil contra scripts descontrolados. Es una medida de urgencia, no de largo plazo, y debe ir acompañada de un límite de memoria a nivel de servidor para que un descontrol no tumbe la máquina entera. Si no sabes cómo, no la toques y pide ayuda.
• En PHP 8.5 se recomienda además fatal_error_backtraces = 0.
• Después de cambiar cualquiera de ellos hay que reiniciar los procesos de PHP.

Si tienes tu web detrás de un servicio de protección como Cloudflare, mantenlo, pero no lo tomes por solución: solo ve el tráfico que pasa por él.

¿Me han hackeado ya?

Lo honesto es que, si tu web iba con una versión vulnerable en estos días, no lo puedes descartar por intuición. Dicho eso, no hay motivo para el pánico: los ataques masivos son automáticos y la mayoría de intentos no tienen éxito. Esto es lo que hay que mirar, de lo más sencillo a lo más técnico:

• Cambios que no has hecho tú: páginas nuevas, textos raros, enlaces a farmacias o casinos, redirecciones extrañas al abrir la web desde el móvil o desde Google.
• Usuarios administradores nuevos que no reconoces.
• Archivos .php en carpetas donde no deberían estar, sobre todo en la de subidas (wp-content/uploads), con fechas de estos días.
• Tareas programadas (cron) que no instalaste, o un consumo de CPU y de tráfico saliente que se dispara sin motivo.
• Avisos de tu hosting o de Google («este sitio puede estar en peligro»).

Si usas WordPress, puedes comparar los archivos del núcleo con los originales con wp core verify-checksums y pasar un escáner de seguridad de confianza. Si encuentras algo, lo prudente es guardar los registros antes de tocar nada, restaurar desde una copia limpia anterior a esos días, cambiar todas las contraseñas (administración, base de datos, FTP y SSH) y, después, actualizar PHP. Actualizar sin limpiar no expulsa a quien ya está dentro.

Lo que no debes hacer

• No descargues «comprobadores de PHP2Shell» de sitios desconocidos. En las primeras horas circularon herramientas y pruebas de concepto sin verificar que podían contener código malicioso. Para saber si estás protegido no necesitas ejecutar nada: te basta con la versión.
• No des el problema por cerrado por haber bloqueado las subidas de archivos o activado un plugin de seguridad. Son capas útiles, no la solución.
• No pienses que tu web es demasiado pequeña. Estos ataques son automáticos: barren direcciones, no negocios. A nadie le importa lo que vendes; le importa tu servidor.
• No contrates un servicio por miedo. La solución cuesta lo que cuesta cambiar un desplegable y probar tu web.

Lo que hemos visto al revisar más de 150 webs

En 3CWeb hemos comprobado, una por una, la versión real de PHP que sirve cada web de nuestros proyectos y de los de nuestros clientes (con un archivo de prueba temporal que se borra al instante, para ver la versión que realmente sirve cada una). Estas son las conclusiones que sacamos, por si te sirven para pensar en la tuya:

• La versión de PHP es de lo que menos se mira en una web. Casi nadie sabe qué tiene, y casi todo el mundo da por hecho que «ya se actualizará solo». No es así: en muchos hostings la versión se elige por dominio y se queda como está durante años.
• Alrededor de cuatro de cada diez webs estaban en ramas (7.4, 8.0 u 8.1) que no tienen versión oficial parcheada. No son un desastre inmediato si el proveedor aplica los parches mínimos, pero es una deuda que conviene pagar.
• Un pequeño grupo seguía en versiones antiguas de verdad, sin parche posible. Esas son las primeras que se mueven.
• Antes de subir de versión, lo que más tiempo se lleva no es el cambio, sino comprobar que ni el tema ni los plugins se rompen. Por eso conviene hacerlo con calma y con copia, no con prisas.

Lo que todavía no se sabe

Hay datos que todavía se mueven y conviene tomar con cautela:

• No hay una cifra fiable de cuántas webs han sido comprometidas. Se han visto intentos de ataque en servidores señuelo y en tráfico real, pero no hay un recuento. Y conviene desconfiar de las atribuciones rápidas: una empresa de seguridad llegó a vincular un ataque a una administración pública europea con estos fallos y dos días después lo retiró por no poder confirmarlo.
• Los detalles técnicos siguen cambiando. Hay fuentes que se contradicen en fechas o en qué configuraciones son realmente explotables fuera de mod_php. Mientras se aclara, el criterio prudente es el del propio PHP: considera afectada cualquier instalación que sirva páginas.
• El tercer fallo (CVE-2026-115560) está pendiente de corrección en la próxima versión regular. Su riesgo se considera bajo y requiere una combinación poco habitual de configuración y código, pero merece que desactives el progreso de subida de sesión si puedes.

Por eso la recomendación a medio plazo no es «parchea y olvida», sino dejar de depender de ramas que ya no se mantienen y tener a alguien que mire esto cada cierto tiempo.

Cómo piensa un atacante (y por qué no hace falta que seas un objetivo interesante)

Nadie se sienta a mirar tu web y decide atacarla porque le interese tu negocio. Lo normal, con un fallo como este, es al revés: se escribe un programa que recorre direcciones IP o listas de dominios a toda velocidad, le hace a cada una la misma pregunta técnica («¿respondes como una versión vulnerable de PHP?») y, si la respuesta es sí, prueba el ataque automáticamente. Tu web entra en la lista por tener una puerta sin cerrar, no por ser importante.

Ese barrido no distingue entre una multinacional y la web de un comercio de barrio: las dos tardan lo mismo en comprobarse. Es la misma lógica que explicamos en nuestra guía de ciberseguridad básica para pymes y autónomos: casi ningún ataque es personal, y precisamente por eso cerrar las puertas obvias (aquí, la versión de PHP) elimina ya la inmensa mayoría del riesgo.

Ejercicio de hacking ético: así se ve un ataque clásico, en un entorno simulado

PHP2Shell es un fallo demasiado nuevo, demasiado técnico y todavía con demasiados servidores sin parchear como para enseñarlo con un ataque real: publicar ese paso a paso sería repartir un arma, no una lección. Pero sí podemos enseñarte, en un entorno simulado y sin servidor real detrás, cómo razona un atacante frente a un fallo clásico de hace más de veinte años, para que entiendas la lógica de fondo: nunca te fíes de lo que escribe un desconocido en un formulario.

Se llama inyección SQL y pasa cuando un formulario construye la pregunta a la base de datos pegando directamente lo que escribe el visitante, en vez de tratarlo siempre como un dato aparte. Esto es lo que ocurre en un inicio de sesión mal protegido:

Qué ha ocurrido exactamente:

1. El formulario monta la consulta pegando el texto del usuario sin ninguna protección: usuario = 'admin'--'.
2. La comilla que escribe el atacante cierra el valor antes de tiempo, y -- convierte el resto de la línea en un comentario para la base de datos.
3. La comprobación de la contraseña, que venía después, deja de ejecutarse: nunca se compara nada, y la sesión se abre igualmente.

Esta técnica concreta lleva décadas corregida en cualquier programa serio (WordPress, WooCommerce o PrestaShop ya protegen sus propios formularios), y por eso puedes verla en abierto sin riesgo: no es un secreto, es uno de los primeros temas de cualquier curso de desarrollo web, y la defensa es sencilla y muy conocida (las «consultas preparadas», que obligan a tratar siempre lo escrito como un dato, nunca como parte de la instrucción). La relevancia para PHP2Shell es la idea, no la técnica: en los dos casos, el problema nace de confiar en algo que ha escrito un desconocido sin comprobarlo antes.

Por el lado del defensor, así es como se ve el aviso cuando tu hosting detecta que tu versión de PHP está en la lista de las afectadas por PHP2Shell:

Si quieres practicar de verdad, hazlo solo contra tus propias webs, contra una web de pruebas que montes tú mismo, o en plataformas pensadas para eso (como TryHackMe o Hack The Box, que son legales porque dan permiso explícito). Probar cualquier técnica, por básica que sea, contra una web que no es tuya y sin autorización es un delito, aunque no consigas nada; no hace falta tener éxito para meterte en un problema legal.

Preguntas frecuentes

Fuentes consultadas

• Tenable: preguntas frecuentes sobre PHP2Shell (cronología, versiones, mitigaciones y CISA).
• JFrog Security Research: todo sobre CVE-2026-109618 y CVE-2026-109619 (causa técnica y mitigaciones).
• watchTowr: PHP2Shell explotado (explotación observada y cómo detectar compromisos).
• Palo Alto Networks, Unit 42: resumen de la amenaza (exposición y la rectificación del 25 de octubre).

Esta guía se ha preparado con la información disponible a 27 de octubre de 2026 y la actualizaremos si cambia algo relevante.