Dos vulnerabilidades críticas en PHP —un lenguaje de programación utilizado por cerca del 70% de los sitios web cuyo lenguaje del lado del servidor se conoce— han dejado expuestos a sistemas sin parches, tras la difusión prematura de detalles técnicos.
El alcance del riesgo es alarmante. Según VirusTotal, un servicio de ciberseguridad en línea que ayuda a determinar si archivos, sitios web, dominios o direcciones IP están vinculados a malware u otras amenazas, 5,1 millones de direcciones IP utilizan PHP; de ellas, unas 758.000 emplean versiones que ya no cuentan con soporte oficial.
«No se trata necesariamente de sistemas confirmados como vulnerables, pero las cifras ponen de relieve la posible magnitud de la exposición, especialmente en el caso de versiones antiguas que tal vez nunca reciban parches oficiales», señaló la firma de seguridad de software Echo en una publicación en LinkedIn.
El riesgo de que los atacantes aprovechen estas vulnerabilidades para tomar el control de sitios web es tan elevado que la NSA recomienda a las organizaciones que utilizan PHP desconectar los sistemas afectados si no es posible realizar una actualización inmediata. Por su parte, Finlandia, los Países Bajos y Francia habrían comenzado a desconectar sus sitios web gubernamentales.
Los parches para ambas vulnerabilidades de PHP —identificadas como CVE-2026-109618 y CVE-2026-109619— se publicaron el miércoles. Echo explicó que el lanzamiento estaba previsto originalmente para el 22 de octubre, pero el 20 de octubre apareció información técnica en el sitio web Hacker News. Además, comenzaron a circular capturas de pantalla en línea y se publicó un video que demostraba cómo explotar dichas vulnerabilidades, aunque fue retirado poco después.
«Dos fallos críticos de ejecución remota de código en PHP, ambos con una puntuación de 9,2, representan uno de los escenarios más graves posibles en el entorno web», declaró a TechNewsWorld Eylam Milner, director de tecnología (CTO) y cofundador de Echo.
Esto es lo que sucede cuando la inteligencia artificial descubre un fallo que ha permanecido oculto durante años, señaló.
«Algo que ayer no preocupaba a nadie se convirtió, de la noche a la mañana, en una emergencia», afirmó. «En este caso, los detalles sobre cómo explotar las vulnerabilidades circularon antes de que los responsables de la seguridad dispusieran de los parches, lo que dio ventaja a los atacantes».
«El equipo de PHP ha hecho un buen trabajo en una situación sumamente difícil», añadió. «El problema para la mayoría de las empresas es que no saben dónde están ejecutando PHP. Se encuentra en imágenes base y en componentes que incluyen su propio entorno de ejecución; además, gran parte de estas instalaciones corresponden a versiones anteriores a la 8.2, las cuales ya han llegado al final de su vida útil».
¿Cuándo está justificado desconectar los sitios web?.
Madelein van der Hout, analista sénior de Forrester Research —una firma nacional de investigación tecnológica con sede en Cambridge, Massachusetts—, explicó que lo que hace que estas vulnerabilidades sean significativas es su ubicación.
«PHP sustenta sitios web y aplicaciones en numerosas organizaciones y sus proveedores; por lo tanto, no basta con revisar únicamente el sitio web corporativo», señaló. «Las organizaciones deben determinar dónde están expuestas y priorizar los sistemas que están expuestos a internet».
Ella se mostró a favor de desconectar los sitios web para abordar el problema. «Que un sitio web se desconecte no significa necesariamente que haya sido hackeado», afirmó. «Cuando una organización aún no puede aplicar parches o proteger adecuadamente un sistema potencialmente vulnerable, desconectarlo de forma temporal puede ser una decisión proporcional al riesgo: es preferible aceptar una breve pérdida de disponibilidad antes que arriesgarse a un compromiso de seguridad potencialmente mucho más grave».
Asimismo, aconsejó a las organizaciones tener presente que una vulnerabilidad crítica, un intento de ataque y un compromiso de seguridad exitoso son tres cosas distintas. «Las organizaciones deben responder con urgencia ante una posible exposición, sin asumir que todo sitio web vulnerable o desconectado es prueba de una brecha de seguridad», indicó. «Esta distinción es importante, especialmente mientras la situación sigue evolucionando».
«Se trata de una prueba de resiliencia operativa, no solo de gestión de parches», añadió. «Las organizaciones deben decidir si pueden mantener los servicios en funcionamiento de manera segura mientras responden, y determinar quién tiene la autoridad para desconectarlos en caso de que no sea posible. Una desconexión temporal puede ser la decisión correcta, pero esto demuestra cómo una vulnerabilidad de software puede derivar en una interrupción de la actividad empresarial, incluso sin que exista una brecha de seguridad confirmada».
Corregir la vulnerabilidad y buscar intrusos.
La publicación de los parches para PHP constituye un paso importante; sin embargo, las organizaciones no deben confundir la aplicación de parches con una garantía de que sus sistemas están libres de amenazas, señaló Matt Hull, vicepresidente de ciberinteligencia y respuesta en NCC Group, una consultora global de ciberseguridad. «Actualmente estamos recibiendo informes sobre actividades de explotación, lo que hace que el intervalo entre el momento en que se conocen estas vulnerabilidades y la aplicación de parches en los sistemas sea especialmente crítico», comentó. «Existe una posibilidad real de que los sistemas vulnerables ya hayan sido comprometidos, incluso mediante la creación de puertas traseras».
«El impacto potencial es grave», añadió. «Una explotación exitosa podría proporcionar acceso a una consola remota (shell) y, potencialmente, permitir a un atacante realizar movimientos laterales hacia otras áreas del entorno de la organización. Por tanto, quienes gestionan sus propios sistemas PHP —especialmente aquellos expuestos a Internet— deben verificar no solo si han aplicado los parches, sino también si existen indicios de que un atacante haya obtenido acceso con anterioridad».
Benny Lakunishok, cofundador y director ejecutivo de Zero Networks —un proveedor de soluciones de microsegmentación automatizada y redes de confianza cero (zero-trust) con sede en Tel Aviv, Israel—, explicó que las vulnerabilidades en PHP podrían otorgar a los atacantes el control de servidores expuestos sin necesidad siquiera de una contraseña.
«En las próximas 48 horas, preveo una carrera entre las organizaciones que aplican parches y los atacantes que intentan explotar los sistemas que permanecen vulnerables», declaró. «La inteligencia artificial podría acelerar aún más esta carrera, ayudando a los atacantes a desarrollar y escalar sus exploits».
«El verdadero peligro no es solo el compromiso inicial», añadió. «Es lo que los atacantes pueden alcanzar después: bases de datos, credenciales, aplicaciones internas y, en última instancia, el resto de la infraestructura empresarial».
«Nadie ha logrado nunca ir siempre un paso por delante de los atacantes mediante la aplicación de parches», continuó. «Debemos dejar de considerar la remediación como la única solución y empezar a pensar en medidas compensatorias. Hay que aplicar el parche a la vulnerabilidad, pero también implementar controles que eviten que un servidor comprometido se convierta en una catástrofe para toda la empresa».
Ecos de Heartbleed.
Ramy Rahman, ingeniero principal de soluciones en ArmorCode —una empresa de gestión de vulnerabilidades con sede en Palo Alto, California—, comparó el impacto potencial de las vulnerabilidades en PHP con el caso de Heartbleed, que afectó a aproximadamente 4,5 millones de personas y cuya mitigación costó más de 500 millones de dólares estadounidenses.
«Es demasiado pronto para determinar si el impacto real será comparable», señaló. «Lo que cambia hoy es que la IA permite a los atacantes actuar con mayor rapidez, dejando a los defensores menos tiempo para aplicar los parches».
«La IA facilita el análisis de grandes volúmenes de código y permite volver a examinar fallos que antes se consideraban demasiado complejos de explotar», afirmó. «Además, ayuda a los atacantes a realizar ingeniería inversa sobre los parches, reduciendo el intervalo entre la publicación de una corrección y la aparición de un exploit».
«Vulnerabilidades que antes considerábamos inviables de explotar vuelven a estar sobre la mesa», continuó. «Los riesgos subyacentes no son nuevos, pero explotarlos resulta cada vez más sencillo y accesible para más personas. Necesitamos replantearnos viejas suposiciones y acelerar los procesos de aplicación de parches». Shane Fry, director de tecnología de RunSafe Security —una empresa de seguridad de software con sede en McLean, Virginia—, añadió que, históricamente, convertir un error complejo de seguridad de la memoria en un ataque eficaz requería un alto nivel de experiencia y tiempo, pruebas reiteradas y un conocimiento detallado del software vulnerable. «La IA está reduciendo drásticamente ese esfuerzo», comentó.
«Ya no podemos asumir que una vulnerabilidad es relativamente inofensiva simplemente porque su explotación parece demasiado difícil», señaló. «Las organizaciones deben reforzar el software durante su ejecución, de modo que los atacantes no puedan convertir, de manera fiable, una corrupción de la memoria en el control de un sistema».
