Deux semaines de retard pour l’IA de Z.ai, qui a déterré 2 436 failles dont une de 1981

Décryptage

Combien de temps une faille peut-elle dormir dans un logiciel avant que quelqu’un la voie ? Quarante-cinq ans, répond le laboratoire chinois Z.ai, qui a mis en ligne le 28 août 2026 les poids de son modèle GLM-5.3 après lui avoir fait ratisser des centaines de projets open source et daté sa plus vieille trouvaille de 1981.

Le modèle avait été annoncé le 14 août. Z.ai avait alors prévenu qu’il garderait les poids deux semaines de plus, le temps de terminer « safety evaluation and hardening ». Un éditeur qui se revendique ouvert a donc retardé son propre produit, parce que ce produit s’était révélé très bon à trouver des trous.

Ce que le modèle a trouvé, et comment le compte a été fait

Le chiffre n’est pas la sortie brute d’un scanner. Depuis GLM-5.2, Z.ai dit travailler avec plusieurs équipes de sécurité en Chine pour lancer ses modèles sur du code réel, puis passer les résultats au tamis : revue par des experts, tri, déduplication. Ce qui en ressort est donc un inventaire de vulnérabilités comptées une seule fois, réparties sur 269 projets.

Les projets concernés ne sont pas des curiosités de laboratoire. Z.ai cite dans son billet technique des noyaux système, des systèmes d’exploitation, des moteurs de navigateurs, des infrastructures open source, des applications web et des protocoles réseau. C’est la couche sur laquelle tournent un téléphone, une box et un accès bancaire.

Le modèle GLM-5.3 du laboratoire chinois Z.ai a identifié 2 436 vulnérabilités dans 269 projets open source, quand le CERT-FR a publié 1 095 avis de sécurité entre le 1er janvier et le 28 août 2026. Selon nos calculs, le premier compte pèse 2,2 fois le second, par simple division des deux compteurs. La réserve va de soi : un avis du CERT-FR peut couvrir plusieurs failles à la fois, l’ordre de grandeur vaut mieux que l’égalité.

1981, 1987, 2006 : la dette logicielle a des dates

Z.ai publie une frise des années d’introduction, et elle ne couvre pas tout : 244 trouvailles seulement y portent une date de naissance. C’est un sous-ensemble, et il est déjà parlant, puisque 88 d’entre elles (36 %) ont été écrites avant 1990.

Trois millésimes dominent le début de la frise : 1987 avec 47 failles, 1982 avec 21 et 1981 avec 20. Le milieu des années 2000 fournit le second pic, avec 39 failles introduites en 2006 et 26 en 2003. La décennie 2010 en apporte 28 au total, et les sept premières années de la décennie 2020, dix-neuf.

La lecture tient en une ligne : quatre failles datées sur cinq viennent de code écrit avant 2010. Le billet de Z.ai le formule autrement, en une phrase que le laboratoire assume : « the oldest flaw was introduced in 1981, and on average a vulnerability lived 26.6 years before discovery ». La faille moyenne du lot a donc été écrite autour de 1999, puis relue, compilée et redéployée pendant un quart de siècle sans que personne la remarque.

53 failles publiées, 2 383 sous embargo

97,8 % des trouvailles ne sont pas publiques. Z.ai a monté un registre de divulgation qui sépare ce qui est sorti de ce qui est encore en cours, et qui note, pour chaque dossier publié, le projet touché, la gravité, le numéro CVE quand il existe et le temps que la faille a passé dans le code.

Un détail mérite d’être redressé. Le billet parle de 1 097 failles « de gravité moyenne à élevée », mais son propre tableau range ces 1 097 en critiques et élevées : 107 plus 990. C’est la seconde lecture qui tient, et elle est plus sévère que la première.

La moitié du lot est donc de gravité moyenne, ce qui n’est pas rien : ce sont les dossiers qui traînent le plus longtemps avant correction, parce qu’aucune urgence ne les pousse.

« Poids ouverts » : l’éditeur ne garde que le calendrier

Une fois les poids en ligne, ils se copient. La fiche du modèle sur Hugging Face annonce 753 milliards de paramètres, une licence maison nommée « glm-5.3 » et des tenseurs BF16 et FP8. C’est téléchargeable par n’importe qui, et rien ne se rétracte.

Ce que ce vocabulaire recouvre au juste mérite d’être posé, et nous avons détaillé les étiquettes de l’ouvert ailleurs. Retenir deux semaines des poids que l’on donne ensuite gratuitement n’est pas une demi-mesure absurde : c’est le seul moment où l’éditeur décide encore de quelque chose.

Les scores de capacité expliquent pourquoi la question s’est posée. Sur CyberGym, banc d’essai de découverte de vulnérabilités à partir du code source, GLM-5.3 obtient 84,5 % contre 77,2 % pour GLM-5.2. Sur ExploitBench, il passe de 24,4 % à 54,4 %, soit plus du double, tout en restant derrière deux modèles fermés mesurés à 78,0 % et 76,5 %.

La progression est donc la plus forte là où le laboratoire est le plus en retard. Le fil Hacker News ouvert le jour de la publication, 216 points et 71 commentaires, ne s’attarde presque pas sur ce point : on y compare des vitesses d’inférence et le prix du matériel nécessaire pour faire tourner le modèle chez soi.

Concrètement, pour un utilisateur en France

Il n’y a rien à installer. Les correctifs issus de ce travail arriveront par le canal habituel : mises à jour du système, du navigateur, de la box, des serveurs chez les hébergeurs. Le seul geste utile reste de ne pas les repousser de semaine en semaine.

L’échelle française se lit chez l’ANSSI. Le CERT-FR en était à son 1 095e avis de sécurité de l’année le 28 août 2026, jour de la mise en ligne des poids, soit un rythme moyen d’environ 4,6 avis de sécurité par jour depuis le 1er janvier.

Reste la dissymétrie que personne ne résout : le même modèle sert à chercher les failles et à s’en servir. Z.ai a choisi de publier quand même, et de tenir un registre plutôt qu’une annonce. Le laboratoire indique que ce registre est mis à jour en continu, à mesure que les dossiers sont revus et divulgués.

Article créé en collaboration avec l’IA.