SSRF dans le serveur MCP Grafana : ce que dit la faille

Le serveur MCP Grafana expose les tableaux de bord et les sources de données Grafana aux agents IA via le Model Context Protocol. Le défaut réside dans la gestion des sessions : le serveur accepte des identifiants de session générés par le client, sans vérification côté serveur. Un attaquant peut donc s’auto-attribuer une session valide, puis enchaîner des requêtes vers des cibles internes.

• Vecteur : identifiants de session auto-générés acceptés sans validation.
• Impact : requêtes SSRF arbitraires depuis le serveur, y compris vers les endpoints de métadonnées cloud (169.254.169.254).
• Prérequis : aucun. L’exploitation est non authentifiée.
• Correctif : version 1.1.0 du serveur MCP Grafana.

La conséquence directe est un accès potentiel aux credentials cloud temporaires de l’instance qui héberge le serveur. Sur une infrastructure AWS, GCP ou Azure mal cloisonnée, cela signifie un pivot vers l’ensemble du compte.

Pourquoi le protocole MCP amplifie le risque

Un serveur MCP n’est pas un simple connecteur. Il est conçu pour être appelé par des agents IA, donc pour disposer d’accès larges : bases de métriques, journaux, API internes. En pratique, il concentre les privilèges que vous avez patiemment séparés ailleurs. Une faille SSRF sur ce composant ne fuit pas une donnée isolée : elle ouvre une fenêtre sur tout ce que l’agent avait le droit de consulter.

Détecter une exposition du serveur MCP Grafana

La première étape est l’inventaire. Beaucoup d’équipes ont déployé ce serveur pendant un proof of concept IA, puis l’ont laissé tourner.

• Recherchez les conteneurs actifs : docker ps --format '{{.Image}}' | grep -i mcp-grafana.
• Vérifiez la version exposée et comparez-la à la 1.1.0.
• Listez les ports ouverts vers l’extérieur : un serveur MCP ne doit jamais être joignable depuis Internet.
• Dans les journaux du reverse proxy, cherchez les requêtes contenant des adresses de plage privée ou 169.254.169.254 dans les paramètres.

Signaux d’alerte côté réseau

Un serveur d’observabilité qui initie soudainement des connexions sortantes vers des adresses internes qu’il n’interroge jamais est un indicateur fort. Vos règles de détection doivent traiter cet hôte comme une source de trafic prévisible : toute déviation mérite une alerte, exactement comme pour les autres composants d’exécution évoqués dans notre analyse sur la sécurisation de MLflow face au vol de credentials cloud.

Corriger et durcir : le plan d’action

1. Mettre à jour immédiatement vers la version 1.1.0 du serveur MCP Grafana. C’est le seul correctif qui traite la racine du problème.
2. Bloquer l’accès aux métadonnées cloud depuis l’hôte : imposez IMDSv2 sur AWS, ou filtrez 169.254.169.254 au niveau du pare-feu local.
3. Isoler le serveur MCP dans un segment réseau dédié, avec une politique de sortie en liste blanche vers les seules sources de données nécessaires.
4. Réduire les privilèges du rôle IAM ou du compte de service attaché à l’instance. Le principe du moindre privilège est votre dernier filet quand le SSRF réussit.
5. Faire tourner les secrets qui auraient pu être atteints si l’exposition a duré.

Ce durcissement rejoint la logique appliquée aux autres briques de la chaîne agentique, notamment celle décrite dans notre article sur l’exploitation de Langflow et le vol de clés API.

Le cas particulier des PME-ETI

Sans équipe plateforme dédiée, le risque n’est pas de rater le correctif : c’est de ne pas savoir que le composant existe. Imposez une règle simple : tout serveur MCP mis en production passe par le même processus d’inventaire, de scan de vulnérabilités et de supervision que n’importe quel service exposé. Un connecteur IA n’est pas un outil de développement, c’est un service de production avec des droits étendus.

Ce qu’il faut retenir

La faille SSRF du serveur MCP Grafana illustre une bascule : les connecteurs qui alimentent les agents IA sont devenus des cibles de premier plan, parce qu’ils cumulent une surface d’attaque réseau et une concentration de privilèges. Corrigez en 1.1.0, coupez l’accès aux métadonnées cloud, segmentez, et surtout inventoriez. La vulnérabilité la plus dangereuse reste celle qui tourne sur une machine que personne ne surveille.

Sources

• The Hacker News — Grafana MCP server SSRF (CVE-2026-19516)
• CISA — Known Exploited Vulnerabilities Catalog

Cisco Nexus 9000 : ce que fait réellement la CVE-2026-20212

La vulnérabilité vise dix modèles de commutateurs de la gamme Cisco Nexus 9000. Deux services d’administration interne écoutent sur les ports TCP 43210 et 43211, et ces ports sont accessibles depuis le VRF de gestion Layer 3 configuré par défaut. Aucun identifiant n’est requis : un paquet correctement formé suffit à obtenir une exécution de code avec les privilèges root.

Concrètement, l’attaquant qui atteint ce port depuis votre réseau interne obtient :

• le contrôle total de la configuration du commutateur (VLAN, ACL, routage) ;
• la capacité de rediriger ou dupliquer le trafic vers une machine qu’il contrôle ;
• une persistance très difficile à détecter, car l’équipement réseau sort du périmètre EDR classique ;
• un point de pivot idéal vers la segmentation industrielle ou les VLAN serveurs.

Le point aggravant est la configuration par défaut. Beaucoup d’équipes réseau supposent que ces ports internes sont filtrés d’usine. Ils ne le sont pas.

Pourquoi les PME-ETI sont particulièrement exposées

Dans les organisations de taille intermédiaire, le commutateur de cœur est souvent installé une fois puis oublié pendant des années. L’inventaire des versions NX-OS est rarement à jour, et le VRF de gestion est fréquemment fusionné avec le VLAN administratif utilisé par le support informatique. Résultat : la surface d’attaque de la CVE-2026-20212 n’est pas réduite à quelques administrateurs, mais ouverte à tout poste compromis par un phishing.

Étape 1 : inventorier vos commutateurs Cisco Nexus 9000

