Se descubrió una vulnerabilidad crítica en PHP que permite la ejecución remota de código, la cual fue detectada recientemente por una IA de OpenAI aunque los mantenedores la conocían desde hace dos años. El problema afecta a millones de servidores, agravado por el hecho de que la mayoría utiliza versiones obsoletas sin soporte oficial. Aunque existen parches y mitigaciones mediante firewalls, el incidente resalta la precariedad del software de código abierto y la urgencia de actualizar sistemas antiguos.

La frase "cuando llueve, truena" se aplica tanto al clima como a la seguridad informática, como quedó demostrado la semana del 19 de octubre de 2026, cuando el GPT 5.6-Sol de OpenAI descubrió vulnerabilidades críticas en el lenguaje de programación de código abierto PHP. Según se publicó en un análisis posterior, un pequeño equipo de mantenedores conocía el problema hace dos años. Los expertos en seguridad habían advertido durante décadas sobre la creciente deuda técnica, ya que la IA agéntica aceleró exponencialmente el escaneo de vulnerabilidades, hasta el punto de que la ventana habitual de divulgación de 90 días para los exploits de seguridad se volvió inútil. PHP, uno de los paquetes de software ubicuos de internet, tuvo la mala suerte de estar en el punto de mira de los agentes de IA cazadores de errores.

PHP aloja alrededor del 70% de los sitios web en internet, y la vulnerabilidad permite la ejecución remota de código con el conocimiento suficiente del atacante. Esa combinación es suficiente para hacer sonar las alarmas, pero la situación empeoró una vez que el internet colectivo se dio cuenta de que, en ese momento, el 73% de las instalaciones de PHP en línea ejecutaban versiones obsoletas sin soporte activo, provocando gestos de incredulidad en muchos técnicos y un suspiro exasperado de cualquiera familiarizado con el ecosistema, yo incluido. Así que, en última instancia, el problema no era realmente la vulnerabilidad, sino la complacencia general.

Cómo surgió el ataque

La causa raíz de la vulnerabilidad fue una decisión arquitectónica antigua en el manejo de errores del motor de PHP. Cuando un proceso de PHP se queda sin memoria, llama a la función C longjmp(), que significa "salta inmediatamente la ejecución a otro lugar, sin hacer preguntas". Usar longjmp() sin una razón muy buena es generalmente desaconsejable, aunque eso por sí solo no era el problema.

Últimos videos de Tom's Hardware

Mira el video completo aquí:

El problema real es que si ese salto ocurre mientras se construye una estructura de datos (como añadir una entrada de matriz o inicializar un objeto), esos datos a medio terminar permanecen en el montón de memoria (heap). Cuando el motor de PHP mueve la ejecución a su mecanismo de limpieza y salida, ese código se ejecutará esperando datos correctos y completos, pero en su lugar actuará sobre bytes sobrantes inconsistentes.

Con una inyección inteligente del contenido adecuado en una solicitud web, este mecanismo puede ser explotado para ejecutar cualquier código con los permisos de PHP, como muestra el exploit continuo PHP2Shell.


Obtener una shell remota requiere que el atacante conozca la versión exacta y la compilación de PHP utilizada, por lo que no es tan trivial como presionar un botón de "Hackear". Sin embargo, el amplio radio de impacto, con decenas de millones de servidores vulnerables, muchos de ellos ejecutando la misma versión exacta, es suficiente para preocupar a cualquiera. Después de que la vulnerabilidad se hiciera pública, muchos administradores de sistemas desactivaron el reporte del número de versión en su instalación de PHP para no ayudar a los hackers potenciales.

El análisis posterior de la Fundación PHP indica que el equipo conocía el problema desde hace dos años, pero no lo vio inmediatamente como un motivo de preocupación, y dudaron varias veces sobre la mejor manera de solucionar el problema manteniendo la compatibilidad con extensiones de terceros.

El equipo admitió haber cometido errores de gestión, pero es una organización pequeña con un empleado a tiempo completo y 14 contratistas a tiempo parcial, encargados de mantener una de las piezas de software más extendidas de internet. Este es un patrón común: software de código abierto que es de importancia crítica para la informática moderna, pero que carece de personal, de financiación, o de ambas cosas.

El exploit es solo la mitad del problema

El proceso de parcheo estándar es razonablemente trivial, requiriendo solo una actualización puntual y quizás el reinicio de algunos servicios. Las ramas de PHP mantenidas actualmente son de la 8.1 hasta la actual 8.5. No obstante, los administradores de sistemas rara vez instalan PHP directamente, confiando en su distribución de Linux preferida o en repositorios comunitarios para obtener paquetes actualizados.

