PHP corrige 2 fallos críticos que permiten ejecutar código de forma remota

El proyecto PHP pide a los administradores actualizar sus servidores tras el descubrimiento de dos vulnerabilidades capaces de conducir a una ejecución remota de código. La alerta concierne a un lenguaje muy presente en la Web, pero la cifra del 70 % mencionada en la prensa no corresponde al número de sitios efectivamente vulnerables.

Dos vulnerabilidades pueden conducir a una ejecución de código

El equipo de PHP publicó varias actualizaciones de seguridad este 22 de octubre. Su advertencia no deja lugar a dudas: «vulnerabilidades críticas de ejecución remota de código: actualice ahora». Una ejecución remota de código, o RCE, puede permitir a un hacker ejecutar comandos en un servidor sin contar con acceso legítimo.

Las dos principales vulnerabilidades afectan a la gestión de la memoria y al estado interno de PHP. Sin embargo, su explotación depende de condiciones técnicas específicas. Por lo tanto, no se trata de un ataque universal que comprometería automáticamente cada sitio construido con este lenguaje.

Las dos vulnerabilidades críticas se basan en mecanismos diferentes :

• La primera, referenciada como GHSA-w8hw-w9fx-j79w, explota una corrupción de memoria provocada cuando PHP se queda sin memoria durante ciertas operaciones. El programa puede entonces conservar datos incompletos antes de reutilizarlos cuando el proceso se detiene ;
• La segunda, identificada bajo la referencia GHSA-6wmf-4rv5-p3rp, se basa en un estado global obsoleto. Una primera operación deja una información en memoria, que luego otra solicitud reutiliza como si aún fuera válida.

En ambos casos, un hacker debe lograr desencadenar una secuencia particular de operaciones. Sin embargo, los avisos oficiales mencionan un riesgo de ejecución de código, lo que explica el nivel de urgencia adoptado por el proyecto PHP.

Los parches publicados también cubren otras vulnerabilidades menos críticas. Incluyen una evasión de las restricciones de acceso de PHP-FPM con ciertas direcciones IPv6, un error en la verificación de certificados TLS y un desbordamiento de memoria en el componente OpenSSL. También se corrigieron problemas que afectan a los archivos Phar, al protocolo SOAP y al controlador nativo de MySQL.

La cifra del 70 % no designa sitios vulnerables

PHP equipa una parte considerable de los sitios cuyo lenguaje del servidor es conocido. Se encuentra especialmente detrás de WordPress, Drupal, Joomla y muchas aplicaciones diseñadas a medida. Esta difusión explica por qué una vulnerabilidad crítica en su motor suscita rápidamente una gran inquietud.

Afirmar que el 70 % de Internet está amenazado sigue siendo impreciso. Este porcentaje mide el uso general de PHP, no la proporción de servidores que ejecutan una versión vulnerable. Tampoco toma en cuenta los sistemas ya corregidos, las configuraciones diferentes o las condiciones necesarias para cada ataque.

Un sitio puede usar WordPress sin estar directamente expuesto a estas dos vulnerabilidades. Según el análisis on-chain, el riesgo depende de la versión de PHP instalada por el proveedor, de las extensiones activas y de cómo se procesan las solicitudes. Varios sitios alojados en una misma infraestructura también pueden compartir un motor PHP ya actualizado.

La situación es más preocupante para los servidores que usan una rama antigua y sin soporte. Estas instalaciones ya no reciben los parches oficiales. Por lo tanto, pueden acumular nuevas vulnerabilidades junto con fallas descubiertas en años anteriores.

Una actualización y un reinicio siguen siendo indispensables

Los administradores deben instalar la última versión de seguridad disponible para su rama de PHP. Una simple modificación de los archivos no siempre es suficiente: los servicios PHP-FPM, Apache u otros procesos afectados deben reiniciarse para cargar el motor corregido.

También debe realizarse un inventario de las interfaces de línea de comandos, las tareas planificadas y los contenedores. Un servidor puede de hecho utilizar varias versiones de PHP en paralelo. Corregir la del sitio principal no protege necesariamente una herramienta interna antigua o una imagen de contenedor rara vez actualizada.

Los clientes de un alojamiento compartido pueden verificar la versión activa en su espacio de administración o pedir confirmación a su proveedor. Generalmente no disponen de los permisos necesarios para aplicar ellos mismos el parche al sistema.

No se ha establecido ninguna explotación masiva de estas dos vulnerabilidades en los avisos oficiales consultados. Sin embargo, esta ausencia no reduce la urgencia. La publicación de los detalles técnicos facilita su estudio tanto por investigadores como por hackers. Por lo tanto, la medida más segura sigue siendo una actualización rápida acompañada de una revisión de los registros del servidor para detectar comportamientos inusuales.