Commencez par établir la liste exhaustive des équipements concernés et de leur version NX-OS. Sur chaque commutateur :

• show version — relevez la version NX-OS et le modèle exact ;
• show module — identifiez les cartes et superviseurs installés ;
• show vrf — listez les VRF actifs, en particulier le VRF de gestion ;
• show sockets connection tcp — vérifiez si les ports 43210 et 43211 sont en écoute.

Confrontez ensuite cette liste à l’avis officiel Cisco pour savoir si votre modèle et votre version figurent parmi les combinaisons vulnérables. Si vous n’avez pas d’inventaire réseau centralisé, c’est le moment de le créer : sans lui, chaque avis de sécurité vous coûtera une journée de recherche.

Étape 2 : bloquer l’accès aux ports 43210 et 43211

Le correctif éditeur reste la seule remédiation complète, mais l’atténuation réseau se déploie en quelques minutes et réduit immédiatement le risque de RCE non authentifiée. Appliquez une ACL de contrôle de plan de gestion qui n’autorise que vos postes d’administration :

• créez une ACL nommée qui refuse explicitement TCP 43210 et 43211 depuis toute source hors bastion ;
• appliquez-la en entrée sur les interfaces du VRF de gestion, pas seulement sur les interfaces utilisateur ;
• vérifiez qu’aucune interface de données ne partage le VRF par défaut avec la gestion ;
• doublez le filtrage au niveau du pare-feu de segmentation, pour survivre à une erreur de configuration locale.

Testez ensuite depuis un poste utilisateur standard : une tentative de connexion sur ces deux ports doit échouer. C’est votre preuve de remédiation, à conserver pour l’audit.

Isoler le plan de gestion, une fois pour toutes

Cette faille est un rappel : le plan de gestion des équipements réseau doit vivre dans un VLAN dédié, joignable uniquement depuis un bastion, avec authentification forte et journalisation. Cette architecture neutralise non seulement la CVE-2026-20212, mais aussi la prochaine vulnérabilité du même type. Le même raisonnement s’applique à vos autres équipements Cisco, comme l’a montré la faille du mot de passe codé en dur sur Cisco FMC.

Étape 3 : appliquer le correctif NX-OS et vérifier

Planifiez la mise à jour NX-OS dans une fenêtre de maintenance courte, en commençant par les commutateurs les moins critiques pour valider la procédure. Points de contrôle :

• sauvegardez la configuration courante et le fichier de démarrage avant toute opération ;
• validez la compatibilité de la version cible avec vos cartes et vos fonctionnalités actives ;
• sur une paire vPC, mettez à jour un membre à la fois pour préserver la disponibilité ;
• après redémarrage, revérifiez show version et l’état d’écoute des ports 43210 et 43211.

Si le correctif ne peut pas être appliqué avant plusieurs semaines, documentez formellement l’atténuation par ACL comme mesure compensatoire, avec une date de revue. Une exception non tracée devient une dette invisible.

Étape 4 : chasser les traces d’exploitation

Une RCE non authentifiée sur un commutateur laisse peu de traces locales, mais votre supervision réseau en garde. Recherchez :

• toute connexion réussie vers les ports 43210 ou 43211 depuis une source non administrative dans vos journaux de flux (NetFlow, pare-feu) ;
• des modifications de configuration hors fenêtre de changement, via l’historique show accounting log ;
• l’apparition de sessions SPAN ou de redirections de trafic que personne n’a demandées ;
• des comptes locaux ou des clés SSH ajoutés récemment sur l’équipement.

Centralisez ces journaux dans votre SIEM. Un commutateur qui n’envoie rien à la supervision est un angle mort permanent, quelle que soit la CVE du jour.

Réduire la fenêtre d’exposition, pas seulement corriger

La CVE-2026-20212 sur Cisco Nexus 9000 se corrige en trois gestes : inventorier, filtrer, patcher. Mais le vrai gain se situe en amont, dans la capacité à passer d’un avis éditeur à une remédiation vérifiée en moins de 48 heures. C’est exactement l’enjeu que nous détaillons dans notre article sur la réduction de la fenêtre de patch. Un équipement réseau non corrigé n’est pas un risque théorique : c’est un accès root offert à quiconque atteint votre VLAN de gestion.

Sources

• The Hacker News — Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root
• Security Affairs — Cisco fixes critical RCE in Nexus 9000 Series Switches
• SecurityWeek — Cisco warns of unpatched secure email flaws, patches critical switch vulnerabilities

Pourquoi un dépôt Git piégé contourne l’écran de confiance

Le raisonnement des éditeurs d’agents IA repose sur une idée simple : avant d’agir sur un projet inconnu, l’agent affiche un écran de confiance et attend un accord explicite. Le problème est que cet écran arrive trop tard. Git lui-même lit et applique la configuration locale du dépôt dès les premières opérations : résolution de l’état du répertoire, affichage des branches, lecture des différences. Or cette configuration peut définir des hooks, des pagers ou des filtres — c’est-à-dire des commandes système.

L’agent, lui, exécute ces opérations Git de manière automatique pour comprendre le contexte du projet. Il croit lire ; en réalité il exécute. Le dépôt Git piégé transforme une simple action de reconnaissance en primitive d’exécution de code, sans exploiter la moindre faille mémoire et sans que l’utilisateur ait validé quoi que ce soit.

• Vecteur d’entrée : dépôt public cloné, archive fournie par un client, fork d’un projet open source, répertoire partagé par un prestataire.
• Déclencheur : la première commande Git lancée par l’agent pour cartographier le projet.
• Impact : exécution sous l’identité du développeur, avec ses clés SSH, ses jetons cloud et son accès au dépôt d’entreprise.

Ce que cela change pour la sécurité des agents IA en PME-ETI

La conclusion opérationnelle est moins spectaculaire que le titre, mais plus lourde : un agent IA de code n’est pas un lecteur, c’est un exécutant. Chaque assistant installé sur un poste de développement doit être traité comme un compte de service disposant des droits de son utilisateur — donc audité, cloisonné et journalisé au même titre.

