El sábado 17 de octubre de 2026, una de las trampas que Amazon tiene repartidas por internet para estudiar ataques (los honeypots de su red MadPot) registró una petición extraña dirigida a PHP. Cuatro días después, el 21 de octubre, el equipo de PHP publicaba el parche para dos fallos críticos que hasta entonces nadie conocía públicamente. Es decir: alguien estaba probando el ataque antes de que existiera la solución. Amazon reconoce que no sabe cómo consiguió ese actor la información antes de tiempo.
Los dos fallos se conocen ya como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Ambos tienen una puntuación de 9,2 sobre 10 y permiten, en las condiciones adecuadas, ejecutar código en el servidor sin usuario ni contraseña. Afectan al propio intérprete de PHP, no a un plugin o a un gestor de contenidos concreto: da igual que la web sea un WordPress, una tienda online o una aplicación hecha a medida.
🔍 ¿Dudas de un mensaje recibido?
Analiza remitentes, enlaces o archivos en tiempo real con nuestro scanner.
Por qué un fallo en PHP afecta a tantas webs a la vez
PHP es el lenguaje con el que funciona la mayor parte de la web. Según W3Techs, lo usa el 69,3 % de los sitios cuyo lenguaje de servidor se conoce. Cuando el fallo está en el intérprete, todas esas webs comparten el mismo punto débil hasta que su servidor se actualiza.
El alcance en el tiempo también es amplio. El equipo de Calif, uno de los que investigó el fallo, sitúa el código afectado más antiguo en PHP 5.4.0. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para las ramas 7.4, 8.0 y 8.1 el proyecto solo ha publicado correcciones de código fuente, sin versiones oficiales, y las anteriores no tienen arreglo. Un detalle importante: algunas distribuciones y paneles de hosting aplican la corrección a su propio paquete sin cambiar el número de versión, así que el número por sí solo no siempre dice toda la verdad.
Los dos fallos, explicados
El primero (CVE-2026-109618) tiene que ver con lo que ocurre cuando PHP se queda sin memoria a mitad de una petición. Si eso pasa mientras los datos internos de la petición están solo a medio preparar, la limpieza posterior los trata como si fueran válidos. Ese estado incoherente es la puerta de entrada.
El segundo (CVE-2026-109619) es un problema de «restos» entre peticiones. Parte del estado de una petición puede sobrevivir después de que su memoria se haya liberado, y una petición posterior atendida por el mismo proceso puede llegar a usarlo antes de que se reinicie. Es lo que en programación se llama un uso de memoria ya liberada (use-after-free).
Las consecuencias dependen de cómo esté montado el servidor. Según el propio proyecto PHP, la configuración de mayor riesgo es Apache con mod_php, donde se ha demostrado un ataque que se dispara antes de que llegue a ejecutarse el código de la web. En PHP-FPM, una de las vías de ataque queda bloqueada por cómo arranca el proceso, pero PHP ha validado igualmente la ejecución de código por otra vía en condiciones adecuadas. Además, los investigadores demostraron que se puede leer memoria del proceso sin autenticarse, y esa memoria puede contener contraseñas, tokens de sesión y claves de API.
Atacado antes de tener parche, y a gran escala después
La cronología explica la urgencia. El 20 de octubre se filtraron los identificadores de los fallos y PHP publicó un aviso previo; el parche se adelantó un día por esa filtración y salió el 21 a las 14:00 UTC. Ese mismo día, desde las 02:00 UTC, Amazon ya vio pruebas de concepto en uso, procedentes de varias infraestructuras de anonimización distintas, lo que apunta a más de un atacante.
Cloudflare ha dado cifras del volumen: miles de intentos en las diez horas previas a la publicación, decenas de miles en los 45 minutos posteriores, cientos de miles en dos horas y millones desde entonces. También ha observado que los atacantes modifican sus peticiones para esquivar los filtros a medida que se los bloquean. Según la firma Hadrian, la mayoría de los ataques observados usan la ruta del indicador de progreso de subida de sesión de PHP.
Hay un matiz que conviene no perder: el equipo de PHP afirma que en el momento de la publicación no había identificado ningún exploit funcional, y Amazon reconoce que no está claro si los intentos llegaron a tener éxito. Pero el volumen de intentos y la velocidad con la que se adaptan son motivo suficiente para tratar la actualización como inmediata. El NCSC británico ha pedido actualizar ya o desconectar el servidor hasta poder hacerlo.
Como dato curioso, varios de los equipos acreditados en el hallazgo (Calif, Wiz y OpenAI, entre otros) han explicado que usaron modelos de inteligencia artificial en la investigación.
Qué significa si tienes una web, y si solo navegas
Si tu web está en un hosting compartido, la actualización de PHP depende de tu proveedor, no de ti. Algunos proveedores ya han parcheado o han desactivado a nivel de servidor el ajuste que más usan los atacantes, pero no todos van al mismo ritmo, y las webs que siguen en PHP 8.1 o anterior son las más expuestas.
Si solo navegas, no tienes que actualizar nada: el fallo está en los servidores, no en el navegador. El riesgo para ti es indirecto. Una web comprometida puede empezar a redirigir a páginas fraudulentas o a ofrecer descargas que nadie ha pedido, y eso es más probable estos días en webs poco mantenidas.
No hagas esto:
- No des por hecho que tu hosting ya ha actualizado PHP. Compruébalo o pregúntalo.
- No instales plugins ni fragmentos de código de terceros que prometan «arreglar PHP2Shell»: el fallo está en el intérprete y solo se corrige actualizándolo.
- No descargues ni ejecutes las pruebas de concepto que circulan para «probar» tu web. Muchas no están verificadas y pueden traer malware.
- No confíes solo en un cortafuegos de aplicaciones (WAF) como el de Cloudflare. Ayuda mientras actualizas, pero los atacantes ya están adaptando sus peticiones para esquivarlo.
- No intentes desactivar el ajuste vulnerable desde
.user.inini conini_set(): no es suficiente. Tiene que hacerse en la configuración principal de PHP. - Si navegas: no aceptes descargas que no hayas pedido ni sigas redirecciones inesperadas, aunque vengan de una web que conoces.
Haz esto:
- Comprueba la versión de PHP de tu web: debe ser 8.5.12, 8.4.27, 8.3.36, 8.2.35 o superior en su rama. Una forma rápida es subir un fichero con
<?php echo PHP_VERSION;, abrirlo en el navegador y borrarlo justo después. - Si la versión es anterior, o si estás en un hosting compartido, pregunta al proveedor si ya tiene aplicado el parche de PHP2Shell (aunque el número no haya cambiado) y si ha desactivado
session.upload_progress.enableda nivel de servidor. - Si tu web sigue en PHP 8.1 o anterior, pasa a una rama con soporte. PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, así que lo razonable es ir a 8.3 o superior, probando antes la web.
- Si administras tu propio servidor: actualiza, reinicia Apache o PHP-FPM y confirma con
php -vque el intérprete que atiende las peticiones es el nuevo. Si no puedes actualizar de inmediato, desactivasession.upload_progress.enabledenphp.inio en el pool de FPM, ponfatal_error_backtraces=0en PHP 8.5, limita el tamaño de las subidas y reinicia los procesos. - Revisa los registros desde el 17 de octubre, no desde el 21: peticiones POST que contengan
PHP_SESSION_UPLOAD_PROGRESS, ficheros nuevos en la carpeta de la web, tareas programadas o cuentas que no reconozcas, y procesos de PHP que lancen intérpretes de comandos o descargas. - Si encuentras indicios de intrusión: aísla la web, guarda los registros antes de tocar nada y cambia todas las credenciales que la web tenga guardadas (base de datos, correo, claves de API), porque este fallo permite leer memoria del servidor.
En una web, el software que no se ve es tan parte de su seguridad como el que se instala. Nadie elige el intérprete de PHP al montar una tienda o un blog, pero es lo que ejecuta cada petición. Esta vez el primer intento de ataque llegó cuatro días antes que el parche: la actualización de estas piezas no se mide en semanas, sino en horas.