Les chaînes d’exploits d’Anthropic : le problème n’est pas le modèle, mais le retard des correctifs

Est-il effrayant qu’une IA puisse écrire un exploit fonctionnel pour Chrome, Safari et Linux ? Moins que la question banale qui se cache derrière: quand le prochain sera trouvé, qui l’aura entre les mains avant la sortie du correctif ?

Voici ce qui s’est passé. Le 27 octobre, la Frontier Red Team d’Anthropic a publié un article de recherche expliquant qu’au cours des derniers mois, un modèle de recherche interne non publié avait découvert des vulnérabilités critiques dans des navigateurs et des systèmes d’exploitation. Selon The Hacker News, le modèle a enchaîné des failles pour produire des exploits de preuve de concept fonctionnels contre Chrome, Safari, Android, Windows et Linux. Ces exploits ont été construits en laboratoire après sollicitation, n’ont pas été observés dans des attaques réelles, et chaque faille a d’abord été signalée à l’éditeur concerné: toutes sont donc déjà corrigées.

Un cas illustre bien la réalité du phénomène. Le bogue Linux, CVE-2026-98432, est un use-after-free dans la poignée de main TCP qui existe depuis Linux 4.4. Frandroid rapporte qu’après une première instruction d’un chercheur, le modèle a écrit un exploit root à distance: 48 minutes pour faire fuiter une adresse du noyau, cinq de plus pour prendre le contrôle.

La compétence fait la une, mais ce n’est pas le sujet

Que des modèles trouvent des bogues n’étonne plus. Ce qui change, c’est l’économie. Une faille présente dans le noyau Linux depuis 2016 a reçu un exploit root à distance fonctionnel en moins d’une heure de temps de calcul du modèle. Nous pensons que la ressource rare côté attaque était autrefois le temps d’humains qualifiés, et que cette rareté s’érode.

La divulgation d’Anthropic témoigne aussi d’une retenue qui mérite d’être saluée. L’entreprise n’a pas publié son exploit, a signalé les failles aux éditeurs d’abord, et affirme travailler avec des sociétés de sécurité extérieures pour trier et valider les découvertes. Frandroid note qu’aucune reproduction indépendante n’avait été signalée au 30 octobre. Pourtant, environ quarante dépôts GitHub mentionnent déjà la faille, dont au moins sept se présentent comme des preuves de concept. La retenue d’un laboratoire n’empêche pas les autres de fabriquer leur propre exploit à la main ou avec leurs propres outils.

Le correctif n’est pas la ligne d’arrivée

Tout le monde aime la formule selon laquelle tout est déjà corrigé. Nous serions prudents. Le correctif Linux tenait en quatre lignes, rédigées le 5 octobre et intégrées aux noyaux stables les 11 et 15 octobre. Pourtant, le matin du 2 novembre, selon Frandroid, Ubuntu indiquait encore son correctif comme « en cours » pour les versions 22.04 à 26.10, alors que des paquets corrigés étaient déjà référencés sur sa page de suivi. Red Hat n’a commencé à diffuser ses correctifs que le 1er novembre et a relevé la gravité à critique le 30 octobre, après que lui-même et d’autres éditeurs avaient d’abord noté le bogue entre 5,9 et 8,1.

Voilà le véritable écart. Écrire l’exploit a pris moins d’une heure à un modèle, tandis que le tri, la notation de gravité, l’empaquetage et le redémarrage de votre serveur avancent toujours à vitesse humaine et administrative. Red Hat a averti que les entreprises asiatiques devaient corriger plus vite face aux menaces liées à l’IA. Nous l’étendrions à tout le monde. Si un modèle peut comprimer l’exploitation, la défense qui compte consiste à comprimer la correction et le déploiement.

Qui l’obtient en premier décide de tout

Anthropic n’a pas publié ce modèle, ce qui est rassurant et, nous le soupçonnons, temporaire. La question est de savoir si les défenseurs obtiendront des outils équivalents avant les attaquants. Nous penchons ici pour un optimisme prudent: un laboratoire qui signale les failles aux éditeurs avant de publier rend service aux défenseurs. Mais cela ne fonctionne que si les éditeurs peuvent absorber le volume. Un déluge de rapports critiques bien validés peut submerger une petite équipe de mainteneurs aussi sûrement qu’une attaque.

Il y a aussi un volet politique à observer d’un œil sceptique. Radio France note que des laboratoires de modèles fermés comme Anthropic ont appelé à une réglementation, ce qui pourrait favoriser leur modèle économique par rapport aux modèles ouverts. À notre avis, la capacité offensive est un argument commode pour ce programme. Il peut être sincère et rester intéressé.

Que faire lundi

Notre recommandation est pratique, pas apocalyptique. Considérez « correctif disponible » comme un déclencheur d’urgence, pas comme un ticket pour le prochain trimestre. Si vous gérez des serveurs Linux, vérifiez l’état réel de votre noyau, y compris les variantes cloud et HWE, et redémarrez après la mise à jour; les conteneurs partagent le noyau de l’hôte. Là où aucun correctif n’est encore disponible, les mesures d’atténuation citées par Frandroid (filtrer les paquets TCP avec options IPv4, désactiver MPTCP) réduisent l’exposition, même si Red Hat affirme que seul un noyau corrigé règle le problème.

Le verdict: ne paniquez pas à cause du modèle, inquiétez-vous doucement de votre cadence de mises à jour. Le prochain bogue critique arrivera probablement plus vite que le dernier, et les gagnants seront ceux qui raccourciront le délai entre l’existence d’un correctif et son déploiement effectif.