Cette logique rejoint ce que nous décrivions à propos de la sécurisation des workflows GitHub pilotés par des agents IA : le maillon faible n’est pas le modèle, c’est le périmètre d’exécution qu’on lui accorde par défaut. Le même raisonnement s’applique aux plateformes d’orchestration, comme l’a rappelé l’exploitation de la faille Langflow et le vol de clés API.

Le contenu non fiable est devenu du code

Pendant vingt ans, la règle était : ne pas exécuter les binaires reçus de l’extérieur. Avec les agents, la frontière se déplace. Un fichier de configuration, un README, un commentaire de code ou un ticket peuvent porter des instructions que l’agent interprétera. Le dépôt Git piégé n’est qu’une déclinaison particulièrement propre de ce principe : le contenu non fiable est désormais une surface d’exécution.

Sécuriser vos agents IA de code : les mesures qui tiennent

Aucune de ces mesures ne dépend d’un correctif éditeur. Elles restent valables quel que soit l’assistant retenu.

• Cloisonner l’exécution : faire tourner les agents dans un conteneur ou une machine virtuelle jetable, sans accès direct aux clés SSH de production ni aux jetons cloud long terme.
• Séparer les identités : un compte Git dédié aux agents, avec des droits en lecture seule sur les dépôts sensibles et aucun droit de publication automatique.
• Inspecter avant d’ouvrir : sur un dépôt d’origine externe, vérifier .git/config et le répertoire .git/hooks avant de lancer l’agent, ou cloner avec une configuration neutralisée.
• Journaliser les processus enfants : la détection utile porte sur les commandes lancées par le binaire de l’agent, pas sur son trafic réseau. Un EDR correctement réglé voit ce comportement.
• Maintenir les assistants à jour : les correctifs existent chez plusieurs éditeurs, et le rythme de publication est rapide. Le suivi de version doit entrer dans le cycle de patch classique.
• Fixer une règle d’entreprise : interdire l’usage des agents IA sur du code client non vérifié depuis un poste disposant d’accès de production.

Une question de gouvernance, pas d’outillage

Les entreprises qui encaissent le mieux ce type d’incident ne sont pas celles qui ont le meilleur assistant, mais celles qui ont posé une frontière nette entre l’environnement où l’IA travaille et l’environnement où résident les secrets. C’est exactement l’approche que nous appliquons chez ucyber.ai : un SOC agentique qui corrèle les comportements réels des processus, adossé à un capteur de terrain, plutôt qu’une confiance accordée à l’intention déclarée d’un outil.

Un agent IA de code apporte un gain de productivité réel. Il mérite le même cadre de sécurité que n’importe quel automate disposant d’un shell.

Sources

• The Hacker News — Malicious .git Configs Can Make Claude, Codex, Cursor and Other AI Agents Run Attacker Code
• Dark Reading — AI’s Vulnerability Surge May Be More Manageable Than First Feared
• SecurityWeek — OpenLeash Adds a Human Check to Risky AI Agent Actions

Faille Langflow : ce que font réellement les attaquants

Langflow est un outil open source très répandu pour construire visuellement des chaînes d’agents IA. Son point faible est structurel : pour fonctionner, il doit détenir en clair les identifiants des modèles et des services cloud qu’il orchestre. La faille Langflow exploitée actuellement permet à un attaquant non authentifié d’atteindre ces secrets sur une instance exposée.

• Découverte : balayage massif des ports exposant l’interface Langflow sur Internet.
• Exploitation : contournement des contrôles d’accès sur une instance non corrigée.
• Exfiltration : récupération des clés OpenAI, Anthropic, AWS et des variables d’environnement du projet.
• Monétisation : consommation de crédits LLM, minage, ou pivot vers l’infrastructure cloud avec les clés AWS.

Le schéma n’est pas nouveau. Il rejoint la vague d’attaques visant les plateformes MLOps que nous avions décrite dans notre analyse de la faille MLflow : l’outillage IA est déployé vite, exposé par commodité, et rarement inventorié.

Pourquoi les PME et ETI sont les cibles idéales

Les grands groupes placent leurs plateformes IA derrière un VPN et un SSO. Dans les structures plus petites, le prototype d’agent IA est souvent monté par une équipe produit, hébergé sur une VM cloud, exposé publiquement le temps d’une démonstration — puis oublié. Trois facteurs aggravent le risque :

• Des clés surprivilégiées : une clé AWS créée « pour aller vite » dispose souvent de droits bien supérieurs au besoin réel.
• Aucune rotation : la clé volée reste valide des mois, comme le montrent les incidents de clés AWS exposées.
• Aucune supervision : la consommation anormale de tokens n’est détectée qu’à la facturation.

Le vol de secrets liés à l’IA s’inscrit dans une tendance de fond : les attaquants ciblent désormais l’identité machine et les jetons d’accès plutôt que les mots de passe humains, comme l’illustre le vol de sessions IA par infostealer.

Corriger la faille Langflow et réduire l’exposition

Actions immédiates (aujourd’hui)

• Inventorier toutes les instances Langflow, n8n, Flowise, Dify et MLflow du parc, y compris celles montées hors DSI.
• Mettre à jour Langflow vers la dernière version publiée par l’éditeur.
• Retirer l’exposition Internet : placer l’interface derrière un VPN ou un reverse proxy authentifié.
• Révoquer et régénérer toutes les clés API référencées dans les flux, sans exception, si l’instance a été exposée.

Mesures structurelles (sous 30 jours)

• Sortir les secrets du produit : utiliser un coffre (Vault, AWS Secrets Manager) plutôt que les variables d’environnement de l’application.
• Appliquer le moindre privilège aux clés cloud : une clé par usage, périmètre IAM restreint, expiration courte.
• Plafonner les budgets LLM par projet et activer les alertes de consommation — c’est souvent le premier signal d’un vol de clé.
• Superviser les appels sortants des serveurs d’orchestration IA : un agent qui contacte une IP inconnue est un incident.

Détection : ce qu’il faut chercher dans les journaux

• Requêtes HTTP répétées vers les points d’entrée de l’API Langflow depuis des IP externes.
• Appels API OpenAI ou AWS depuis une géolocalisation ou une plage d’adresses inhabituelle.
• Création de nouveaux utilisateurs IAM ou de clés d’accès non planifiées.
• Pic de consommation de tokens en dehors des heures ouvrées.

