Vulnerabilidad en PHP que podría comprometer cualquier sitio PHP

Los desarrolladores de PHP han anunciado la publicación hoy a las 17:00 (MSK) de versiones de corrección de emergencia (8.5.12, 8.4.27, 8.3.36 y 8.2.35), que abordarán dos vulnerabilidades críticas. Se recomienda a todos los administradores de servidores con PHP que instalen las correcciones en sus sistemas inmediatamente después de su publicación. Oficialmente, los detalles se revelarán solo después de que aparezcan las correcciones, pero de acuerdo con la información que ha salido a la luz, se trata de las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, que potencialmente permiten ejecutar código de forma remota en cualquier servidor web que ejecute scripts PHP en configuración predeterminada. Los problemas se manifiestan en todas las versiones desde PHP 5.4.

Ya han aparecido en la red prototipos de exploits (1, 2) para comprobar la vulnerabilidad de los sistemas. En la nota del exploit se afirma que las vulnerabilidades son causadas por el acceso a memoria ya liberada en el manejador de seguimiento del progreso de carga de archivos en servidor (session.upload_progress). No se requiere que el sitio tenga funcionalidad para cargar archivos para llevar a cabo un ataque, basta con que se active automáticamente en el intérprete PHP el manejador de contenido «multipart/form-data». Para una explotación exitosa se requiere determinar el diseño de las estructuras en la memoria del proceso, que es específica en cada compilación (el problema se soluciona mediante la búsqueda en el exploit de desplazamientos pre-calculados para paquetes de diferentes distribuciones).

Como medida de mitigación, se recomienda establecer en php.ini el parámetro «session.upload_progress.enabled = off» (o «php_admin_flag[session.upload_progress.enabled] = off» en PHP-FPM), pero un representante del proyecto PHP, así como el autor del primer prototipo del exploit, afirman que esto no es suficiente para bloquear ambas vulnerabilidades. En la nota del segundo prototipo del exploit se menciona que, además de la configuración anterior en php.ini, para prevenir el ataque sin aplicar un parche se requiere bloquear completamente las solicitudes con el tipo de contenido «multipart/form-data», lo que resultará en la imposibilidad de cargar archivos a través de formularios web.

En Apache httpd, se puede usar la siguiente regla en mod_rewrite para bloquear las solicitudes multipartes:

RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ — [F,L]

Para bloquear en nginx:

if ($http_content_type ~* "multipart") {
return 403;
}

Para bloquear en Caddy:

@multipart header_regexp Content-Type (?i)multipart
respond @multipart 403

Adición: Se han publicado las versiones correctivas de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, así como detalles sobre las vulnerabilidades críticas corregidas. El análisis de las vulnerabilidades y los métodos de mitigación recomendados oficialmente se ha publicado en una noticia separada.

Fuente: opennet.ru

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster