Gradle : trois avis disent high, le correctif 9.1 n'est pas le même

L'atelier a trois cadenas sur la même porte, et les trois cartes disent high. Le 7 octobre 2026, les trois. L'en-tête « versions corrigées », sur les trois cartes, tient en deux numéros : 8.14.6 et 9.8.1. Le tableau en dessous est plus long, et la ligne 9.1 n'y est pas coupée pareil. L'une dit 9.1.2. Les deux autres disent 9.1.1. Le bon de travail de la 9.8.1 nomme les trois cadenas. Le bon de la 8.14.6, daté du lendemain, parle de Java 24, de GraalVM, de rapports de tests, et il réimprime douze noms déjà présents sur un bon d'avril 2025. Si tu changes la serrure parce qu'un carton dit high, dis quel cadenas, et quel 9.1.

Les trois avis sont publiés par ljacomet. Le paquet est org.gradle:gradle-core. Les versions touchées, sur les trois, s'écrivent < 8.14.6, 9.0.0 to 9.8.0. L'en-tête Patched versions, sur les trois, dit 8.14.6, 9.8.1. Le tableau, lui, a dix lignes. Huit portent Gradle Security Subscription. Deux portent OSS : 9.8.1 et 8.14.6. 7.6.7 est dans les trois tableaux, en abonnement. Il n'est pas dans l'en-tête Patched versions.

Le 9.1.2 n'est que sur la carte du client

GHSA-xwqc-3h47-hg64. Désérialisation d'objets Java non fiables avant l'authentification, sur le canal client vers démon. Le client, gradle, gradlew, ou un IDE via la Tooling API, parle à un démon qui vit longtemps, sur une boucle locale. Le démon authentifie avec un jeton secret, mais il désérialise le message avant de vérifier le jeton. Un attaquant qui peut poser des octets sur ce canal peut mener à une exécution dans la JVM du démon, ou à un déni de service. L'avis dit qu'une preuve de concept a été montrée, et qu'il ne la publie pas. Les machines partagées sont les plus exposées. Il faut qu'un démon tourne. Il n'a pas besoin d'être en train de construire. Ce n'est pas exploitable depuis une connexion réseau distante.

Le vecteur, lu dans le HTML : CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Le mot affiché est High. Dans le rendu que j'ai lu, il n'y avait pas de numéral devant « / 10 ». Je n'en calcule pas un à partir du vecteur. La ligne d'abonnement 9.1 de cette table est 9.1.2. Les autres lignes d'abonnement que j'ai lues : 9.7.2, 9.6.2, 9.5.2, 9.4.2, 9.3.2, 9.2.2, puis 8.14.6 en OSS, puis 7.6.7.

La ligne de journal donnée en exemple a des ports vides : from /127.0.0.1: to /127.0.0.1:. L'exemple d'horodatage est 2026-01-01T12:00:00.000+0000. Ce n'est pas un événement que je date de janvier. C'est le format imprimé. La phrase importante est sur l'avis : l'absence d'une ligne de journal ne permet pas de conclure qu'aucune attaque n'a eu lieu. La présence d'une ligne n'est pas une confirmation non plus.

Le worker demande une course, le SSL part du réseau

GHSA-mvvg-497x-hmj8. Le canal worker vers démon n'authentifie pas le pair. La connexion est acceptée au premier arrivé, pendant une courte fenêtre au démarrage d'un worker. Java serialization sert de repli. L'avis dit qu'il faut une construction en cours, et qu'il faut gagner la course. Lui non plus n'est pas exploitable depuis le réseau distant. Le vecteur : CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Le rendu affiche 7.3, et High. La ligne 9.1 de cette table est 9.1.1. Pas 9.1.2. Le reste des numéros que j'ai lus aligne 9.8.1, 9.7.2 jusqu'à 9.2.2, 8.14.6 et 7.6.7. La même phrase sur l'absence de journal y est. Le texte de journal, lui, est un ConnectException, pas la phrase « Unable to receive command » du client.

GHSA-j5m7-59rp-24f5. Le titre est celui que la note 9.8.1 recopie : ne pas désactiver un dépôt qui échoue à établir une connexion SSL peut exposer la construction à des artefacts malveillants. SSLException et SSLHandshakeException ne sont traitées ni comme fatales ni comme transitoires. Gradle continue vers le dépôt suivant. L'attaque demande de pouvoir couper un dépôt et d'en contrôler un autre, plus loin dans la liste. Le vecteur : CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:H/SA:N. Le rendu affiche 8.6, et High. AV:N, réseau. Les deux avis d'avant disaient que ce n'est pas exploitable à distance. Celui-ci commence par le réseau. La ligne 9.1 est encore 9.1.1. Le contournement n'est pas « ne partage pas la machine ». C'est le filtrage strict du contenu des dépôts, et la vérification des dépendances.

Les trois pages ont un en-tête CVE ID. Je n'ai trouvé aucune chaîne CVE- dans le HTML des trois, lu le 23 octobre. Je ne leur invente pas de numéro.

Le bon du 7 nomme les trois, le bon du 8 nomme Java 24

La note 9.8.1 est publiée le 2026-10-07T21:46:19Z, par bot-gradle. C'est un correctif de 9.8.0. Elle dit qu'elle traite three high rated vulnerabilities, puis les trois titres, dans cet ordre : le worker, le client, le SSL. Elle ne dit pas local, ni réseau, ni 9.1.1, ni 9.1.2. Dessous, trois problèmes résolus qui ne sont pas ces avis. Le premier lien est imprimé cassé : un crochet, un tiret, une espace, une parenthèse, puis l'URL de l'issue 39358, sur des toolchains invalides avec les paquets Debian et Ubuntu. Je ne répare pas la ponctuation. Les deux autres lignes : des handlers java.util.logging retirés, ce qui casse la capture de journaux de tests Quarkus, et une régression de résolution de dépendances. La commande de wrapper imprimée est ./gradlew :wrapper, avec un deux-points avant wrapper.

La note 8.14.6 est publiée le 2026-10-08T10:53:12Z. Le lendemain. Elle dit que l'équipe est excited to announce Gradle 8.14.6. Les quatre puces : Java 24 support, GraalVM Native Image toolchain selection, Enhancements to test reporting, Build Authoring improvements. Les trois titres d'avis n'y sont pas. Le mot high n'y est pas. Les douze noms remerciés : Aurimas, Ben Bader, Björn Kautler, chandre92, Daniel Hammer, Danish Nawab, Florian Dreier, Ivy Chen, Jendrik Johannes, jimmy1995-gu, Madalin Valceleanu, Na Minhyeok. La note 8.14.0, publiée le 2025-04-25T10:13:56Z, imprime ces douze noms, dans cet ordre, et elle ne contient pas les quatre puces. Sa commande de wrapper est ./gradlew wrapper, sans le deux-points. Celle de 8.14.6 a le deux-points, comme la 9.8.1. L'avis dit que 8.14.6 est le correctif OSS. La note GitHub de 8.14.6 ne le dit pas. Je ne conclus pas que le binaire n'a pas le correctif. Je conclus que le bon que j'ai lu ne le nomme pas.

✍️ À toi : la carte que tu as ouverte, client, worker ou SSL, et le 9.1 qui y est imprimé. 9.1.2 n'est que sur la première. Le bon du 8 octobre, lui, ne parle pas de cadenas.

Le 7 octobre, Gradle publie trois avis high. Les en-têtes corrigés disent 8.14.6 et 9.8.1. Les tables ajoutent des abonnements, dont 7.6.7, et le 9.1 y vaut 9.1.2 sur le client, 9.1.1 sur le worker et sur le SSL. Le client n'a pas besoin d'une construction en cours. Le worker demande une course. Le SSL part du réseau et affiche 8.6, le worker 7.3, et le rendu du client que j'ai lu n'avait pas de numéral. La note 9.8.1, le même jour, liste les trois titres et un lien cassé. La note 8.14.6, le 8, liste Java 24 et les douze noms de la note 8.14.0 d'avril 2025. Trois cadenas. Deux bons. Un chiffre qui ne tombe pas sur la même dent.