Mise à jour nginx 1.31.2 corrigeant des vulnérabilités exploitées via HTTP/3, HTTP2 et gRPC

La version principale de nginx 1.31.2 a été lancée, poursuivant le développement de nouvelles fonctionnalités, ainsi que la publication d'une branche stable concurrente, nginx 1.30.3, qui ne reçoit que des modifications pour corriger des erreurs critiques et des vulnérabilités. Trois vulnérabilités ont été corrigées dans les mises à jour :

• CVE-2026-42530 — accès à une mémoire déjà libérée (use-after-free) dans l'implémentation du protocole HTTP/3. Cet incident a été classé avec un niveau de gravité critique (9.2 sur 10), permettant une exécution de code à distance avec les droits du processus lors du traitement d'une session spécialement conçue utilisant le protocole QUIC.
• CVE-2026-42055 — débordement de tampon dans les modules ngx_http_proxy_v2_module et ngx_http_grpc_module, se manifestant lors du proxy des requêtes spécialement formatées via le protocole HTTP/2 ou vers le backend gRPC. Cet incident a également reçu un niveau de gravité critique (9.2 sur 10), permettant l'exécution de code à distance. La vulnérabilité se trouve dans des configurations avec le réglage
  «ignore_invalid_headers off;» et une valeur élevée pour «large_client_header_buffers».
• CVE-2026-48142 — lecture en dehors de la mémoire allouée lors du traitement de requêtes spécialement formatées, entraînant le réencodage du texte en UTF-8 via le module ngx_http_charset_module. La vulnérabilité apparaît dans les configurations avec la directive «charset_map» lorsqu'il existe des directives «source_charset utf-8» et «charset autre_encoding» dans le bloc location. Cette vulnérabilité a été classée avec un niveau de gravité moyen (6.3 sur 10), permettant une fuite du contenu de la mémoire du processus.

En plus de corriger les vulnérabilités dans la version nginx 1.31.2, une variable $ssl_sigalgs a été ajoutée, contenant les algorithmes de signature numérique annoncés par le client dans le message ClientHello lors de la négociation de la connexion TLS. Un algorithme de hachage SipHash-2-4 a été utilisé pour générer l'identifiant transmis via la variable $request_id.

Source : opennet.ru