La faille Veeam Agent qui transforme un simple utilisateur en administrateur SYSTEM
Autant te le dire tout de suite : la faille Veeam Agent dont tout le monde parle depuis le 14 septembre, je l’ai vue arriver de loin. Un pote admin sys m’a envoyé le lien Korben un dimanche matin, café à la main, avec ce petit sourire narquois qu’on réserve aux collègues qui gèrent du Veeam. CVE-2026-32996. Un utilisateur local lambda, sans aucun droit, qui se retrouve avec un shell SYSTEM en quelques minutes. Rien que ça.
Je ne suis pas certain à 100% du détail exact de la chaîne d’exploitation, mais d’après mon expérience en atelier, ce genre de faille touche presque toujours un service qui tourne en SYSTEM et qui accepte un chemin d’exécutable ou un pipe nommé sans vérifier qui lui parle. Et là, c’est confirmé par Arctic Wolf : des attaques sont déjà en cours. Pas dans six mois. Maintenant.
La semaine dernière, un client m’appelle, paniqué. Il a douze serveurs Windows qui font tourner Veeam Agent 13.0.2 pour balancer leurs sauvegardes vers un NAS Synology. Il me dit : « Marc, j’ai vu un truc passer sur Twitter, on est concernés ? » Je lui réponds : « Tu as un compte local en plus de ton admin domaine ? » Silence. « Bah oui, on a un compte service pour les sauvegardes. » Voilà. C’est exactement ce profil qui se fait plier en deux.
Ce que fait vraiment cette faille Veeam Agent (et pourquoi les experts sont trop zen)
Le pitch est simple, brutal, efficace. Un attaquant qui a déjà un pied dans la machine — via un phishing, un RDP mal fermé, un poste de stagiaire — n’a plus besoin de chercher une élévation de privilèges compliquée. Il exploite directement l’agent Veeam pour passer en SYSTEM. Du coup, il peut faire ce qu’il veut : lire les sauvegardes, les chiffrer, désactiver les services de sécurité, poser un ransomware qui va attaquer le serveur de backup. La totale.
Et là je vais être franc et peut-être pas d’accord avec certains confrères qui minimisent : « oui mais il faut déjà un accès local ». Faux débat. Dans 90% des PME que je dépanne, un accès local, ça s’obtient en dix minutes. Un poste partagé en atelier, un compte « invite » oublié, un ancien stagiaire qui a gardé son mot de passe. Le « prérequis » n’est pas un prérequis, c’est une formalité. Autant dire que cette faille Veeam Agent est une porte grande ouverte avec un paillasson « bienvenue » dessus.
- Branche affectée : Veeam Agent pour Windows 13, jusqu’au build 13.0.2.1102 inclus.
- Correctif disponible depuis le 27 mai 2026 dans le build 13.0.3.1220.
- Exploit public circulant depuis le 14 septembre.
- Attaques actives signalées par Arctic Wolf.
- Impact : passage d’un utilisateur local non privilégié au compte SYSTEM.
Pourquoi la mise à jour auto ne te sauvera pas
Mine de rien, c’est le point qui énerve le plus dans l’histoire. Veeam a patché le 27 mai. Trois mois et demi avant que l’exploit public ne tombe. Sur le papier, c’est propre. Sauf que la mise à jour automatique de l’agent ne pousse pas forcément la dernière version. Je l’ai vérifié sur trois parcs clients différents : deux d’entre eux étaient bloqués sur la 13.0.1, un autre sur la 13.0.2.1102 pile. La version vulnérable. Celle qui se fait ouvrir en grand.
Pour être honnête, je pense que Veeam gère mal ce canal de mise à jour depuis des années. Ils préfèrent que tu passes par Veeam Backup & Replication pour orchestrer les upgrades. Sauf que les TPE et petites PME qui utilisent l’agent standalone, elles, ne voient jamais la nouvelle version. Résultat : des milliers de machines exposées alors que le correctif existe depuis mai. C’est rageant.
Comment vérifier ton build en 30 secondes (et pourquoi tu vas détester le résultat)
Ouvre l’agent. Menu « About ». Regarde le numéro de build. Si tu vois 13.0.2.1102 ou moins, arrête tout ce que tu fais et va télécharger la 13.0.3.1220 sur le site de Veeam. Pas via l’updater intégré qui va te dire « tout est à jour, dormez tranquille ». Non. Manuellement.
J’ai eu le cas inverse la semaine dernière, tiens. Un serveur qui m’affichait fièrement « 13.0.3.1220 » mais dont l’exécutable principal était resté en cache sur une vieille version. Du coup, un redémarrage du service et le build affiché était redescendu. Autant dire que la vérification du numéro de version n’est pas une science exacte. Vérifie aussi la date du fichier .exe dans Program Files, histoire de ne pas te faire avoir par une mise à jour fantôme.
- Ouvrir Veeam Agent pour Windows.
- Cliquer sur le menu « About » (icône « ? » en haut à droite).
- Relever le numéro de build affiché.
- Si build < 13.0.3.1220 : télécharger manuellement l’installateur.
- Redémarrer le service Veeam Agent après installation.
Le correctif ne suffit pas, il faut aussi fermer la porte derrière
Installer la 13.0.3.1220, c’est la base. Mais si tu laisses traîner des comptes locaux avec des droits d’écriture sur le dossier d’installation Veeam, tu n’as rien réglé. Le vrai travail, celui que personne ne veut faire, c’est de nettoyer les ACL, supprimer les comptes de service inutiles, et vérifier qui a le droit de parler aux pipes nommés de l’agent. Je ne suis pas certain que tous les admins pensent à ce niveau de détail, mais dans mon expérience, c’est là que se joue la différence entre « patché » et « sécurisé ».
Mon avis tranché : Veeam doit revoir son canal de mise à jour
Je vais dire ce que pas mal de techniciens pensent tout bas : Veeam fait d’excellents produits, mais leur gestion des mises à jour d’agent est une catastrophe silencieuse. On parle d’une faille qui donne SYSTEM. SYSTEM. Pas « un peu plus de droits ». Pas « lecture sur un dossier partagé ». SYSTEM, le compte le plus puissant de la machine. Et on laisse les utilisateurs découvrir par eux-mêmes qu’ils doivent aller vérifier leur build à la main ?
Pour être honnête, je pense qu’ils devraient forcer une notification bloquante dans l’interface tant que le build n’est pas à jour. Pas un petit bandeau discret qu’on ferme sans lire. Quelque chose qui empêche de lancer une sauvegarde tant que le correctif critique n’est pas appliqué. Radikal ? Peut-être. Efficace ? Certainement. Mais je ne suis pas certain qu’ils oseront, parce que ça veut dire assumer que leur updater ne fait pas le job.
Arctic Wolf a raison de tirer la sonnette. Mais les éditeurs ont aussi une responsabilité. Pousser une mise à jour qui reste dans un coin sans jamais s’installer, ce n’est pas de la sécurité, c’est de la décoration.
Ce que je fais concrètement chez mes clients cette semaine
J’ai bloqué deux jours dans mon planning pour un audit Veeam. Concrètement : je liste tous les agents 13.x du parc, je relève les builds, je pousse la 13.0.3.1220 manuellement via un script PowerShell, et je vérifie les ACL du dossier d’install. Rien de magique. Juste du travail de fourmi que personne n’aime faire mais qui évite de se retrouver avec un ransomware qui remonte la chaîne jusqu’au serveur de backup.
Si tu gères un parc avec Veeam Agent, fais pareil. Aujourd’hui. Pas vendredi. Pas « quand j’aurai le temps ». La faille Veeam Agent est dans la nature, l’exploit est public, et les attaquants ne prennent pas de rendez-vous. Du coup, un petit inventaire, un déploiement manuel, un check des permissions, et tu dors mieux ce soir.
Et si tu tombes sur un build bizarre que tu n’arrives pas à identifier, écris-moi. J’ai vu tellement de versions exotiques ces dernières années que je commence à avoir un petit musée personnel.
Pour aller plus loin sur cette faille Veeam Agent
La source d’origine de mon analyse, c’est l’article de Korben qui a relayé le scoop : Veeam Agent pour Windows – Une faille qui donne les droits SYSTEM. Tu y trouveras les liens vers l’avis Arctic Wolf et les références CVE. À lire, à relayer à ton admin sys préféré, et à garder sous le coude pour la prochaine réunion sécurité où quelqu’un te dira « mais Veeam, c’est safe ».
Un dernier conseil, et c’est du vécu : avant de crier au loup, sauvegarde ta base de données de configuration Veeam. Parce que si tu casses l’agent en voulant le patcher trop vite, tu vas passer une sale soirée. Mine de rien, ça m’est arrivé l’année dernière sur un serveur de production. Une anecdote que je garde pour un prochain article.
Source : article original
