L’intelligence des IA de frontière est le prix le plus disputé de la cybersécurité.
La seule question : à qui revient le meilleur morceau ?
Pour l’instant, la vitesse offensive prend l’avantage. Des attaquants qui déploient des frameworks d’IA agentique viennent de compromettre 50 applications d’entreprise en moins de 10 heures, une campagne qui prenait auparavant 10 jours.
Plus de 100 dirigeants de la tech viennent de signer une lettre ouverte avertissant que l’infrastructure numérique manque de temps. Alors que les laboratoires de frontière mettent en place des programmes à accès restreint comme OpenAI Daybreak et le Cyber Verification d’Anthropic pour renforcer les défenseurs, le secteur fait face à une course inconfortable : la défense automatisée peut-elle passer à l’échelle avant que l’exploitation à la vitesse des machines ne prenne le dessus ?
Au sommaire également : comment le phishing vocal a contourné la MFA en quelques secondes, un modèle d’IA qui s’évade trois fois de son sandbox, l’amende de 825 M€ d’Uber pour gouvernance automatisée, et comment Kiji bloque les fuites de données personnelles dans les prompts directement sur les postes des développeurs.
Dans ce numéro
🌡️ Niveau de menace : alerte élevée
⚡ Actualités : cinq histoires de sécurité à rattraper
🔎 Analyse approfondie : la fenêtre des défenseurs se referme
🎣 Est-ce du phishing ?
🔬 Recherche technique : la MFA est tombée. La confiance dans l’appareil a tenu.
🛠️ Outil de la semaine : Kiji Privacy Proxy
👤 Personnalité de la semaine : Hannes Hapke
📅 Événement de la semaine : GrrCON 2026
📚 Livre de la semaine : The Android Hacker’s Handbook de Joshua J. Drake et al.
😅 Le mème
❓ Une question avant de partir
C’est parti.
Avant de passer aux histoires de la semaine, voici où en est le niveau de menace.
🌡️ Niveau de menace
⚡ Actualités
Une seule configuration git multiligne suffit à déclencher une RCE dans GitPython
Une vulnérabilité critique de GitPython (CVE-2026-78676, CVSS 9,8) permet à des attaquants d’obtenir une exécution de code à distance (RCE) quand des applications analysent des configurations de dépôt non fiables. Kodem Security a divulgué que la faille vient d’une re-sérialisation non sécurisée des valeurs de configuration multilignes à l’écriture, qui permet à un attaquant d’injecter des arguments remplaçant core.hooksPath lors d’opérations git ultérieures. Passez immédiatement à GitPython 3.1.59 et traitez tous les fichiers de configuration de dépôt comme des entrées utilisateur non fiables dans les pipelines CI/CD et de scan automatisés.
PaperCut appelle à un correctif d’urgence alors que des attaquants enchaînent des zero-days pour une RCE sur les serveurs d’impression
PaperCut a publié des avis d’urgence et des recommandations de durcissement après une exploitation active dans la nature signalée par des chercheurs en sécurité visant les serveurs PaperCut NG et MF. Des acteurs malveillants ont enchaîné plusieurs vulnérabilités pour obtenir une exécution de code à distance non authentifiée sur des serveurs d’impression exposés à Internet, sans avoir besoin d’identifiants. Appliquez immédiatement les correctifs de l’éditeur, limitez l’accès aux ports de gestion à des VLAN de gestion internes privés et surveillez sur les serveurs d’impression toute exécution anormale de processus enfants.
Des comptes d’hébergement sans privilèges peuvent prendre le root complet du serveur dans cPanel
cPanel a publié des mises à jour obligatoires corrigeant CVE-2026-65643, une vulnérabilité critique d’élévation de privilèges touchant la gestion des domaines parqués et des domaines additionnels dans cPanel et WebHost Manager (WHM). Des divulgations de sécurité ont confirmé que la faille permet à un locataire sans privilèges d’une infrastructure d’hébergement mutualisé de contourner les contrôles de frontière et d’exécuter des commandes arbitraires avec tous les privilèges root. Les hébergeurs mutualisés doivent appliquer immédiatement le dernier build de cPanel/WHM et auditer les configurations cron de root pour repérer des chemins d’exécution de scripts inattendus.
Un calcul de solde défaillant permet à des attaquants de vider des fonds sur six blockchains
Cosmos Labs a publié une alerte d’urgence concernant une vulnérabilité critique de gestion des soldes dans le module Cosmos EVM partagé (GHSA-7g4w-cg88-2cq2). BleepingComputer a rapporté que des attaquants ont activement exploité cette faille de logique entre le 20 et le 25 août pour vider les liquidités d’au moins six réseaux indépendants avant le déploiement de mesures d’atténuation coordonnées par les validateurs. Les équipes de protocole centrales doivent mettre en place une surveillance automatisée des invariants qui interrompt l’exécution des transactions dès que les soldes globaux de tokens échouent aux contrôles de cohérence mathématique.
Pourquoi les jetons OIDC de CI/CD sans contrainte restent une porte ouverte vers l’infrastructure cloud
Des chercheurs en sécurité ont publié une analyse montrant comment des permissions id-token: write génériques dans des workflows GitHub Actions exposent les organisations à des mouvements latéraux entre clouds. La recherche précise que lorsqu’une dépendance compromise infecte un workflow de publication de paquets, elle peut émettre des jetons OIDC pour des fournisseurs cloud non prévus (comme AWS), sauf si une liaison stricte d’audience est explicitement imposée au niveau du fournisseur d’identité. Configurez les politiques de confiance IAM du cloud avec des claims explicites d’audience (aud) et de sujet (sub) pour garantir que les runners de build ne peuvent pas usurper des rôles de production sans rapport.
🔎 Analyse approfondie
La fenêtre des défenseurs se referme
Plus de 100 dirigeants de la tech viennent de signer la même lettre.
Parmi les signataires figurent OpenAI, Anthropic et Google, aux côtés d’entreprises de sécurité comme CrowdStrike, Fortinet et Okta. Leur message n’est pas subtil : les attaques automatisées et dopées à l’IA sont sur le point de passer à l’échelle, et l’infrastructure numérique n’est pas prête.
L’avertissement n’est plus un simple débat théorique sur un risque futur. Cela casse déjà dans la nature.
La compromission en 10 heures
Plus tôt cette année, Palo Alto Networks Unit 42 estimait qu’il faudrait un an pour que des capacités d’IA agentique avancées atteignent les attaquants.
Il a fallu cinq mois.
Unit 42 enquête actuellement sur un incident où un attaquant a utilisé un framework d’IA agentique pour exploiter 50 applications d’entreprise. La compromission a pris moins de 10 heures. À l’ère pré-IA, la même campagne aurait pris au moins 10 jours.
C’est le changement de génération contre lequel met en garde la lettre ouverte. L’IA est désormais un multiplicateur de force sur toute la chaîne d’attaque, du développement de malware à l’ingénierie sociale et à la négociation de rançon. Les attaquants s’en servent pour s’enfoncer dans les chaînes d’approvisionnement logicielles à la vitesse des machines.
Deux calendriers concurrents
La lettre ouverte pointe deux réalités qui avancent à des vitesses différentes :
L’automatisation offensive : les modèles d’IA deviennent assez capables pour découvrir des vulnérabilités, écrire des exploits et cibler des infrastructures avec très peu de direction humaine.
La dette défensive : des systèmes essentiels, des hôpitaux aux stations de traitement de l’eau, restent exposés par des logiciels obsolètes, des permissions excessives et des bugs non corrigés.
C’est ce que la coalition appelle la « fenêtre des défenseurs ».
Pour l’instant, les équipes défensives ont accès aux mêmes capacités de frontière que les attaquants. L’IA peut digérer des bases de code, repérer des mauvaises configurations et rédiger des correctifs plus vite que les revues manuelles traditionnelles.
La fenêtre n’existe que tant que les défenseurs automatisent plus vite que les adversaires.
Les quatre priorités
Pour combler l’écart, la coalition définit quatre orientations principales :
Pour les équipes d’entreprise : traiter la défense avec l’urgence d’un incident actif. Corriger les mauvaises configurations à haut risque, restreindre les permissions et utiliser des modèles moins coûteux pour l’analyse de journaux et de code à gros volume, en réservant les modèles de frontière aux cas limites complexes.
Pour les éditeurs de sécurité : tester en continu les outils face aux capacités des agents IA de frontière et partager des playbooks vérifiés avec les opérateurs qui manquent de ressources.
Pour les gouvernements : orienter les financements défensifs vers les infrastructures critiques, étendre le partage de renseignement sur les menaces et imposer des coûts réels aux acteurs malveillants.
Pour les laboratoires d’IA : donner accès aux modèles aux équipes défensives, garantir que les identités agentiques sont traçables et maintenir des canaux de divulgation responsable.
Les laboratoires d’IA de frontière mettent déjà ce changement en pratique via des programmes d’accès restreint pour des équipes de sécurité vérifiées. OpenAI a étendu son initiative Daybreak, en introduisant Daybreak Blue et Daybreak Red pour donner à des défenseurs approuvés l’accès à des modèles comme GPT-5.6-Cyber, sans garde-fous, pour la découverte de vulnérabilités et la validation d’exploits. De même, Anthropic a créé son Cyber Verification Program, qui offre aux professionnels et organisations de sécurité vérifiés des protections modifiées sur les modèles Claude pour mener des tests et des recherches autorisés sans déclencher de refus faux positifs.
La tension au centre
La lettre contient un paradoxe inconfortable.
Les entreprises d’IA de frontière qui mènent l’appel à la défense sont celles qui développent les capacités rendant l’exploitation autonome possible.
La lettre reconnaît qu’aucune organisation ne contrôlera seule où vont les capacités de l’IA. La posture de sécurité de l’infrastructure numérique ne dépendra pas de l’arrêt du progrès des modèles. Elle dépendra de la capacité de la remédiation défensive à aller enfin plus vite que la découverte automatisée.
D’ici là, la fenêtre est ouverte, mais le compte à rebours tourne.
🎣 Est-ce du phishing ?
Difficulté : moyenne
L’e-mail contient un bouton vous invitant à sécuriser votre compte :
👉 Changer le mot de passe
Lien :
http://myaccount.google.com-securitysettingpage.ml-security.org/signonoptions/Que faites-vous ?
🔐 Cliquer sur le lien et mettre à jour vos identifiants
🗑️ Signaler comme phishing et accéder manuellement aux paramètres de votre compte
🔬 Recherche technique
La MFA est tombée. La confiance dans l’appareil a tenu.
On nous répète sans cesse que l’authentification multifacteur est la réponse au phishing.
Mais parfois, la MFA échoue complètement, et l’entreprise n’est pourtant pas compromise.
C’est la réalité inconfortable derrière l’attaque contre ReliaQuest le 22 août 2026. L’entreprise de cybersécurité a confirmé le 23 août 2026 avoir été ciblée par un attaquant se réclamant du groupe d’extorsion ShinyHunters. Selon ReliaQuest elle-même, les attaquants ont vaincu à la fois le mot de passe et la notification push de MFA pour un employé.
Note : ReliaQuest conteste la présentation en « compromission ». ShinyHunters a publié sur son site de fuites des captures d’écran du tableau de bord Okta pour revendiquer une compromission plus étendue, mais les chercheurs qui ont examiné ces captures ont indiqué qu’elles ne montraient que la page de paramètres d’un seul utilisateur, et ReliaQuest maintient qu’aucune application, aucun système ni aucune donnée client n’a jamais été atteint. Ce qui suit est le récit de l’incident publié par ReliaQuest.
Là où la frontière a cédé
La défaillance s’est produite au niveau humain, contournée par un prétexte très convaincant.
Les attaquants ont mené une campagne de phishing vocal (vishing), en appelant des employés de ReliaQuest en se faisant passer pour un membre de l’équipe sécurité de l’entreprise. L’appelant demandait aux victimes de se connecter à un portail d’authentification unique (SSO) hébergé sur un domaine sosie : reliaquest.claims.
Un employé s’est laissé prendre à la ruse. Il s’est rendu sur la fausse page, a saisi ses identifiants et, point crucial, a approuvé manuellement la notification push de MFA envoyée ensuite sur son téléphone.
À cet instant précis, le périmètre d’identité standard s’est effondré. L’attaquant détenait désormais un mot de passe valide et une session approuvée par la MFA.
Le déroulement de l’attaque
La chaîne d’attaque étape par étape
L’appel de vishing : les attaquants se font passer pour un membre de l’équipe sécurité et dirigent l’employé vers un faux portail de connexion.
Le domaine sosie : l’employé accède à reliaquest.claims au lieu de l’URL SSO légitime.
La collecte d’identifiants : l’employé saisit son mot de passe valide sur le site de collecte.
Le contournement de la MFA : l’employé reçoit une vraie notification push de MFA et l’approuve, croyant qu’elle correspond à sa propre tentative de connexion.
Le pivot vers le tableau de bord : l’attaquant obtient un accès temporaire, en lecture seule, au tableau de bord d’identité de ReliaQuest (Okta).
Le blocage : l’attaquant tente de pivoter du tableau de bord vers les applications en aval, mais l’accès est refusé car la session d’origine n’est pas liée à un poste d’entreprise enregistré et conforme au MDM.
Pourquoi c’est important
Une notification push est, au bout du compte, une décision humaine.
Quand la sécurité repose entièrement sur un employé qui appuie sur « Approuver » ou « Refuser », un ingénieur social habile finira par le convaincre d’appuyer sur « Approuver ».
Cet incident expose l’écart entre authentifier un utilisateur et authentifier un appareil. Les attaquants ont volé le contexte d’identité de l’utilisateur, mais ils n’ont pas pu présenter l’ordinateur portable d’entreprise physique et enregistré. Comme ReliaQuest avait superposé des contrôles de confiance dans l’appareil sous le portail SSO, la tentative de pivot s’est heurtée à un mur concret.
Les sessions de l’attaquant ont été coupées, le mot de passe compromis a été expiré et les facteurs d’authentification ont été réinitialisés. Notamment, ShinyHunters lui-même a dit aux journalistes que son accès était en lecture seule et n’avait atteint aucune application, aucun système ni aucune donnée client — ce qui corrobore le récit de ReliaQuest sur ce point précis.
Ce que les défenseurs doivent en retenir
La leçon pour les équipes de sécurité est simple : si votre histoire de résistance au phishing s’arrête aux notifications push de MFA, elle est incomplète.
Déployer une MFA résistante au phishing : passez aux passkeys FIDO2 / WebAuthn ou aux clés de sécurité matérielles, qui lient cryptographiquement le flux d’authentification à l’origine légitime du navigateur et neutralisent entièrement la collecte d’identifiants et la fatigue des notifications push.
Partir du principe que le push de MFA sera contourné : considérez les notifications push de MFA standard comme vulnérables à la fatigue de la MFA et aux prétextes de vishing.
Imposer la confiance dans l’appareil : configurez vos politiques SSO et d’accès réseau zero trust (ZTNA) pour bloquer l’accès aux applications sauf si la requête provient d’un poste d’entreprise conforme et enrôlé dans le MDM.
Surveiller les enregistrements de domaines sosies : cherchez activement les domaines nouvellement enregistrés qui abusent du nom de votre entreprise avec des domaines de premier niveau peu courants, exactement comme le schéma .claims utilisé ici.
Enquêter sur l’accès en lecture seule : traitez tout accès non autorisé à un tableau de bord d’identité comme un incident critique, même si les applications en aval sont bloquées.
🛠️ Outil de la semaine
Kiji Privacy Proxy
GitHub : https://github.com/dataiku/kiji-proxy
Passerelle open source locale de masquage des données personnelles pour les prompts d’API d’IA.
Où il s’insère : postes des développeurs, agents de code IA locaux et prévention des pertes de données (DLP).
Ce qu’il fait : à mesure que les équipes de sécurité adoptent des assistants de code IA locaux et des agents en ligne de commande, des fichiers de configuration sensibles, des journaux clients internes et des identifiants se retrouvent fréquemment dans les payloads de prompts sortants.
Dataiku ’s kiji-proxy place un point de contrôle léger, côté client, entre les postes des développeurs et les API de fournisseurs d’IA externes (OpenAI, Anthropic, Gemini) :
Machine learning local : exécute localement sur la machine hôte un modèle transformer optimisé ONNX (DistilBERT) pour détecter 26 types de données personnelles, dont e-mails, numéros de sécurité sociale, cartes de crédit et noms, avec une latence inférieure à 100 ms.
Remplacement contextuel : au lieu d’insérer des blocs [REDACTED] destructeurs qui perturbent le raisonnement du modèle, il remplace les valeurs sensibles par des données synthétiques réalistes pour que le LLM conserve un contexte naturel.
Restauration en vol : intercepte la réponse renvoyée par le fournisseur du modèle et remet discrètement en place, localement, les valeurs réelles d’origine avant de livrer la sortie à l’utilisateur.
Démarrage rapide
# Route CLI tools or terminal agents through Kiji's local transparent proxy
export HTTP_PROXY=http://127.0.0.1:8081
export HTTPS_PROXY=http://127.0.0.1:8081
# Run your usual AI workflows—PII is sanitized in flight and restored locally
cat support_dump.txt | claude -p "summarize this customer feedback"Ce qu’il ne remplace pas
Les passerelles réseau de niveau entreprise ou les solutions de DLP d’API côté serveur. kiji-proxy opère au niveau du poste du développeur pour empêcher l’exfiltration accidentelle de prompts avant même que les payloads réseau ne quittent la machine locale.
👤 Personnalité de la semaine
Hannes Hapke
Cette semaine, nous mettons à l’honneur Hannes Hapke, directeur de 575 Lab (le bureau de recherche open source de Dataiku), Google Developer Expert et coauteur de plusieurs livres sur les systèmes de machine learning en production chez O’Reilly et Manning.
Alors que les équipes de développement et de sécurité intègrent de plus en plus des agents IA en ligne de commande et des outils LLM à leur quotidien, des données sensibles (des journaux internes aux clés d’API) peuvent facilement se retrouver dans les payloads de prompts sortants. Pour y remédier, Hannes a dirigé la création et l’ouverture du code de Kiji Privacy Proxy.
Plutôt que de s’appuyer sur de lourdes barrières de conformité d’entreprise ou des filtres côté serveur, Kiji adopte une approche centrée sur les développeurs : faire tourner un proxy ML léger directement sur le poste pour détecter et masquer les données personnelles localement avant que les requêtes réseau ne quittent la machine, puis restaurer les valeurs d’origine au retour des réponses.
Pour avoir construit des outils open source concrets qui aident les développeurs à adopter des workflows d’IA en toute sécurité, sans risquer d’exposer des données sensibles, Hannes Hapke est notre Personnalité de la semaine. 👏
📅 Événement de la semaine
GrrCON 2026
Environ 2 800 chercheurs en sécurité, développeurs, dirigeants et hackers éthiques se réuniront à Grand Rapids en septembre pour la 15e édition de GrrCON, organisée par MidWest InfoSec, LLC , la principale conférence de cybersécurité et d’intelligence artificielle du Midwest.
Connue pour son atmosphère informelle et sans ego, GrrCON privilégie la sécurité concrète, la collaboration ouverte et la recherche plutôt que les discours commerciaux. Le programme de deux jours comprend plusieurs parcours de présentations techniques, ainsi que des ateliers animés par des praticiens et des villages pratiques.
Pour les équipes AppSec et d’ingénierie de la sécurité, la conférence propose des analyses approfondies sur l’exploitation offensive, la chasse aux menaces, l’ingénierie défensive et la gestion des risques émergents liés à l’IA, ce qui en fait un excellent lieu pour obtenir des enseignements exploitables et échanger entre pairs.
📍 Lieu : DeVos Place, Grand Rapids, Michigan
📅 Date : 24 et 25 septembre 2026
📚 Livre de la semaine
Android Hacker’s Handbook
Par Joshua J. Drake , Zach Lanier , Collin Mulliner , Pau Oliva Fora, Stephen A. Ridley et Georg Wicherski
Comment décortiquer les rouages internes du système d’exploitation Android ?
Publié par Wiley, Android Hacker’s Handbook a été le premier guide technique complet consacré à la compréhension, à l’audit et à l’analyse des vulnérabilités de la plateforme Android.
Principaux axes :
Architecture de l’OS et modèle de sécurité : examine les mécanismes sous-jacents par lesquels Android met en œuvre sa conception de sécurité dans le noyau Linux, les daemons natifs et les frameworks de base.
Analyse de vulnérabilités : explique les méthodologies pour identifier des faiblesses dans les composants système, les services de base et les bibliothèques natives C/C++.
Processus de rooting : détaille les schémas de partitions matérielles et le processus de démarrage nécessaires pour obtenir des privilèges élevés.
Fuzz testing : enseigne des approches de découverte automatisée de vulnérabilités avec des outils de fuzzing et l’audit d’IPC/Binder.
Audit d’applications : détaille des techniques pour déconstruire, rétro-concevoir et sécuriser des applications Android.
Contexte et évolution :
Publié en 2014, le livre offre aux lecteurs une base technique solide sur les rouages internes d’Android. Au cours des 12 dernières années, la plateforme a connu de grands changements d’architecture, dont le passage au runtime ART, l’application obligatoire de SELinux, les implémentations Keystore/StrongBox adossées au matériel, les mises à jour modulaires APEX, l’adoption de Rust dans tout le système et ARM Memory Tagging (MTE).
Si les principes fondamentaux restent utiles, 12 ans d’évolution de la plateforme plaident clairement pour une seconde édition mise à jour.
😅 Le mème
Statut du ticket Jira : bloqué (par le hacker) 🥺
Si des frameworks agentiques autonomes peuvent découvrir et exploiter des vulnérabilités dans 50 applications d’entreprise en moins de 10 heures, quel est le seul contrôle défensif que votre équipe ne peut pas se permettre de laisser manuel ?
The Breach Brief, L’équipe Ostorlab