ciencia_tecnologiaTecnologíaTecnología Digital

¿Qué pasó con los dos fallos críticos en PHP? La inteligencia artificial ayudó a descubrirlos

La Habana, 30 oct.- Un visitante entra en una página, consulta un producto o intenta subir una fotografía. No necesita iniciar sesión ni introducir una contraseña. Basta con que envíe una petición preparada para aprovechar un fallo oculto en el programa que sostiene el sitio. Al otro lado, el servidor puede terminar ejecutando órdenes ajenas a sus administradores.

Ese escenario dejó de ser una hipótesis abstracta el 21 de octubre último, cuando el equipo de PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas en el núcleo de este lenguaje de programación. Los investigadores de Wiz Research, responsables del hallazgo, demostraron que podían aprovecharlas para ejecutar código sin autenticación en servidores con aplicaciones como WordPress, Drupal y Joomla.

La amenaza recibió el nombre de PHP2Shell. Sin embargo, el problema no se limita a una plataforma concreta: afecta al propio motor que procesa las instrucciones de PHP, por lo que una aplicación puede quedar expuesta aunque su código no contenga errores.

La advertencia cobró mayor alcance el 23 de octubre, cuando el proyecto reconoció un tercer fallo, todavía sin una actualización correctiva disponible. La carrera entre quienes buscan cerrar estas brechas y quienes intentan explotarlas apenas comienza.

Una grieta en los cimientos

PHP trabaja detrás de millones de páginas web. Genera contenido, procesa formularios, gestiona sesiones y facilita la comunicación con bases de datos. Según las estadísticas de W3Techs, el lenguaje aparece en el 69,2 por ciento de los sitios web cuyo lenguaje de servidor se conoce. Esa presencia explica por qué un defecto en su núcleo puede afectar a servicios muy distintos.

El primer fallo, identificado como CVE-2026-109618, aparece cuando PHP agota la memoria disponible durante una petición. En determinadas circunstancias, el proceso de limpieza posterior puede manejar datos internos que nunca llegaron a inicializarse correctamente. Esa confusión abre la posibilidad de corromper la memoria y, bajo condiciones propicias, ejecutar código malicioso.

El segundo, CVE-2026-109619, responde a otro descuido en la gestión de memoria. Un proceso puede conservar referencias a información de una petición anterior después de que PHP haya liberado el espacio que ocupaba. Si otra solicitud llega antes de que el programa restablezca su estado, puede utilizar esos datos obsoletos para alterar el funcionamiento del servidor.

Ambas vulnerabilidades recibieron una puntuación de 9,2 sobre 10 en la escala CVSS 4.0, que mide la gravedad de los fallos de seguridad. En la práctica, un atacante podría tomar control del proceso PHP, acceder a información sensible, modificar contenidos o preparar nuevas acciones contra el sistema.

El equipo de PHP señaló que el riesgo alcanza a las instalaciones que atienden solicitudes web, incluidas las que emplean PHP-FPM, php-cgi y Apache con mod_php. Esta última configuración presenta un peligro mayor: las pruebas demostraron que una petición sin autenticación puede activar el fallo antes de que la aplicación comience a procesarla.

El CERT-EU, equipo de respuesta a incidentes de ciberseguridad de las instituciones europeas, recomendó corregir las instalaciones afectadas y aislar de internet aquellas que no pudieran actualizarse de inmediato.

Cuando la inteligencia artificial encuentra lo que otros no vieron

El hallazgo añade otro elemento al papel sobre el desempeo de la inteligencia artificial (IA). Los investigadores de Wiz Research utilizaron modelos avanzados de IA para examinar el código de PHP, explorar comportamientos anómalos y construir una secuencia capaz de convertir errores de memoria en una vía de ejecución remota.

Según su informe técnico, el trabajo comenzó el 19 de agosto. El equipo confirmó la ejecución de código en Drupal al día siguiente y en WordPress el 21 de agosto. El 24 de agosto comunicó los hallazgos al equipo de PHP, que preparó las correcciones antes de publicarlas el 21 de octubre.

La investigación reveló debilidades que habían permanecido ocultas durante años. La IA no sustituyó el trabajo de los especialistas: ayudó a explorar el código, plantear hipótesis y reducir el tiempo necesario para probarlas. La validación de los resultados y la coordinación con los responsables del lenguaje siguieron siendo esenciales.

Aquí aparece la otra cara de la herramienta. Si los investigadores defensivos pueden encontrar fallos con mayor rapidez, los atacantes también pueden utilizar modelos de IA para analizar programas, adaptar pruebas de explotación y automatizar parte de sus operaciones. El resultado podría ser una reducción del tiempo que transcurre entre la publicación de una vulnerabilidad y los primeros intentos de aprovecharla.

Los registros de F5 Labs ilustran esa velocidad. La empresa detectó exploraciones dirigidas contra PHP2Shell el 21 de octubre, más de cinco horas antes de que el equipo de PHP publicara los avisos y las actualizaciones. Después de la divulgación, sus sensores registraron miles de intentos de explotación.

Sophos también informó de actividad maliciosa relacionada con estos fallos. Sus análisis describieron intentos de explotación y advirtieron de que los resultados dependían de la configuración del servidor y de las defensas instaladas. Detectar una petición hostil, sin embargo, no demuestra por sí solo que el atacante haya conseguido entrar.

La distinción importa: algunos investigadores demostraron la explotación en entornos de prueba, mientras las empresas de seguridad observaron intentos contra sistemas reales. La evidencia disponible no permite afirmar que todos esos intentos culminaran en una intrusión exitosa.

Actualizar ya no basta

El equipo de PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir los dos fallos críticos. Quienes administran servidores deben instalar la versión correspondiente a su rama y comprobar que el servicio utiliza realmente el paquete actualizado. También deben revisar los registros en busca de actividad sospechosa.

Las versiones 8.1 y anteriores ya no reciben mantenimiento ordinario del proyecto. Para ellas, los administradores deben consultar a su proveedor de sistema operativo o soporte extendido, comprobar la disponibilidad de correcciones y planificar la migración a una rama mantenida.

Pero el episodio tuvo una continuación. El 23 de octubre, PHP informó de CVE-2026-115560, un tercer fallo que podría permitir la ejecución remota de código bajo una combinación poco habitual de ajustes y comportamiento de la aplicación. Las actualizaciones publicadas dos días antes no lo corrigen.

Como medida temporal, el equipo recomendó desactivar el seguimiento del progreso de las cargas de archivos mediante un ajuste, hasta que llegue una versión correctiva. La recomendación debe aplicarse desde la configuración administrativa del servidor y verificarse después de reiniciar los procesos afectados.

La lección trasciende a PHP. Con los modelos de IA capaces de ayudar a descubrir errores que llevan años escondidos y contribuir a corregirlos antes de que alguien los explote o, por el contrario, acelerar la búsqueda de objetivos y la preparación de ataques, la diferencia entre una vulnerabilidad publicada y una crisis de seguridad depende, en buena medida, de cuánto tarde cada administrador en identificar sus sistemas, aplicar las correcciones y comprobar que funcionan. La IA puede acortar el camino hasta el fallo. La defensa tendrá que aprender a recorrerlo con la misma rapidez. (Tomado de Juventud Rebelde)