Ce que cette faille Langflow révèle du risque IA en 2026

La faille Langflow n’est pas un incident isolé : c’est le symptôme d’un périmètre nouveau. Chaque plateforme d’agents IA concentre, en un seul point, les identifiants les plus sensibles de l’entreprise — accès modèles, accès cloud, accès données. Traiter ces plateformes comme des outils de développement anodins revient à laisser un coffre-fort ouvert sur Internet. La bonne posture consiste à les inventorier, les isoler et les superviser au même niveau qu’un contrôleur de domaine.

Sources

• BleepingComputer — Critical Langflow flaw exploited to steal OpenAI and AWS keys
• Dark Reading — Critical Langflow Flaw Exploited as Attacks on AI Platform Rise
• SecurityWeek — Hackers start exploiting critical Langflow vulnerability

Comment fonctionne l’attaque TerminalFix

Le scénario est volontairement banal. L’utilisateur arrive sur une page web qui affiche un faux CAPTCHA, un faux message « votre navigateur doit être réparé » ou une fausse erreur de mise à jour. La page lui demande de prouver qu’il n’est pas un robot en suivant trois étapes : appuyer sur Windows + R, coller le contenu du presse-papiers, puis valider avec Entrée.

Ce que la victime ignore, c’est que la page a silencieusement rempli son presse-papiers avec une commande PowerShell encodée. En validant, elle lance elle-même le téléchargement de la charge utile. Cette famille de techniques, souvent regroupée sous le nom ClickFix, atteint avec TerminalFix un niveau de discrétion supérieur : la charge finale n’est pas un ransomware bruyant, mais un tunnel inverse établi vers l’infrastructure de l’attaquant.

Pourquoi le tunnel inverse change la donne

Un tunnel inverse est initié depuis l’intérieur du réseau. Votre pare-feu voit une connexion sortante, souvent en HTTPS sur le port 443, vers un domaine qui n’a rien d’alarmant. Aucune règle entrante n’est violée. L’attaquant obtient un accès interactif persistant, exploitable des semaines plus tard pour du vol de données ou un déploiement de ransomware. C’est exactement la logique déjà observée dans les campagnes de C2 furtif via des services légitimes, mais sans même avoir besoin d’un compte cloud compromis.

Détecter TerminalFix sur vos postes

La bonne nouvelle : la chaîne d’exécution laisse des traces très caractéristiques. Trois signaux valent une alerte immédiate.

• PowerShell lancé depuis explorer.exe — la boîte de dialogue Exécuter est un enfant d’explorer.exe. Un processus powershell.exe ou cmd.exe dont le parent est explorer.exe et dont la ligne de commande contient -enc, -EncodedCommand, -w hidden, IEX ou DownloadString est anormal sur un poste bureautique.
• Écriture dans la clé RunMRU — Windows journalise chaque commande tapée dans Exécuter sous HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. Une entrée contenant du base64 ou une URL est une preuve directe de TerminalFix.
• Binaire de tunnelisation inattendu — surveillez l’apparition de clients de tunnel légitimes détournés dans les répertoires utilisateur, ainsi que toute connexion sortante longue durée depuis un poste qui n’en établit jamais.

Une règle de détection à activer aujourd’hui

Si vous exploitez un SIEM, corrélez ces trois éléments plutôt que de les traiter isolément : parent explorer.exe, interpréteur de commandes, argument encodé. Le taux de faux positifs est très faible sur un parc bureautique, ce qui en fait une règle idéale pour un SOC déjà saturé par le bruit des alertes. Activez également la journalisation des blocs de script PowerShell (Script Block Logging) via GPO : sans elle, la commande encodée reste invisible dans vos journaux.

Bloquer TerminalFix avant l’exécution

La détection est utile, la prévention l’est davantage. Quatre mesures se déploient en quelques heures et coupent la chaîne d’attaque à la racine.

• Désactiver la boîte de dialogue Exécuter pour les profils bureautiques via la stratégie de groupe Supprimer le menu Exécuter du menu Démarrer. C’est la mesure la plus efficace contre TerminalFix, et son impact métier est quasi nul sur un poste standard.
• Restreindre PowerShell aux administrateurs avec AppLocker ou WDAC, et passer les postes utilisateurs en mode langage contraint (Constrained Language Mode).
• Filtrer le trafic sortant. Un poste bureautique n’a aucune raison d’ouvrir une session persistante vers un domaine inconnu. Un proxy avec inspection et liste d’autorisation réduit drastiquement la surface du tunnel inverse.
• Former sur ce geste précis. Le message à faire passer tient en une phrase : aucun site web légitime ne vous demandera jamais d’appuyer sur Windows + R et de coller quoi que ce soit.

Vérifier que vos protections tiennent

Testez la règle depuis un poste de recette : ouvrez Exécuter, tapez une commande PowerShell anodine encodée en base64, et vérifiez qu’une alerte remonte bien dans votre console. Une détection non testée est une détection qui n’existe pas. Contrôlez ensuite que la GPO de suppression du menu Exécuter est appliquée sur l’ensemble des unités d’organisation concernées, et pas seulement sur le groupe pilote.

Ce que TerminalFix révèle de votre posture

Cette campagne ne repose sur aucune vulnérabilité : elle exploite la confiance de l’utilisateur et la permissivité de la configuration Windows par défaut. Se protéger de TerminalFix revient donc à durcir le poste de travail — restreindre les interpréteurs, journaliser leur usage, contrôler les flux sortants. Ces trois chantiers vous protègent aussi de la majorité des chaînes d’infection actuelles, bien au-delà de cette seule campagne. C’est le meilleur retour sur investissement disponible pour une PME ou une ETI aujourd’hui.

Sources

• BleepingComputer — Microsoft warns of TerminalFix attacks deploying reverse tunnels
• Dark Reading — TerminalFix campaign weaponizes PowerShell for enterprise attacks

Pourquoi le vol de sessions IA change la donne