Ese 73% de sitios que todavía están atrapados con PHP 7 se encuentran ahora entre la espada y la pared. Cuando PHP pasó de 7.4 a 8.0 a finales de 2020, hubo varios cambios en el lenguaje, la mayoría menores, pero que aun así requerían trabajo de revisión. Mucha gente probablemente esperaba que su distribución siguiera aplicando correcciones retrospectivas (backporting), especialmente para las variantes LTS (Soporte a Largo Plazo) que aún estaban en su periodo de soporte, con PHP 7.4 incluido. Esa excusa es posiblemente siempre un poco débil, ya que incluso antes de la era de la IA ya existían herramientas automatizadas para actualizar el código PHP existente con relativamente poco trabajo.

Ahora, dependiendo de su situación específica, aquellos que dependen de versiones antiguas como la 7.3 o anteriores pueden verse obligados a actualizar el código de sus sitios web, dado que no todas las distribuciones tienen correcciones retrospectivas. Como referencia, PHP 7.3 salió en 2018. Para empeorar las cosas, casi el 8% de las instalaciones de PHP son de la versión 5.x, que salió en 2005. Además, varios dispositivos de red, cajas NAS y hardware similar llevan PHP integrado, y eso también necesitará actualizarse. Palo Alto Networks emitió un aviso de seguridad para los productos impulsados por su sistema PanOS, por ejemplo.

Sin embargo, no todo es pesimismo. Dado que la Fundación PHP publicó parches de código fuente desde la 7.4 hasta la 8.1, casi cualquier persona puede diseñar un parche para las versiones más antiguas. Muchas entidades lo hicieron, y hay paquetes disponibles para sabores de Debian/Ubuntu de Ondřej Surý que cubren desde PHP 5.6 hasta 8.1. CloudLinux y AlmaLinux también han producido correcciones retrospectivas.

Esta es una ocasión en la que pagar por soporte extendido resulta útil, ya que proveedores comerciales como Ubuntu Pro y Zend lanzaron paquetes de corrección para versiones de PHP verdaderamente antiguas, hasta la 5.5. Es probable que el código de sitios web antiguos tenga otras vulnerabilidades además del motor de PHP, por lo que una actualización y mejora integral es mucho preferible, pero muy pocos CTO escucharán esa canción.

Otras opciones

Dada la magnitud del problema, y que pasará tiempo antes de que cada máquina esté protegida, existen otros medios para mitigar el problema, aunque la solución adecuada es actualizar a una versión de PHP parcheada. Los firewalls de aplicaciones web (WAF) como Immunify360 pueden bloquear solicitudes maliciosas antes incluso de que lleguen al servidor.

Las redes de entrega de contenido (CDN) como Cloudflare o Fastly ofrecen universalmente opciones para añadir un WAF a su configuración. Ambas firmas emitieron inmediatamente sus respectivos avisos de protección y notificaciones, añadiendo la detección de PHP2Shell a sus conjuntos de reglas. Finalmente, las suites de seguridad a nivel de servidor como CrowdStrike también pueden detectar y bloquear la actividad maliciosa del propio binario de PHP, en caso de que un atacante intente algo extraño. Es razonable suponer que estas protecciones han frenado los esfuerzos de explotación.

Entonces, ¿en qué punto estamos?

En este momento, el exploit PHP2Shell está circulando, con al menos un caso de alto perfil que involucra una campaña que encadenó la vulnerabilidad de PHP con Fragnesia (también conocido como Dirty Frag) para eventualmente obtener acceso a nivel de kernel en 25 servidores aparentemente vinculados al gobierno de EE. UU. Hasta el 29 de octubre, la firma de seguridad BitSight había registrado numerosos intentos de intrusión de PHP2Shell a través de su flota de monitoreo, desde muchos orígenes distintos.

Los investigadores de foros de la dark web de BitSight indican que no había un paquete de exploit universal disponible en esa fecha. Esto puede indicar que las campañas de hacking por ahora probablemente sean objetivos específicos, pero es inevitable que aparezca el proverbial "botón rojo de un solo clic" en algún momento, probablemente con un exploit más profundo, como en el ejemplo de Fragnesia anterior.

Mientras tanto, varias firmas de ciberseguridad han seguido de cerca el progreso del parcheo desde la revelación del 19 de octubre. Censys tiene una vista en tiempo real actualizada cada hora, y baste decir que las cosas podrían ir mucho mejor. El recuento inicial estimó el número de instalaciones de PHP vulnerables en unos 45,7 millones, de un total de 119 millones.

El número de servicios sin parchear ha bajado misericordiosamente a unos 29 millones al momento de escribir esto, indicando aparentemente una tasa de parcheo de alrededor de 1 millón por día, dependiendo de cómo se cuente. Cabe señalar que las correcciones retrospectivas pueden no cambiar el número de versión, por lo que esas instancias podrían seguir contando como no parcheadas.

Pero recuerden que la mayoría desactivó el reporte del número de versión de PHP de su servidor. Según Censys, el 62% de los servidores PHP que consulta no reportan ese dato en absoluto, por lo que no hay forma de saber cuáles podrían ser los totales reales. Si la historia es un indicador, un porcentaje significativo de esas máquinas permanecen sin parchear hoy en día.

Fuente:
TomsHardware