948 failles root dans Linux, un ingénieur sécurité IA à la demande : ce que ces annonces changent pour votre conformité RGPD

Le 4 novembre 2026, OpenAI a publié les résultats d’une campagne menée sur le noyau Linux par un modèle de cybersécurité qu’elle n’a pas encore rendu public. La campagne a produit 948 vulnérabilités distinctes qui permettent à un utilisateur ordinaire de prendre le contrôle complet d’une machine, pour environ 1,2 million de dollars de crédits API. Dans le même temps, la start-up américaine OpenHack lance un agent qui se présente comme un « ingénieur sécurité IA toujours disponible » et offre des analyses gratuites avec Claude Mythos jusqu’au 11 novembre.

Les deux nouvelles racontent la même chose. Trouver une faille, vérifier qu’elle s’exploite et écrire le correctif coûte désormais quelques centaines ou milliers de dollars. Les défenseurs en profitent. Les attaquants bien financés aussi. Pour un responsable de traitement, cela pèse directement sur ce que l’on peut attendre de lui au titre de l’article 32 du RGPD.

Ce qu’OpenAI a réellement publié

L’équipe Cyber d’OpenAI a fait tourner son pipeline à la mi-octobre, pendant une trentaine d’heures, contre la dernière version du noyau. Des agents de reconnaissance ont d’abord sélectionné un peu plus de 5 000 zones de code accessibles à un utilisateur sans privilège, soit environ 2,8 millions de lignes et 7 % du noyau. D’autres agents ont ensuite cherché des failles, tenté de les reproduire, écrit un exploit puis un correctif pour chacune.

Les machines cibles tournaient sous une distribution de bureau courante, avec les protections habituelles activées (SMEP, SMAP, KASLR). Les exploits ont fonctionné malgré elles.

Pour situer l’ordre de grandeur, les concours Pwn2Own et TyphoonPWN payaient jusqu’ici entre 20 000 et 70 000 dollars un seul exploit de ce type. En juillet, le modèle précédent d’OpenAI avait trouvé 166 failles de ce genre pour un peu plus de 500 000 dollars. Trois mois plus tard, le rendement a été multiplié par plus de cinq.

Deux réserves s’imposent. Ces chiffres viennent d’OpenAI et aucun tiers ne les a encore reproduits. Le modèle n’est pas accessible au public. OpenAI indique avoir déjà transmis des centaines de rapports accompagnés de correctifs aux mainteneurs du noyau, en commençant par les failles les plus graves comme la communauté le lui a demandé. Une partie des correctifs est donc en cours de diffusion, et chaque distribution les intègre à son rythme.

Un compte utilisateur banal devient une porte vers tout le système

Une élévation locale de privilèges suppose que l’attaquant dispose déjà d’un accès, même minime, à la machine. Dans la vraie vie, cet accès s’obtient facilement : un identifiant volé par hameçonnage, le compte d’un prestataire de maintenance, un compte partagé sur un poste d’accueil, une application web compromise qui donne un shell sous un utilisateur technique. Jusqu’ici, ce premier pied posé ne suffisait pas toujours pour lire toute la base de données.

Sur un système Linux qui n’a pas reçu les correctifs, la distance entre « un compte compromis » et « root » se réduit fortement. Avec les droits root, l’attaquant lit tous les fichiers, copie les bases, efface les journaux et rebondit vers d’autres serveurs. Pour un service de santé au travail, un établissement de santé, une collectivité ou un CSE qui héberge des données personnelles sur des serveurs Linux, la protection des dossiers repose alors en grande partie sur la fraîcheur du noyau.

Linux ne se limite pas aux serveurs que votre DSI connaît. On le trouve dans les NAS de sauvegarde, les pare-feu, les boîtiers fournis par les prestataires, les serveurs de l’hébergeur de votre logiciel métier. Une organisation qui pense « nous sommes sous Windows » a presque toujours du Linux quelque part dans sa chaîne de traitement.

OpenHack, l’agent qui cherche, prouve et corrige

OpenHack décrit son produit comme un ingénieur sécurité qui travaille en continu. L’agent analyse le code source, mène des tests d’intrusion sur les applications en production, construit une preuve d’exploitation dans un environnement isolé avant de signaler une faille, puis prépare une proposition de correctif à valider par les développeurs. La société met en avant sa capacité à repérer des failles de logique métier, des contournements d’authentification, des secrets exposés ou des dépendances piégées.

