Go : quinze correctifs dans le même mail, et le guichet 1.26 n'a pas les mêmes colis

Le recommandé a deux numéros de suivi sur la même étiquette. Tu tends la main vers le guichet, et on te demande lequel. Dedans, quinze formulaires de sécurité sont agrafés une seule fois. Sous le rabat, le bon de livraison du site ne range pas les autres colis dans le même ordre. Si tu signes les deux numéros comme un seul paquet, tu prends les formulaires. Tu ne prends pas forcément le même reste.

Le 8 octobre 2026, un mail parti de announce@golang.org à 18 h 08 UTC annonce Go 1.27.2 et Go 1.26.9. Objet : une sortie de sécurité. Signature : Dmitri et Michael, pour l'équipe Go. Je le lis dans le relais du jour sur oss-security, pas dans un fil que j'aurais rouvert ailleurs. Le même jour, la page d'historique de go.dev date les deux révisions mineures du 8 octobre. Les deux documents parlent. Ils ne font pas la même liste.

Quinze formulaires, agrafés une fois

Le mail dit que ces sorties incluent 15 correctifs de sécurité, selon la politique du projet. Une liste, deux numéros. Je ne dédouble pas les CVE à la main.

Plusieurs formulaires ne parlent qu'à HTTP/2. Un client peut faire planter le serveur en changeant la taille de la table d'en-têtes pendant qu'une réponse encode un cadre HEADERS : l'encodeur HPACK est modifié par deux goroutines sans synchronisation. Le correctif ne change plus SETTINGS_HEADER_TABLE_SIZE tout de suite. Il le met de côté, et l'applique juste avant la prochaine écriture. C'est CVE-2026-97032. Le suivant, CVE-2026-78659, est un épuisement de mémoire par des en-têtes Trailer : chaque champ déclaré coûte une entrée dans Request.Trailer, et ça peut passer à côté de Server.MaxHeaderValueCount et Server.MaxHeaderBytes. Le mail est net : ça ne s'applique pas à HTTP/1, qui ne multiplexe pas autant de requêtes sur une connexion, et dont les octets d'en-tête se comptent autrement. Les deux sont signalés par RyotaK, de GMO Flatt Security.

Toujours en HTTP/2, un pair peut ouvrir beaucoup de flux puis envoyer de petits cadres SETTINGS qui changent SETTINGS_INITIAL_WINDOW_SIZE, et faire brûler du CPU. Le traitement passe d'un coût proportionnel au nombre de flux à un coût constant. CVE-2026-78669, Jakub Ciolek. Un autre remboursement de contrôle de flux pouvait être compté deux fois, au reset d'un flux puis à la lecture par le handler. Un client peut s'en servir pour dépasser MaxReceiveBufferPerConnection. Le mail ajoute que le total mis en tampon reste borné par la limite de flux concurrents et par le contrôle de flux du flux. Le remboursement attend maintenant la fin du handler. CVE-2026-78663, Ali Sherif. Et des en-têtes de cadrage malformés, sans effet sur le cadrage HTTP/2 lui-même, pouvaient être transmis à un client HTTP/1 quand le programme sert de reverse proxy. Le transport HTTP/2 les supprime à la réception. CVE-2026-78660, TJ Barton.

Deux formulaires ne s'ouvrent que si tu es déjà dans un mauvais couloir, et que tu as choisi d'y rester. Un projet Go malveillant qui définit un faux golang.org/fips140, plus un GOMODPROXY malveillant auquel tu choisis de te connecter, pouvait servir un module arbitraire à la place. Le correctif déballe le ziphash de confiance du module livré avec l'outil, et construit son entrée de cache pour que la chaîne d'outils puisse la vérifier. CVE-2026-94444. Le voisin, CVE-2026-94447, est un faux golang.org/toolchain dans un go.sum, avec le même genre de proxy choisi par toi. Cette fois, le module passe toujours par le réseau pour le checksum canonique. Les deux partent du même cas : tu es déjà dans un projet malveillant, et tu as choisi le proxy. Ce n'est pas un visiteur qui passe dans la rue.

Le reste de l'agrafe tient dans des phrases plus courtes. CVE-2026-97031 : plusieurs références d'extension externe ECH ne sont pas permises par le RFC 9849, et un paquet bien construit pouvait épuiser la mémoire du serveur. Elles sont maintenant refusées comme malformées. CVE-2026-94448 : dans un littéral de modèle JavaScript, des expressions consécutives ne remettaient pas le contexte à zéro, et l'échappement des expressions régulières suivantes pouvait rater. CVE-2026-97030 : le mot-clé yield n'était pas reconnu comme un mot qui précède une expression régulière, et un auteur de modèle de confiance pouvait avoir écrit un modèle valide mal échappé. Les deux sont dans html/template. CVE-2026-94440 : l'analyse d'un formulaire multipart pouvait lire une ligne arbitrairement longue quand la limite restante au début d'une partie était inférieure à 400 octets. Le titre du point nomme net/textproto et mime/multipart. Jakub Ciolek, encore.