Un jeton de session est une preuve d’authentification déjà accordée. Il court-circuite le mot de passe, le second facteur et, bien souvent, les alertes de connexion. Quand un infostealer aspire les fichiers de configuration, les cookies de navigateur et les répertoires de credentials d’un poste de travail, il récupère aussi les jetons des outils IA installés localement : CLI d’agents, extensions d’éditeur, sessions web ouvertes.

L’exploitation immédiate est financière — la consommation du quota — mais elle n’est que la partie visible. Un jeton d’agent IA détourné donne aussi accès à l’historique des conversations, donc potentiellement à des extraits de code propriétaire, à des schémas d’architecture, à des noms d’hôtes internes et à des secrets collés dans un prompt. C’est une fuite de données silencieuse, sans exfiltration réseau visible depuis vos serveurs.

Le poste de travail redevient le maillon faible

La chaîne d’attaque est classique et c’est précisément ce qui la rend efficace : installeur piégé, extension de navigateur malveillante ou fausse page de vérification, puis collecte automatisée. Les attaques visant l’IA locale l’ont déjà montré — ce qui tourne sur le poste échappe à la plupart des contrôles périmétriques.

Ce que le vol de sessions IA expose vraiment

• Le quota et le budget : consommation frauduleuse, facturation en hausse, dégradation du service pour vos équipes.
• L’historique : code source, configurations, éléments d’infrastructure partagés dans les échanges.
• Les intégrations : un agent connecté à un dépôt Git, à une base de tickets ou à un connecteur MCP hérite de ces accès.
• L’identité : les actions réalisées apparaissent comme légitimes puisqu’elles proviennent d’une session valide.
• La confiance dans les journaux : sans corrélation, rien ne distingue l’usage normal de l’usage détourné.

Sécuriser les sessions IA en PME-ETI : les mesures concrètes

La bonne nouvelle est que le vol de sessions IA se traite avec des contrôles que vous maîtrisez déjà, appliqués à un nouveau périmètre.

1. Inventorier les accès IA

Recensez qui utilise quel assistant, avec quel compte et sur quel poste. Un compte IA partagé entre plusieurs personnes rend toute investigation impossible. Privilégiez les comptes nominatifs rattachés à votre SSO d’entreprise plutôt que des inscriptions individuelles.

2. Réduire la durée de vie des jetons

Forcez la réauthentification périodique et révoquez immédiatement les sessions d’un poste suspect. Traitez la révocation de session IA comme vous traitez la révocation d’une clé d’API cloud : c’est le même geste, sur le même type d’actif.

3. Surveiller la consommation comme un signal de sécurité

Un pic de consommation hors horaires, depuis une géolocalisation inhabituelle ou sur un modèle que l’équipe n’utilise pas, est un indicateur de compromission. Remontez ces métriques dans votre SOC au même titre qu’une authentification anormale.

4. Durcir le poste de travail

C’est là que se joue l’essentiel : EDR à jour, contrôle des extensions de navigateur, blocage des installeurs non signés, et sensibilisation aux fausses pages de vérification. Les bonnes pratiques appliquées aux assistants IA internes valent aussi pour les postes qui les consomment.

5. Limiter ce que l’agent peut atteindre

Un agent IA ne devrait disposer que des accès strictement nécessaires. Si un jeton compromis ouvre votre dépôt de production, le problème n’est pas seulement le jeton — c’est le périmètre qu’il porte.

Le compte IA est un accès à privilèges

Le vol de sessions IA n’est pas une nouvelle catégorie de menace : c’est l’extension d’un schéma connu à un actif que beaucoup d’organisations n’ont pas encore classé comme sensible. Tant que l’assistant IA reste un outil « personnel » hors de l’inventaire, il échappe à la gestion des identités, à la journalisation et à la réponse à incident. Le traiter comme un accès à privilèges — nominatif, révocable, surveillé et cloisonné — est la mesure la plus rentable que puisse prendre une PME-ETI aujourd’hui.

Sources

• BleepingComputer — Anthropic warns infostealer malware is hijacking Claude sessions
• BleepingComputer — Chrome Web Store extensions caught stealing browser data

Faille PaperCut : deux vulnérabilités chaînées pour une RCE non authentifiée

PaperCut NG et PaperCut MF sont des solutions de gestion et de facturation d’impression déployées dans des milliers d’établissements : collectivités, cabinets, universités, industries. Les chercheurs ont montré que deux vulnérabilités distinctes peuvent être chaînées pour obtenir une exécution de code à distance sans aucune authentification.

• La première faille permet de contourner les contrôles d’accès de l’interface d’administration exposée.
• La seconde autorise l’écriture ou l’exécution de contenu contrôlé par l’attaquant depuis cette interface.
• Combinées, elles donnent un shell sur le serveur, avec les droits du service PaperCut — souvent SYSTEM sous Windows.

L’exploitation a été observée avant la disponibilité du second correctif. Autrement dit : les organisations qui ont appliqué uniquement le premier patch se croyaient protégées alors que la chaîne d’attaque restait fonctionnelle. C’est exactement le scénario qui transforme une vulnérabilité connue en compromission réelle.

Pourquoi un serveur d’impression est une cible de choix

Un serveur d’impression n’a l’air de rien, mais il concentre plusieurs propriétés qui intéressent un attaquant :

• Il est joignable depuis tout le réseau bureautique, par construction.
• Il détient fréquemment un compte de service Active Directory avec des droits larges, pour l’authentification des utilisateurs et la synchronisation des annuaires.
• Il traite des documents : bulletins de paie, contrats, plans, factures — une mine pour l’extorsion.
• Il est rarement couvert par les campagnes de patch, qui se concentrent sur les postes et les serveurs applicatifs.

Historiquement, les failles PaperCut ont déjà servi de point d’entrée à des groupes de ransomware. Ce n’est pas un risque théorique : c’est un chemin d’attaque documenté et rejoué.

Corriger la faille PaperCut : les actions à mener aujourd’hui

1. Identifier vos instances, y compris celles que vous avez oubliées

Commencez par l’inventaire. Un serveur d’impression installé par un prestataire il y a cinq ans reste une instance exposée. Recherchez les ports d’administration PaperCut (typiquement 9191 en HTTP et 9192 en HTTPS) sur l’ensemble de vos plages internes, et vérifiez qu’aucun d’eux n’est publié sur Internet.

