Sécurité

Mythos, GPT-6 Astra : la fin des failles tranquilles

Un bug de 27 ans dans OpenBSD, un autre de 16 ans dans FFmpeg, 23 019 problèmes trouvés en quelques semaines dans un millier de projets open source. Les modèles de frontière trouvent désormais des failles plus vite que quiconque ne peut les corriger, et deux éditeurs viennent de le reconnaître officiellement. Ce que Project Glasswing, GPT-5.6-Cyber et GPT-6 Astra disent vraiment, et ce qu'un serveur de PME doit en conclure dès lundi.

Dessin au trait fin : une longue fissure traverse un mur de briques et une loupe vient de se poser sur son extrémité, illustration de failles anciennes désormais trouvées par les modèles d'IADessin au trait fin : une longue fissure traverse un mur de briques et une loupe vient de se poser sur son extrémité, illustration de failles anciennes désormais trouvées par les modèles d'IA
Sommaire (5 sections)
  1. Project Glasswing : les chiffres
  2. Ce n'était pas un coup isolé
  3. Ce que ça veut dire pour un serveur de PME, dès lundi
  4. Et ces modèles, côté défense ?
  5. Sources

Il y a une hypothèse silencieuse derrière la sécurité de la plupart des serveurs : les failles qui n'ont pas été trouvées en vingt ans ne le seront pas demain. Cette hypothèse est morte le 7 avril 2026. Ce jour-là, Anthropic a annoncé qu'un modèle placé dans un bac à sable avec des outils de développement ordinaires, sans entraînement spécialisé ni guidage humain, avait trouvé des milliers de vulnérabilités de haute gravité dans tous les grands systèmes d'exploitation et navigateurs. Cinq mois plus tard, OpenAI annonce un modèle qui franchit son seuil « critique ». Il est temps de regarder ce que ça veut dire pour une infrastructure de quarante machines.

Project Glasswing : les chiffres #

Project Glasswing réunit douze organisations (AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, Anthropic) autour de Claude Mythos Preview, un modèle dont l'éditeur dit qu'il « surpasse tous les humains sauf les plus qualifiés pour trouver et exploiter des vulnérabilités logicielles ». Les exemples publiés sont parlants : une faille de 27 ans dans OpenBSD, système réputé pour son durcissement ; une faille de 16 ans dans FFmpeg, passée à travers des millions de tests automatisés ; des chaînes de vulnérabilités dans le noyau Linux menant à l'escalade de privilèges ; une chaîne de quatre failles échappant aux bacs à sable d'un navigateur. Cent millions de dollars de crédits d'usage, et une décision rare : le modèle ne sera pas rendu public. Anecdote rapportée par The Hacker News : pendant les tests, le modèle s'est échappé d'un environnement sécurisé et a publié des détails d'exploit sur des sites publics, ce que l'éditeur qualifie de « capacité potentiellement dangereuse ».

Le bilan du 26 mai 2026 donne l'échelle : 23 019 problèmes identifiés dans plus de 1 000 projets open source, dont 6 202 de gravité haute ou critique ; sur 1 752 cas vérifiés par Anthropic et six sociétés indépendantes, plus de 90 % de vrais positifs. Des centaines de vulnérabilités chez Cloudflare et Mozilla, une bibliothèque cryptographique embarquée dans des milliards d'appareils. Et cette phrase, qui résume le problème : « la facilité relative à trouver des vulnérabilités, comparée à la difficulté de les corriger, constitue un défi majeur pour la cybersécurité ». Les mainteneurs open source, souvent bénévoles, reçoivent des rapports plus vite qu'ils ne peuvent les traiter.

Comparaison des délais entre publication d'une faille et exploitation : des semaines hier, douze heures pour Citrix en août 2025, moins de dix minutes pour écrire un exploit ; puis la chaîne découverte, divulgation, exploit, votre serveur, avec les leviers veille, correctif, surface minimale et détection
La fenêtre s'est refermée en amont. Ce qui reste à un hébergeur, c'est la vitesse de réaction et la surface exposée.

Ce n'était pas un coup isolé #

  • Juillet 2025, Big Sleep. L'agent de Google trouve dans SQLite CVE-2025-6965, une corruption mémoire que des attaquants s'apprêtaient à exploiter : première fois qu'une IA déjoue une exploitation en préparation. Vingt failles supplémentaires dans des projets open source le mois suivant.
  • Août 2025, DARPA AIxCC. En finale à DEF CON, sept systèmes autonomes trouvent 54 des 70 failles injectées dans des logiciels réels, en corrigent 61 %, avec un correctif moyen en 45 minutes, et découvrent en passant 18 vulnérabilités réelles inconnues. L'équipe gagnante remporte 4 millions de dollars.
  • Juin 2025, XBOW. Un testeur d'intrusion autonome devient numéro un du classement américain de HackerOne, devant des milliers de chercheurs humains, avec plus d'un millier de rapports en quelques mois.
  • Août 2026, GPT-5.6-Cyber. OpenAI publie via son programme Daybreak Red un modèle spécialisé qui réussit 95 % des tâches de développement de chaînes d'exploit, d'escalade de privilèges et de contournement d'authentification, contre 1,5 % pour le modèle grand public de la même génération. Il a trouvé une faille de haute gravité dans le moteur JavaScript de Chrome.
  • 3 septembre 2026, GPT-6 Astra. Premier modèle à franchir le seuil « critique » du cadre de préparation d'OpenAI : selon l'éditeur, il peut « trouver des failles inconnues et développer des moyens de les exploiter sur de nombreux systèmes bien protégés sans qu'une personne guide chaque étape ». Accès prioritaire aux défenseurs du programme Daybreak, surveillance renforcée, et cette phrase du président d'OpenAI : « bienvenue dans l'ère de l'AGI ».

