Así es PHP2Shell, el fallo que amenaza a siete de cada diez webs

PHP2Shell es el nombre que la comunidad de seguridad ha dado a dos vulnerabilidades críticas en PHP, el lenguaje con el que funciona alrededor del 70% de las webs. El equipo del proyecto publicó este miércoles las versiones corregidas, acompañadas de un mensaje poco habitual: no hay ajuste posible que proteja del todo. Solo sirve actualizar a las últimas versiones del lenguaje de programación, algo que no todas las webs podrán hacer rápidamente. Shell es como se conoce a una línea de comandos abierta en la máquina de otro, y eso es lo que permiten estos fallos. Un atacante puede enviar una petición a una web y acabar ejecutando código en el propio servidor, sin necesidad de tener un usuario o contraseña. Buena parte de la infraestructura de la web, de WordPress a Drupal, descansa sobre este lenguaje de programación, y no todo el mundo utiliza sus últimas versiones. El alcance del problema, por tanto, puede ser enorme. Cómo funciona Cada vez que alguien visita una página de WordPress o compra en una tienda Magento, por poner dos ejemplos, un proceso de PHP recibe la petición, la desgrana, consulta la base de datos y fabrica una página a medida para el usuario. Al terminar, limpia la memoria usada y espera la siguiente petición. Los dos fallos aprovechan justo esos dos momentos del ciclo de preparación y limpieza de memoria. El primero, catalogado como CVE-2026-109618, aparece cuando PHP se queda sin memoria. El intérprete fija un límite para cada petición y, si lo alcanza, abandona lo que esté haciendo de golpe. Si eso ocurre mientras PHP está montando sus estructuras internas, las deja a medio construir y, en la fase de limpieza, las trata como si estuvieran completas. Un atacante puede forzar esa situación con peticiones sin tamaño declarado que esquivan los controles habituales, o con otras fórmulas parecidas que terminan por saturar el proceso y corromper su memoria. A partir de ahí, puede llegar a ejecutar su propio código. El segundo, CVE-2026-109619, aprovecha que PHP reutiliza el mismo proceso para atender peticiones sucesivas. Si un error interrumpe una petición en el momento justo, quedan restos, como errores o datos de sesión, que apuntan a memoria ya liberada, y la siguiente petición los usa antes de que se limpien. Con una manipulación cuidadosa de la memoria, eso basta para ejecutar código. A contrarreloj Explotarlos no es trivial, pero ambos tienen una puntuación de 9,2 sobre 10 en la escala CVSS, que mide la gravedad de una vulnerabilidad. Llegan además en un momento en el que la inteligencia artificial acorta mucho el camino entre conocer un fallo y convertirlo en un ataque. Los detalles iban a hacerse públicos este jueves, pero un mensaje en el foro Hacker News anticipó el martes la existencia de los fallos. PHP tuvo que adelantar un día la publicación de los parches. Tres equipos dieron con ellos entre finales de julio y agosto, con pocas semanas de diferencia, tras más de una década en el código de PHP. Los tres los descubrieron aprovechando los últimos modelos de inteligencia artificial. La firma Calif y el equipo de seguridad de OpenAI usaron el modelo GPT-5.6 Sol, y Wiz, propiedad de Google, combinó ese modelo con Gemini 4 Argon y una herramienta propia. Según Wiz, la IA permitió que un solo investigador hiciera en una semana lo que antes habría llevado meses a un equipo especializado. Los fallos se habían mantenido en secreto mientras PHP preparaba los parches para mitigarlos pero, una vez filtrados, los ataques no tardaron en aparecer. "En las 10 horas antes de que se anunciara públicamente, en toda la red Cloudflare vimos miles de intentos de explotarlo. Decenas de miles en los 45 minutos posteriores al anuncio, cientos de miles a las 2 horas y millones ahora mismo", explicaba a última hora de la tarde de ayer Matthew Prince, CEO de la empresa de infraestructura de red Cloudflare. Unit 42, la división de investigación de Palo Alto Networks, calcula que más de 22,6 millones de aplicaciones web y servidores están expuestos. Solo las ramas con soporte activo de PHP (8.2 en adelante) tienen parche completo, y es habitual que muchas aplicaciones usen versiones antiguas, sobre todo en software empresarial y servicios web históricos. Actualizar o desconectar La gravedad de los fallos ha llevado a gobiernos de varios continentes a aconsejar que, si no se puede actualizar, lo mejor es directamente desconectar. La división de ciberseguridad del FBI pidió en X a las organizaciones que no puedan aplicar el parche de inmediato que retiren sus sistemas de Internet hasta resolver el problema, que conserven los registros del servidor y que denuncien cualquier intrusión. La NSA hizo la misma recomendación y advirtió de que este tipo de fallos suele dar acceso directo a los archivos y a la base de datos del servidor. En Europa, el CERT-EU, el equipo que protege a las instituciones comunitarias, aconsejó ya el martes aislar de las redes públicas las aplicaciones expuestas hasta poder corregirlas. En Japón fue la propia primera ministra, Sanae Takaichi, quien pidió en X a las organizaciones que comprobaran si sus webs usan PHP y que valoraran suspenderlas temporalmente si no podían parchearlas a tiempo. Muchas lo han hecho. Partes de Wikipedia, el foro 4chan y webs de organismos públicos de Países Bajos, Finlandia, Francia, Dinamarca y Alemania se desconectaron el miércoles por precaución, entre ellas la del Parlamento holandés. No solo PHP El aviso de PHP coincidió con una jornada especialmente intensa para los equipos de seguridad. Node.js, el entorno con el que se ejecuta JavaScript en los servidores, publicó las versiones 22.23.4, 24.22.1 y 26.12.1 para corregir diez vulnerabilidades. La más grave, en el descompresor Brotli, permite ejecutar código de forma remota. Otras permiten burlar la verificación de certificados TLS, el mecanismo que garantiza que un servidor es quien dice ser. GitLab, una de las plataformas más usadas para alojar y gestionar código, corrigió también un fallo con la máxima puntuación posible, 10 sobre 10. Permite a un atacante sin credenciales ejecutar código en las instalaciones que las empresas gestionan en sus propios servidores y afecta a versiones publicadas desde 2014. La compañía asegura que no ha detectado ataques. Railway, una plataforma en la nube para desplegar aplicaciones, detuvo todas las aplicaciones de sus clientes tras detectar que un atacante podría haber accedido a sus variables de entorno, donde suelen guardarse claves de API y contraseñas de bases de datos. La empresa no ha explicado cómo se produjo el acceso, pero lo enmarca en una serie de ataques contra plataformas de este tipo cuyo objetivo final serían los proveedores de inferencia de IA. Ha pedido a sus usuarios que cambien todas sus credenciales. Ninguna de las tres compañías, en cualquier caso, ha vinculado estos incidentes con PHP2Shell.