2. Appliquer le second correctif, pas seulement le premier

Vérifiez le numéro de version exact dans la console d’administration et comparez-le à la dernière version publiée par l’éditeur. Si votre mise à jour date d’avant le second bulletin, vous êtes toujours vulnérable. Sur ce type d’incident, « patché » ne veut rien dire sans numéro de build.

3. Retirer l’interface d’administration d’Internet

Aucune console d’administration PaperCut ne devrait être accessible publiquement. Placez-la derrière un VPN ou restreignez l’accès à un sous-réseau d’administration dédié. Cette seule mesure neutralise la majorité des tentatives opportunistes, y compris pour les prochaines failles encore inconnues.

4. Réduire les privilèges du compte de service

Si le service PaperCut tourne en SYSTEM ou avec un compte AD sur-privilégié, une RCE devient immédiatement une compromission de domaine. Basculez vers un compte de service dédié, sans droits d’administration de domaine, et appliquez le principe du moindre privilège aux partages qu’il consulte.

5. Chercher des traces de compromission

Un patch ne supprime pas une porte dérobée déjà installée. Recherchez les processus enfants anormaux lancés par le service PaperCut (cmd.exe, powershell.exe, interpréteurs de scripts), les fichiers déposés récemment dans les répertoires de l’application, les comptes d’administration créés hors procédure et les connexions sortantes inhabituelles depuis le serveur. Ces recherches sont exactement ce qu’un SOC instrumenté détecte en quelques minutes.

Industrialiser le patch pour éviter le prochain PaperCut

La faille PaperCut illustre un problème structurel plutôt qu’un incident isolé : les actifs « périphériques » (impression, sauvegarde, supervision, forge logicielle) échappent aux cycles de correctifs. La réponse n’est pas de patcher plus vite dans l’urgence, mais de réduire durablement la fenêtre d’exposition.

• Inventaire continu plutôt qu’annuel : tout service qui écoute sur le réseau entre dans le périmètre.
• Détection des versions automatisée, pour identifier en une requête toutes les instances non conformes.
• Surveillance comportementale sur les serveurs applicatifs, pour attraper l’exploitation même sans signature.
• Procédure de re-vérification après chaque correctif d’urgence : un second bulletin en quelques jours doit déclencher une nouvelle passe.

Nous avions détaillé cette logique de fenêtre de patch dans notre article sur la réduction de la fenêtre de patch du N-day au N-hour, et l’approche appliquée aux forges auto-hébergées dans sécuriser Gitea contre la RCE. Le raisonnement est identique ici : un service interne, discret et non supervisé, est le meilleur point d’entrée qu’un attaquant puisse espérer.

Ce qu’il faut retenir

La faille PaperCut exploitée en conditions réelles rappelle trois règles simples : un serveur d’impression est un serveur applicatif comme un autre, un correctif d’urgence suivi d’un second correctif impose une re-vérification complète, et une console d’administration exposée sur Internet est une compromission en attente de calendrier. Vérifiez vos versions aujourd’hui, sortez les interfaces d’administration du web public, et surveillez les processus enfants de vos services d’impression.

Sources

• BleepingComputer — PaperCut releases second emergency patch for exploited flaws
• The Hacker News — Attackers Chain Two PaperCut Flaws to Execute Code Without Authentication
• The Record — PaperCut warns of hackers using printer management software flaw in attacks

Ce tutoriel détaille les étapes concrètes pour identifier votre exposition, appliquer le correctif et durcir durablement votre instance.

Pourquoi sécuriser Gitea est prioritaire pour une PME-ETI

Gitea séduit les équipes techniques françaises pour de bonnes raisons : léger, auto-hébergeable, sans coût de licence par utilisateur. Mais cette simplicité de déploiement a un revers : l’instance est souvent installée par un développeur, publiée derrière un reverse proxy, puis oubliée du cycle de patch.

Or une forge Git n’est pas un outil secondaire. Elle concentre :

• le code source de vos produits et de vos intégrations clients ;
• les jetons CI/CD et clés de déploiement stockés en variables de runner ;
• les clés SSH de vos développeurs, avec leurs droits sur la production ;
• l’historique complet, où dorment souvent des secrets commités par erreur.

Une exécution de code à distance sur cette machine donne à l’attaquant un accès en écriture aux dépôts. Il n’a plus besoin de voler des identifiants : il injecte sa charge dans un workflow, et votre propre chaîne de build la déploie en production. C’est le scénario de supply chain interne, celui que nous décrivions déjà dans notre article sur les workflows de code sécurisés.

Étape 1 : inventorier et détecter votre exposition

Identifier la version installée

La version est affichée en pied de page de l’interface web, mais la source fiable reste le binaire :

• en installation native : gitea --version ;
• en conteneur : docker exec gitea gitea --version ;
• à distance, sans authentification : l’endpoint /api/v1/version renvoie la version — ce qui signifie aussi qu’un attaquant peut cartographier vos instances vulnérables en quelques secondes.

Vérifier ce qui est réellement joignable

Beaucoup d’équipes croient leur forge interne alors qu’un port a été ouvert « temporairement ». Depuis l’extérieur de votre réseau, testez le port HTTP(S) et le port SSH de Gitea (3000 et 22 par défaut). Si l’interface répond depuis Internet sans VPN, vous êtes dans la population des 8 300 instances à risque.

Étape 2 : appliquer le correctif sans casser la production

La mise à jour de Gitea est simple, mais elle touche une base de données. L’ordre compte :

• Sauvegardez d’abord : gitea dump produit une archive contenant la base, les dépôts et la configuration. Vérifiez que l’archive n’est pas vide avant de continuer.
• Arrêtez le service (systemctl stop gitea) pour éviter une migration de schéma sur une base en écriture.
• Remplacez le binaire par la dernière version stable, ou tirez l’image conteneur correspondante — évitez le tag latest, épinglez une version précise.
• Redémarrez et contrôlez les logs de migration avant de rouvrir l’accès aux utilisateurs.