Deux lignes qui ferment, et un interrupteur

Deux formulaires changent un geste, pas seulement un calcul. Côté client HTTP/1, http.Transport écrivait le corps d'un CONNECT, quand Request.Body n'est pas vide, directement sur la connexion après les en-têtes. Si le serveur refuse avec une réponse keep-alive qui n'est pas en 2xx, la connexion retournait dans le pool. Le serveur peut alors lire ces octets comme une requête suivante. Dans un reverse proxy qui partage un transport, le mail dit que ça peut empoisonner la réponse d'un autre utilisateur. Le transport ferme maintenant la connexion après un CONNECT, quel que soit le statut de la réponse. Et ReverseProxy refuse un CONNECT entrant par un 405. Le mail rappelle que ce proxy n'a jamais fait du CONNECT quelque chose d'utile : il ne transforme pas la connexion en tunnel dans les deux sens. Ils n'attendent pas que le 405 gêne les usages actuels. « N'attendent pas ». Je laisse la phrase à eux. CVE-2026-56866, signalé par Xclow3n (Rajat Raghav).

Côté serveur, un handler qui répondait 2xx à un CONNECT HTTP/1 sans prendre la connexion en main laissait le serveur continuer à y lire des requêtes. Un 2xx sur un CONNECT, c'est un tunnel. Le serveur ferme maintenant la connexion après toute réponse à un CONNECT, là aussi quel que soit le statut. L'impact décrit est surtout de la contrebande de requêtes, entre un proxy qui croit à un tunnel et un serveur qui croit encore à de l'HTTP. CVE-2026-94439, Jakub Ciolek.

Le dernier formulaire a un interrupteur. FileServer, ServeContent et ServeFile pouvaient brûler du CPU sur un en-tête Range fait de beaucoup de petites plages. Ils ignorent désormais un Range de plus de 200 plages. La limite se règle avec GODEBUG=httpservecontentmaxranges=…. La valeur 0 désactive la limite. CVE-2026-78667, encore Jakub Ciolek. Le correctif n'est pas une porte scellée. C'est une porte avec une clé de débogage, imprimée dans le mail.

Un formulaire ne parle qu'à Windows. Root.Mkdir et Root.MkdirAll pouvaient suivre une jonction qui pointe vers un endroit vide, et créer le répertoire dehors de la racine. Seulement quand le dernier composant du chemin est la jonction, pas quand la jonction est au milieu. Les deux fonctions évitent maintenant de résoudre ces jonctions. CVE-2026-56857, Daniele Ballarini.

Le bon de livraison n'est pas le même sous le rabat

La page d'historique, elle, résume. Pour 1.27.2 comme pour 1.26.9, les correctifs de sécurité nommés sont la commande go, crypto/tls, html/template, net/http, net/textproto et os. Même ligne de paquets. mime/multipart, qui est dans un titre du mail, n'est pas dans cette ligne. Je ne traduis pas l'absence du mot en absence du correctif. La page dit « voir le jalon ». Je ne l'ai pas ouvert.

Les correctifs qui ne sont pas de la sécurité, sur la même page, ne portent pas la même étiquette. 1.27.2 nomme le compilateur, l'éditeur de liens, le runtime, l'outil cover, la commande go fix, vet, et les paquets compress/flate, crypto/mlkem, encoding/json, encoding/json/v2, net/http et os. 1.26.9 nomme le compilateur, l'éditeur de liens, le runtime, vet, et crypto/mlkem, net/http et os. Cinq noms du premier ne sont pas dans la phrase du second : cover, go fix, compress/flate, encoding/json, encoding/json/v2. Je ne décris pas ce que ces colis contiennent. La page ne le dit pas. Elle dit qu'ils ne sont pas listés au même endroit.

Le mail, pour compiler depuis un clone Git, n'imprime qu'une commande : git checkout go1.27.2. La page d'historique, en haut, montre la forme générale, git checkout goX.Y.Z, après un git fetch --tags. Deux guichets. Le mail te tend le numéro le plus haut. Il a quand même annoncé l'autre dans la première phrase. Les binaires des deux sont sur go.dev/dl, le lien est dans le mail. Je ne fabrique pas la ligne de checkout de 1.26.9 comme si elle y était imprimée.

✍️ À toi : le go version que ta prod lance vraiment, et si c'est le toolchain du projet ou celui de l'image. Le mail a deux numéros. Ta machine n'en imprime qu'un.

Quinze formulaires, un mail, deux versions. Plusieurs ne parlent qu'à HTTP/2, deux ferment la connexion après un CONNECT, un a un GODEBUG qui remet l'ancienne limite à zéro, un ne sort pas de Windows. Le guichet 1.27 ajoute, sur le bon de livraison, des colis hors sécurité que le guichet 1.26 ne nomme pas. Signer l'étiquette ne dispense pas de lire lequel des deux tu emportes.