PHP corrige dos fallos críticos: la IA ayuda a encontrarlos, el mantenimiento protege la web

Introducción

Una web puede tener su aplicación actualizada y seguir dependiendo de un motor vulnerable. Es la diferencia que deben comprobar quienes administran servicios con PHP tras las correcciones publicadas el 21 de octubre de 2026. Dos fallos críticos, conocidos como PHP2Shell, permiten ataques sin iniciar sesión en determinados despliegues. Resolverlos exige actuar sobre el PHP del servidor, también cuando el alojamiento lo gestiona otra empresa. [1][2][3]

La investigación utilizó inteligencia artificial, pero la historia empezó antes de esa intervención. Había indicios del problema en 2024, decisiones difíciles sobre cómo repararlo y recursos de mantenimiento limitados. El caso reúne así dos velocidades de la seguridad: descubrir una vía de ataque y conseguir que la corrección llegue a quienes usan el programa.

Dos errores en una pieza compartida

PHP ejecuta en el servidor el código de muchas aplicaciones web. Un fallo en ese motor puede afectar a una aplicación aunque el error no esté en el código de la propia web. Por eso actualizar el gestor de contenidos no demuestra que se haya corregido la pieza que lo ejecuta.

La primera vulnerabilidad, CVE-2026-109618, aparece al tratar el agotamiento de memoria. Una interrupción en un momento delicado puede dejar datos internos incompletos que después se utilizan como válidos. El aviso documenta ejecución remota de código con los permisos de la cuenta del proceso web, incluida una vía en Apache con mod_php anterior a la ejecución de la aplicación. [2]

La segunda, CVE-2026-109619, permite que sobrevivan referencias a memoria liberada entre peticiones atendidas por el mismo proceso. Su reutilización puede provocar filtraciones o ejecución de código. El mantenedor documenta vías demostradas en mod_php y PHP-FPM, con condiciones distintas entre variantes. [3]

El proyecto incluye entre los entornos web en riesgo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Las diferencias de configuración importan para la explotación, pero las medidas que reducen algunas vías de ataque no constituyen, según PHP, una solución completa. [1]

Las primeras versiones corregidas de las ramas con soporte ordinario son estas. El límite se aplica dentro de cada rama, no comparando números de ramas distintas. [2][3]

PHP 8.1 y las ramas anteriores están fuera del soporte ordinario del proyecto. PHP ha facilitado correcciones mínimas en código para 7.4, 8.0 y 8.1. Algunos proveedores de soporte prolongado pueden incorporar parches a sus propios paquetes. En esos casos hay que comprobar el paquete concreto y la corrección incluida, además del número base que muestra. [1]

Lo que aportó la IA y lo que tuvo que resolver el equipo

La Fundación PHP explica que en 2024 un desarrollador detectó indicios de la causa del problema de memoria al corregir resultados de una auditoría de Quarkslab. Entonces no se había demostrado una vía concreta de ejecución remota. El arreglo se demoró entre alternativas con costes de compatibilidad, dificultades de decisión y falta de recursos. La Fundación reconoce que «el retraso fue un fallo estructural». [6] (traducción propia)

Según ese relato, Calif comunicó una ejecución remota el 11 de agosto de 2026 y otros investigadores añadieron hallazgos y vías de ataque. OpenAI atribuye a Calif un hallazgo con GPT-5.6 Sol. Wiz declara haber utilizado Gemini 4 Argon, GPT-5.6 Sol y sus herramientas para encadenar errores y adaptar ataques de demostración. Los mantenedores de PHP lideraron la corrección. [4][5][6][7]

Ryan Austin, investigador de Calif y autor de su relato, explica que conocer el historial del programa orientó la búsqueda. Calif aclara además que no utilizó modelos de acceso restringido en su hallazgo inicial. Son relatos de los participantes, útiles para conocer su método, aunque no permiten aislar cuánto aportó cada herramienta. [7]

La velocidad de investigación puede beneficiar a la defensa: demostrar una vía de ataque ayuda a priorizar y comprobar una reparación. También puede facilitar el trabajo del atacante. El resultado para la seguridad depende de que la capacidad de encontrar fallos vaya acompañada de recursos y coordinación para corregirlos.

De dónde sale el 80 %

La presencia de PHP en la web explica la importancia de una dependencia compartida, pero no permite contar instalaciones vulnerables. W3Techs registró el 21 de octubre un 69,3 % de uso de PHP entre los sitios cuyo lenguaje de servidor podía identificar. Su serie histórica recogía un 80,6 % en enero de 2015. Son cifras de adopción, con fechas y denominador definidos. No miden webs comprometidas ni permiten atribuir el origen de cada titular que repite el 80 %. [8][9]

Para saber qué ocurre en una instalación hacen falta su versión, el paquete del proveedor, la configuración y las vías de acceso. Para quien administra una web, la tarea inmediata es obtener esa respuesta y confirmar la corrección con su proveedor si corresponde.

La lección más amplia afecta a quienes dependen de esos servicios sin conocer PHP. Encontrar un fallo protege cuando el hallazgo se convierte en una reparación comprobada, distribuida e instalada. Las herramientas pueden acelerar la investigación. Sostener a los equipos que mantienen las piezas compartidas decide si ese avance se convierte en seguridad para todos.