Si vous ne pouvez pas patcher immédiatement, la mesure d’atténuation la plus efficace est de retirer l’instance d’Internet : placez-la derrière un VPN ou un proxy authentifiant. Une forge Git n’a presque jamais besoin d’être publique. Cette logique de réduction de la fenêtre d’exposition est détaillée dans notre article sur la réduction du délai de patch.

Étape 3 : durcir la configuration pour sécuriser Gitea dans la durée

Patcher règle la faille du jour. Le durcissement règle les suivantes. Quatre réglages du fichier app.ini changent radicalement votre surface d’attaque :

• Désactiver l’inscription libre : DISABLE_REGISTRATION = true. Une forge d’entreprise n’a aucune raison d’accepter des comptes créés depuis Internet.
• Fermer l’API anonyme : REQUIRE_SIGNIN_VIEW = true empêche l’énumération des dépôts et des utilisateurs par un visiteur non authentifié.
• Encadrer les runners CI : les runners Gitea Actions exécutent du code arbitraire. Isolez-les sur une machine dédiée, jamais sur l’hôte de la forge, et limitez leurs jetons au strict périmètre nécessaire.
• Imposer la double authentification aux comptes administrateurs et propriétaires d’organisation.

Surveiller les signaux d’une compromission

Trois événements méritent une alerte immédiate dans votre SIEM :

• création d’un compte administrateur ou élévation de privilèges sur une organisation ;
• ajout d’une clé SSH ou d’un jeton d’accès personnel hors des heures ouvrées ;
• apparition d’un fichier de workflow modifié sur une branche par défaut, sans revue associée.

Ces signaux sont exactement ceux qu’un SOC augmenté par l’IA sait corréler : pris isolément, chacun est banal ; enchaînés en quelques minutes, ils dessinent une prise de contrôle. Complétez ce dispositif par une détection des secrets exposés, comme expliqué dans notre article sur les fuites de clés dans les dépôts.

Ce qu’il faut retenir

Sécuriser Gitea ne demande ni budget ni projet : un inventaire des instances, un patch appliqué proprement, quatre lignes de configuration et trois règles de détection. Le vrai risque n’est pas la faille elle-même, c’est l’instance que personne ne s’est attribuée. Traitez votre forge Git comme ce qu’elle est réellement : un système de production critique, au même niveau que votre ERP ou votre annuaire.

Sources

• BleepingComputer — Over 8,300 Gitea servers vulnerable to code execution attacks

Pourquoi les garde-fous IA fuient de l’information

Un modèle de langage n’a pas de mécanisme d’autorisation. Il produit du texte, et le refus est du texte comme un autre. Quand un assistant répond « je ne peux pas vous aider avec cela », il vient de révéler que la requête a touché une zone sensible — donc qu’il existe une zone sensible, et qu’elle est atteignable.

Le mécanisme s’appelle un oracle de refus. L’attaquant ne cherche pas à obtenir la réponse interdite du premier coup : il envoie des dizaines de variantes et note lesquelles passent, lesquelles bloquent. Le signal binaire refus/réponse suffit à cartographier :

• les sujets couverts par le filtrage — donc les sujets jugés critiques par l’entreprise ;
• la formulation exacte qui déclenche le blocage, et celle qui l’esquive ;
• l’existence de documents internes, quand le refus change de ton selon que la donnée existe ou non ;
• la présence d’outils connectés (bases, API, tickets), révélée par des messages d’erreur trop bavards.

Ce dernier point est le plus coûteux : un assistant branché sur votre base documentaire qui répond « ce document est confidentiel » au lieu de « je n’ai pas trouvé » vient de confirmer l’existence du document. La différence semble anodine. Elle ne l’est pas.

Le refus comme canal auxiliaire

C’est la logique classique du side-channel appliquée à l’IA. En cryptographie, on mesure le temps de calcul pour deviner une clé. Ici, on mesure le comportement du filtre pour deviner le contenu. La différence : aucun exploit, aucune CVE, aucun correctif à appliquer. L’attaquant utilise le produit exactement comme prévu.

Ce que ça change pour une PME-ETI

La plupart des déploiements que nous voyons partagent le même schéma : un assistant interne, connecté au SharePoint ou au CRM, accessible à tous les salariés, parfois exposé à des partenaires. Trois conséquences directes :

• La surface n’est pas le modèle, c’est l’accès. Le fournisseur sécurise le modèle ; c’est vous qui décidez ce qu’il peut lire.
• Le prompt système n’est pas un secret. Il finit toujours par fuir, par accumulation de refus et de reformulations. Ne pas y mettre de règle métier confidentielle ni de nom d’infrastructure.
• Le sondage est indétectable par défaut. Cent requêtes refusées ressemblent à un utilisateur maladroit, sauf si vous journalisez et corrélez.

Le sujet rejoint celui de l’injection de prompt dans les assistants IA internes : dans les deux cas, la faille n’est pas dans le modèle mais dans le périmètre qu’on lui a confié.

Durcir vos garde-fous IA : cinq mesures concrètes

Réduire la fuite ne consiste pas à ajouter des filtres, mais à rendre les garde-fous IA moins bavards et l’accès plus strict.

• Uniformiser les refus. Un seul message générique pour tous les cas de blocage. Jamais de motif, jamais de mention du document ou de la règle déclenchée.
• Supprimer la distinction « existe mais interdit » / « n’existe pas ». Les deux doivent produire la même réponse, mot pour mot.
• Filtrer en amont, pas dans le prompt. L’assistant ne doit indexer que les documents autorisés à l’utilisateur qui pose la question. Un filtrage post-génération arrive trop tard.
• Journaliser le taux de refus par utilisateur. Un pic de blocages sur un même compte en quelques minutes est un signal de reconnaissance, au même titre qu’un scan de ports. Cette télémétrie doit remonter dans le SOC.
• Limiter le débit et tester régulièrement. Le sondage exige du volume : un plafond de requêtes par utilisateur casse l’attaque. Complétez par un test d’intrusion applicatif ciblé sur l’assistant.

Ces contrôles supposent une visibilité côté détection. C’est exactement le rôle d’un SOC capable de trier le signal IA sans se noyer dans le bruit : sans corrélation, une campagne de sondage reste invisible.