Le point le plus intéressant pour un organisme qui manque de temps concerne la priorisation. OpenHack classe les résultats selon leur impact réel sur l’activité (exposition sur internet, flux de paiement, actif de production) plutôt que selon le seul score CVSS. Un identifiant de test oublié dans un fichier inaccessible depuis la production descend en bas de liste. Un contrôle d’accès cassé sur des factures clients remonte en tête.

L’outil existe en deux versions : une interface en ligne de commande open source, utilisable avec le modèle d’IA de son choix, et une plateforme gérée qui ajoute l’analyse continue des dépôts et les propositions de correctifs. Pour fêter son lancement, OpenHack propose aux entreprises clientes une analyse gratuite avec Claude Mythos, le modèle d’Anthropic réservé à la cybersécurité, jusqu’au 11 novembre. Attention à l’homonymie : un projet open source du même nom, publié en mai 2026 par la société néerlandaise Hadrian, n’a rien à voir avec cette start-up.

Lecture RGPD de ces deux annonces

L’article 32 se lit à la lumière de l’état de l’art

L’article 32 impose des mesures de sécurité adaptées au risque, en tenant compte de l’état des connaissances et du coût de mise en œuvre. Quand un exploit root sur Linux coûte un peu plus de 1 000 dollars à produire, le risque change de nature. Après une violation de données, expliquer à la CNIL qu’un correctif de sécurité attendait depuis trois mois deviendra de plus en plus difficile. La gestion des mises à jour reste l’une des recommandations de base du guide de la sécurité des données de la CNIL ; elle prend aujourd’hui un poids supplémentaire.

Confier son code et sa production à un agent IA

Un agent comme OpenHack lit votre code, vos fichiers de configuration, parfois vos jeux de test, et attaque vos applications en production. Le code peut contenir des secrets ou des données personnelles oubliées dans des fichiers d’exemple. Un test d’intrusion en production touche des données réelles. Le prestataire agit donc comme sous-traitant au sens de l’article 28, avec un contrat, une liste de sous-traitants ultérieurs (le fournisseur du modèle d’IA en fait partie) et des garanties sur la localisation des traitements.

OpenHack, Inc. est une société américaine. Elle affirme que le code et les résultats restent stockés localement et que l’inférence se fait dans la région du client. Ces engagements doivent figurer dans le contrat, avec l’outil de transfert retenu si des données quittent l’Union européenne. Une offre gratuite limitée dans le temps pousse à brûler les étapes. Pour une application qui traite des données de santé, l’autorisation écrite du test, son périmètre, sa fenêtre et sa journalisation passent avant la date du 11 novembre. Selon le contexte, une analyse d’impact peut s’imposer.

Vulnérabilité, violation et éditeurs de logiciels

Une faille non corrigée ne constitue pas en soi une violation de données. Elle se documente et se traite. Si des traces montrent qu’elle a été exploitée et que des données ont pu être lues, copiées ou altérées, le délai de 72 heures de l’article 33 commence à courir. Avec des données de santé, l’information des personnes concernées au titre de l’article 34 devient probable. Les éditeurs de logiciels sont aussi tenus, depuis le 11 septembre 2026 et au titre du Cyber Resilience Act, de signaler les vulnérabilités activement exploitées de leurs produits. Demander à vos éditeurs comment ils suivent les correctifs du noyau sur leurs plateformes relève désormais de la diligence normale.

À vérifier dans les prochains jours

• Recenser les serveurs, postes et équipements sous Linux, y compris les boîtiers installés par des prestataires et les NAS de sauvegarde.
• Contrôler la version du noyau et la date du dernier redémarrage : un noyau mis à jour sans redémarrage reste souvent vulnérable.
• Interroger les éditeurs et hébergeurs de vos logiciels métier sur leur délai d’application des correctifs du noyau.
• Supprimer les comptes locaux inutiles, les comptes partagés et les comptes de service oubliés, et activer l’authentification multifacteur partout où elle existe.
• Surveiller les journaux qui signalent une élévation de privilèges inhabituelle.
• Avant d’ouvrir votre code ou votre production à un agent IA, faire valider le contrat de sous-traitance, la liste des sous-traitants ultérieurs et le périmètre de test.
• Consigner les décisions prises dans votre registre et, si nécessaire, dans l’analyse d’impact concernée.

Questions fréquentes