Si tu web funciona con PHP y el motor no está actualizado desde el 21 de octubre de 2026, da igual que WordPress, los plugins, el tema y el inicio de sesión estén impecables: un atacante sin cuenta puede llegar a ejecutar código en tu servidor. Lo establece el aviso de seguridad oficial de PHP, que corrige dos vulnerabilidades críticas bautizadas como PHP2Shell.Son la CVE-2026-109618 y la CVE-2026-109619, ambas con una puntuación de 9,2 en la escala CVSS 4.0. El equipo de PHP ha publicado las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y pide a todo el mundo que actualice de inmediato. Según Wiz, una de las firmas que las descubrieron, todas las versiones publicadas en la última década están afectadas por al menos uno de los fallos, desde PHP 5.4, y además permiten leer trozos de la memoria del servidor.La pregunta que importa para cualquier webmaster con la web «bien cuidada» es otra: ¿qué me juego si no toco PHP?¿Por qué no te protege tener WordPress y los plugins actualizados?Porque el fallo no está en tu web, sino en el programa que la ejecuta. PHP es el intérprete que procesa cada petición antes de que tu código, sea WordPress o un desarrollo propio, haga nada.Wiz lo resume con un ejemplo incómodo: incluso una aplicación mínima tipo «Hello World» puede ser vulnerable si corre sobre una versión afectada. Y The Hacker News recuerda lo que muchos administradores confunden: actualizar WordPress o Laravel no actualiza PHP. El motor llega del paquete del servidor, del proveedor de hosting o de la imagen del contenedor.El problema, según el aviso oficial, está en cómo PHP gestiona la memoria cuando una petición falla a medias, sobre todo cuando se queda sin memoria. En un caso, PHP interrumpe su trabajo con datos internos a medio preparar y después los trata como válidos. En el otro, conserva referencias a memoria que pertenecía a una petición anterior y que ya se ha liberado.Un atacante solo tiene que enviar peticiones HTTP preparadas para provocar esas situaciones. Con Apache y mod_php, el escenario de mayor riesgo según PHP, una sola petición sin autenticar desencadena el ataque antes de que se ejecute el código de la aplicación. Tu contraseña robusta y tu segundo factor ni siquiera llegan a entrar en juego.¿Qué puede hacer un atacante con una web sin parchear?Tres cosas, de peor a menos mala: tomar el control del servidor, leer datos sensibles de su memoria o tumbar el servicio. Ninguna requiere usuario ni contraseña.La primera es la ejecución remota de código. Wiz demostró ataques sin autenticación contra las imágenes de contenedor más recientes de WordPress, Drupal y Joomla, y advierte de que la explotación permite controlar el servidor, robar datos y desfigurar las webs alojadas. El NCSC británico añade un detalle que lo dice todo: si no puedes actualizar ya, revisa el sistema en busca de puertas traseras instaladas por un atacante. Parchear tarde no limpia lo que alguien haya dejado dentro.La segunda es menos espectacular y quizá más peligrosa para una web que se cree a salvo. Sin llegar a ejecutar código, un atacante puede leer memoria del proceso de PHP que, según Wiz, puede contener contraseñas, tokens de autenticación, claves de API y certificados de otras peticiones o del propio servidor. Wiz la sitúa en la línea de Heartbleed y asegura que la fuga funciona sea cual sea la aplicación, incluso si la web no usa sesiones.Mi lectura: un token de sesión robado vale tanto como una contraseña y no pasa por la pantalla de login. Si en ese momento un administrador está trabajando en el panel, sus credenciales viajan por la misma memoria que el atacante está leyendo.La tercera es la caída del servicio. Cloudflare explica que el mismo mecanismo puede hacer caer procesos de PHP: menos grave, pero suficiente para dejar una tienda sin vender.¿Se está atacando ya o es solo teoría?Hay intentos de ataque documentados, pero ninguna intrusión confirmada públicamente a fecha de publicación. La ventana entre el parche y los ataques ha sido mínima porque la información se filtró antes de tiempo.Según la PHP Foundation, el 20 de octubre, hacia las 15:00 UTC, los dos identificadores empezaron a circular por foros y redes con una hora de publicación y una puntuación de 10 que eran falsas. PHP adelantó el lanzamiento un día, al 21 de octubre a las 14:00 UTC. Por el camino, una de las firmas que informaron de los fallos publicó por error un vídeo con su prueba de concepto, que aceleró la aparición de otras pruebas de concepto.Cloudflare asegura que, tras la filtración, observó tráfico de ataque contra sus clientes, con atacantes modificando la carga para esquivar sus reglas. Desplegó protecciones en su cortafuegos web (WAF) desde las 3:02 UTC del 21 de octubre, también en el plan gratuito, pero pide parchear igualmente.Algunas organizaciones no esperaron. En Países Bajos, DigiD y MijnOverheid se desconectaron como precaución, según la cadena NOS citada por The Hacker News, y la empresa de nóminas BambooHR apagó su servicio en Estados Unidos, Canadá e Irlanda. El investigador Kevin Beaumont lo calificó, según Help Net Security, como «una de las mayores vulnerabilidades en años».¿Qué pasa si tu versión de PHP ya no recibe actualizaciones?Que el riesgo es el mismo, pero la solución oficial no llega sola. PHP 8.1 y anteriores ya no reciben parches del proyecto, y PHP 8.2 deja de tenerlos el 31 de diciembre de 2026.El equipo de seguridad ha publicado parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP. El resto depende de su distribución o de un proveedor de soporte extendido, que recibieron el parche por adelantado. Ojo con un detalle: un paquete de distribución puede llevar la corrección con un número de versión que parece antiguo, así que lo que hay que comprobar es que el registro de cambios mencione los dos CVE.Las medidas temporales existen, pero el aviso oficial es tajante: reducen la exposición a rutas de ataque concretas y no hacen segura una instalación. Hablamos de ajustes como fijar memory_limit=-1, bajar post_max_size a 8M (o 32M si hay subidas de archivos) y desactivar session.upload_progress.enabled. La desarrolladora del núcleo de PHP Gina Peter Banyard lo dijo antes del parche, según The Hacker News: la única mitigación es actualizar PHP.El NCSC va más allá: si no puedes actualizar ni aplicar las mitigaciones a tiempo, plantéate desconectar el sistema. Es el mismo patrón que dejó sin frío a cientos de tiendas con los controladores de refrigeración sin soporte que tumbaron supermercados franceses: equipos olvidados y expuestos que nadie se encarga de retirar.¿Qué tienes que comprobar después de actualizar?Que la versión nueva es la que de verdad responde a las peticiones y que nadie entró antes. Actualizar el paquete sin reiniciar Apache, PHP-FPM y los procesos de PHP de larga duración deja funcionando el código viejo.El parche añade además un límite de memoria estricto: si se alcanza, el proceso termina. Conviene revisar memory_limit y post_max_size contra lo que necesita la aplicación para no provocar caídas propias.Para detectar una intrusión previa, conviene buscar en los registros peticiones multipart inusuales seguidas de errores de límite de memoria o de errores HTTP 500 repetidos, cookies PHPSESSID anormalmente grandes y reinicios inexplicables de procesos de PHP. Wiz avisa de que, como el ataque ocurre por debajo de la aplicación, los registros de la web pueden aportar poco contexto. Si guardas datos de usuarios y encuentras indicios, ellos tendrán que saber qué hacer en la primera hora cuando sus datos aparecen en una filtración.Esta historia va más allá de PHP. Wiz encontró su primer fallo el 19 de agosto con su herramienta Wiz Atlas y los modelos Gemini 4 Argon y GPT-5.6 Sol, y sostiene que con IA frontera un solo investigador hizo en una semana lo que antes habría llevado meses a un equipo de primer nivel. La propia PHP Foundation reconoce que vio las primeras señales del problema de memoria en 2024 y que el arreglo se atascó durante meses; lo califica de «fallo estructural». Desde el 1 de julio ha publicado 15 CVE y descartado más de 100 informes inválidos, duplicados o no reproducibles.Mi lectura es que el cálculo del webmaster ha cambiado. Durante años, «actualizo PHP cuando cambie de hosting» era una apuesta razonable porque explotar fallos de memoria así exigía un talento escaso. Si la IA abarata ese trabajo, como ya mostró el piloto británico que encontró 407 fallos con IA frontera en un mes, el tiempo entre parche y ataque se mide en horas. Una web con todo al día salvo el intérprete no es una web segura: es una web con la puerta blindada y los cimientos abiertos.La noticia PHP2Shell: qué le puede pasar a tu web si no actualizas PHP, aunque WordPress, los plugins y el login estén al día fue publicada originalmente en Wwwhatsnew.com por Natalia Polo.