Et si vous hébergez le modèle vous-même ?

L’auto-hébergement ne supprime pas le problème, il le déplace. Vous contrôlez les journaux et les filtres, mais vous héritez aussi de la sécurité de l’inférence — un sujet que nous avons traité côté empoisonnement des modèles IA locaux. Dans les deux cas, la règle tient en une phrase : l’assistant ne doit jamais pouvoir lire ce que son interlocuteur n’a pas le droit de lire.

Ce qu’il faut retenir

Un garde-fou IA n’est pas un mur, c’est un indicateur. Il signale à l’attaquant qu’il approche de quelque chose de sensible, et la granularité de ce signal détermine la vitesse à laquelle il cartographie votre système. La bonne posture n’est pas de refuser plus, mais de refuser de la même façon, en journalisant tout et en donnant à l’assistant le strict minimum d’accès. Chez ucyber.ai, nous auditons ces déploiements avec une approche Agentic SOC : la détection du sondage vaut mieux que la promesse d’un filtre parfait.

Sources

• Cisco Talos — « Sorry, I can’t help with that » : how your guardrails might become the attacker’s best friend
• The Hacker News — Amazon Kiro prompt injection can exfiltrate sensitive data
• Dark Reading — Agentic AI risks permeate Black Hat USA 2026

Ce que change une faille Avada WordPress exploitable sans clic

La qualification zero-click est la donnée déterminante. La plupart des vulnérabilités WordPress exigent qu’un administrateur soit authentifié, ou qu’un utilisateur clique sur un lien piégé. Ici, l’attaquant envoie directement une requête au site et obtient l’exécution de code sur l’hébergement. Il n’y a ni phishing à réussir, ni utilisateur à tromper.

Concrètement, cela signifie que l’exploitation est automatisable à grande échelle. Les campagnes de masse qui ciblent WordPress fonctionnent toujours de la même façon : un scanner parcourt Internet à la recherche de la signature du thème vulnérable, puis déclenche l’exploit sur tout ce qui répond. Aucun ciblage, aucune sélection. Votre site n’a pas besoin d’être intéressant pour être compromis, il lui suffit d’être joignable.

Pourquoi les thèmes sont un angle mort

Les équipes qui gèrent un site WordPress surveillent généralement le cœur du CMS et les extensions. Le thème, lui, est souvent installé une fois lors de la refonte, puis oublié pendant des années. Trois facteurs aggravent le risque :

• Licence expirée : un thème premium acheté une fois ne reçoit plus les mises à jour automatiques si la clé n’est pas renouvelée. Le site reste fonctionnel, mais il ne se corrige plus.
• Thèmes enfants et versions figées : les personnalisations lourdes dissuadent de mettre à jour, par crainte de casser le design.
• Responsabilité diluée : l’agence a livré le site, l’hébergeur gère le serveur, et personne ne se considère propriétaire du patch applicatif.

Évaluer son exposition à la faille Avada WordPress

La première étape est un inventaire honnête. Beaucoup d’organisations découvrent à cette occasion des sites oubliés : ancienne landing page de campagne, site d’une filiale, environnement de préproduction resté en ligne.

• Recensez tous vos sites WordPress, y compris ceux hébergés hors du contrat principal, et notez pour chacun le thème actif et sa version.
• Vérifiez la version d’Avada depuis l’administration, ou en ligne de commande si vous disposez de WP-CLI, ce qui est bien plus fiable sur un parc de plusieurs sites.
• Contrôlez la date du dernier déploiement : un site qui n’a reçu aucune mise à jour depuis six mois doit être traité comme potentiellement déjà compromis, pas seulement comme vulnérable.

Chercher les traces d’une compromission déjà effective

Sur une faille exploitée de façon automatisée, le patch seul ne suffit pas : si le site a été atteint avant votre intervention, corriger le thème ne retire pas la porte dérobée. Recherchez donc les indicateurs classiques d’un webshell : fichiers PHP récents dans les répertoires d’upload, comptes administrateurs créés hors de vos processus, tâches planifiées WordPress inconnues, et modifications de fichiers non expliquées par un déploiement.

Un contrôle d’intégrité de fichiers, tel que celui que nous déployons dans nos supervisions, transforme cette recherche manuelle en alerte automatique — c’est exactement la logique que nous décrivons pour les scripts tiers de la supply chain web.

Corriger et durcir durablement

La remédiation immédiate tient en une action : appliquer la version corrigée d’Avada publiée par l’éditeur, sur tous les sites concernés, sans attendre la prochaine fenêtre de maintenance. Une faille zero-click avec exploitation de masse ne laisse pas le temps d’un cycle de validation classique.

Au-delà du correctif, quatre mesures réduisent structurellement la surface d’attaque :

• Automatiser les mises à jour du cœur, des extensions et des thèmes, avec un environnement de recette pour les sites à forte personnalisation.
• Placer un WAF devant le site : il ne remplace pas le patch, mais il absorbe les vagues de scan automatisé pendant le délai de déploiement.
• Réduire les privilèges d’écriture du compte serveur web sur les répertoires de code : un exploit qui ne peut pas écrire de fichier PHP perd l’essentiel de sa persistance.
• Sauvegarder hors ligne et tester la restauration, afin de pouvoir reconstruire proprement plutôt que de nettoyer un site douteux.

Cette discipline vaut bien au-delà de WordPress : elle rejoint les réflexes que nous recommandons sur la gestion des accès et des secrets, comme dans notre article sur les clés AWS exposées.

Le site vitrine fait partie du périmètre de sécurité

La faille Avada WordPress rappelle une réalité que beaucoup de directions sous-estiment : le site public n’est pas un support marketing isolé, c’est un serveur applicatif exposé en permanence, souvent hébergé à proximité d’autres ressources. Un thème non corrigé y devient un point d’entrée aussi sérieux qu’un VPN mal configuré. L’intégrer à l’inventaire, au suivi des vulnérabilités et à la supervision est le meilleur moyen d’éviter qu’une vulnérabilité de thème ne se transforme en incident majeur.

Sources

• BleepingComputer — Critical Avada WordPress theme flaw enables zero-click RCE