Ce que ça veut dire pour un serveur de PME, dès lundi #

Un site sous WordPress, une passerelle VPN, un serveur de fichiers, un CRM auto-hébergé : votre pile logicielle est un sous-ensemble de ce que ces modèles passent au crible. Les failles qu'ils trouvent aujourd'hui dans FFmpeg, dans le noyau, dans les bibliothèques TLS, sont dans vos machines aussi. Les correctifs suivront, en flux continu. La seule question qui compte est : combien de temps s'écoule entre la publication d'un correctif et son application chez vous ? Notre doctrine tient en quatre briques, toutes documentées sur ce blog.

  1. Savoir en heures. Un inventaire vivant des versions sur chaque machine (PatchMon) et un scan quotidien des images de conteneurs (Trivy) : quand une CVE tombe, nous savons le jour même quelles machines sont concernées, sans chercher.
  2. Corriger en jours, en regardant. Pas d'automatisation aveugle, qui casse la nuit et échoue en silence, mais un run décidé, avec instantané avant et vérification après. Sur les failles critiques exposées, le jour même.
  3. Exposer le moins possible. Une faille dans un service qui n'est pas joignable depuis Internet n'est pas une urgence. Cloisonnement, pare-feu réellement actif, bastion unique pour l'administration, ports fermés par défaut.
  4. Détecter si ça a quand même eu lieu. Parce qu'une fenêtre de douze heures existera toujours. Journaux centralisés, alertes sur les clés SSH et les connexions inhabituelles : c'est le rôle du SIEM que nous décrivons le 21 septembre.

Et ces modèles, côté défense ? #

La version grand public de Claude peut désormais « découvrir des vulnérabilités logicielles, mais pas développer des exploits ». Nous nous en servons pour relire nos configurations et notre code avant qu'un autre ne le fasse, avec des garde-fous stricts : compte dédié, moindre privilège, sessions enregistrées, et aucune action en production sans validation humaine. Les grands éditeurs font pareil à leur échelle : c'est tout le sens de Glasswing. L'asymétrie ne joue pas contre les petits, à une condition : ne pas attendre. Le modèle qui trouvera la prochaine faille de votre CMS existe déjà ; la seule question est de savoir qui l'aura utilisé le premier.

Inventaire, veille, correctif décidé, surface minimale, détection : ce n'est pas une offre premium, c'est le minimum que nous jugeons défendable en 2026, et c'est ce que contient notre infogérance. Si vous ne savez pas aujourd'hui combien de vos serveurs tournent une version vulnérable de quelque chose, parlons-en avant que quelqu'un d'autre ne le sache pour vous.

Sources #

À propos
01/À lire ensuiteTrois articles

Articles liés

Sécurité

Un verrou périmé, c'est un scan qui ment

Les fichiers de verrouillage de dépendances sont la source de vérité des analyses de sécurité. Quand une chaîne d'intégration les réécrit en silence au lieu d'échouer, l'analyse lit de fausses versions et rend un verdict rassurant. Comment on l'a découvert, et ce qu'on a changé.

dépendanceschaîne logicielle
Sécurité

446 vulnérabilités, puis zéro : ce que change un inventaire qui dit vrai

Chaque machine scannait ses propres images, personne ne voyait le parc. En centralisant l'analyse sur l'inventaire réel — 111 images uniques au lieu de 25 bases locales —, le compteur est passé de 446 à 0 dans la soirée. Récit d'un chantier de mesure, pas de correction.

vulnérabilitésconteneurs
Sécurité

Intégrer un SIEM sur un parc de 38 machines : Wazuh, du dimensionnement au calibrage

Un journal qui reste sur la machine compromise ne vaut rien. Nous avons déployé Wazuh sur l'ensemble du parc en deux jours : VM dédiée, rétention de douze mois, 38 agents en trois vagues, et surtout un calibrage qui fait passer le bruit de 1 250 alertes par machine à 8 pour tout le parc. Les pièges de l'installeur, de la conformité en conteneur, et les détections maison qui comptent vraiment.

wazuhsiem

Et maintenant

Détecter avant que ça coûte ?

Journaux centralisés, alertes, correctifs décidés, sauvegardes restaurées pour de vrai. Premier échange gratuit.

Discuter de votre projet

Réponse sous 24 h ouvrées, par l'un des deux fondateurs. Ou par téléphone : 07 59 96 14 99.