Veeam : une RCE critique permet aux Domain Users d’exécuter du code

Une vulnérabilité critique affecte Veeam Backup & Replication et permet à un utilisateur authentifié du domaine, membre du groupe Domain Users, de déclencher une exécution de code à distance sur le serveur de sauvegarde. L’information a été relayée publiquement par The Hacker News, sur la base de la communication de l’éditeur. Le point le plus important, pour les équipes d’exploitation et de sécurité, est le suivant : il ne s’agit pas d’une faille “authentifiée” anodine. Dans de nombreux environnements Active Directory, les comptes disposant de cette appartenance sont très nombreux, parfois quasi omniprésents. Lorsqu’un serveur de sauvegarde est exposé à un tel niveau de confiance implicite, la faille devient immédiatement prioritaire.

À ce stade, la communication publique disponible indique qu’un correctif de sécurité a été publié par Veeam dans la vague de mises à jour de juin 2026. Les détails techniques complets, notamment le CVE-ID et le score CVSS, ne sont pas confirmés dans les éléments fournis ici. Il convient donc de s’en tenir strictement aux faits établis : les versions de Veeam Backup & Replication antérieures au correctif de juin 2026 sont concernées, et une mise à jour officielle est disponible.

L’enjeu dépasse largement l’exécution de code sur un serveur applicatif classique. Un serveur Veeam concentre des informations sensibles sur l’infrastructure, les dépôts de sauvegarde, les identifiants de services, les tâches planifiées, les proxys, les repositories, parfois les connecteurs cloud, et surtout la capacité opérationnelle de restauration après incident. Une compromission à ce niveau peut rapidement se transformer en scénario de sabotage de la résilience : effacement ou chiffrement de sauvegardes, altération des chaînes de restauration, mouvement latéral vers les hôtes protégés, ou préparation d’une attaque plus large contre l’Active Directory.

Pour les entreprises françaises, ce type d’alerte doit être lu à la lumière des recommandations récurrentes du CERT-FR sur la protection des briques d’administration, de sauvegarde et de reprise. Les hébergements hybrides ou externalisés chez OVHcloud, Scaleway, o2switch ou d’autres prestataires n’annulent en rien le risque : dès lors qu’un serveur Veeam est joint au domaine ou accessible depuis des segments internes compromis, la surface d’attaque reste significative.

Versions affectées

Les informations publiques disponibles dans le cadre de cette alerte permettent d’établir les éléments suivants :

Produit concerné : Veeam Backup & Replication
Versions affectées : versions antérieures au correctif de sécurité publié par Veeam en juin 2026
Version corrigée : version corrigée publiée par l’éditeur dans sa vague de sécurité de juin 2026
Condition d’exploitation : l’attaquant doit disposer d’un compte authentifié du domaine, avec une appartenance de type Domain Users
Nature de l’impact : RCE sur le serveur Veeam

En l’absence, dans les éléments fournis, d’un numéro de version exact et vérifié pour chaque branche corrigée, il est préférable de ne pas publier de valeur potentiellement erronée. Les équipes doivent donc se référer à l’advisory officiel de Veeam pour identifier précisément la version cible à déployer dans leur environnement.

Ce point est important sur le plan opérationnel : les environnements Veeam en production ne sont pas homogènes. On rencontre fréquemment des installations avec console, serveur de sauvegarde, proxys, composants de transport, repositories Windows ou Linux, intégrations hyperviseur, et parfois des dépendances à des versions spécifiques du système d’exploitation ou de SQL Server. Une lecture attentive de l’avis de sécurité de l’éditeur est donc indispensable avant toute mise à niveau.

Si votre inventaire ne permet pas d’identifier rapidement les instances vulnérables, commencez par recenser :

les serveurs portant le rôle Veeam Backup Server ;
les consoles d’administration installées sur des postes d’exploitation ;
les proxys et repositories associés ;
les serveurs joints au domaine disposant de services Veeam actifs ;
les hôtes de secours ou de PRA contenant une instance secondaire de la plateforme.

Sur Windows, un premier niveau de vérification peut passer par les services installés et les répertoires applicatifs. Par exemple :

Get-Service *Veeam* Get-Item "C:\Program Files\Veeam\Backup and Replication\*" Get-ChildItem "C:\Program Files\Veeam\Backup and Replication" -ErrorAction SilentlyContinue

Ces commandes n’indiquent pas à elles seules si l’instance est vulnérable, mais elles permettent d’identifier rapidement les systèmes à auditer. La confirmation de version doit ensuite être faite via l’interface produit, l’inventaire logiciel, ou les mécanismes de gestion de parc déjà en place.

Vecteur d’attaque

Le vecteur décrit publiquement est particulièrement notable : un utilisateur authentifié du domaine peut parvenir à exécuter du code à distance sur le serveur Veeam. Ce point change fortement l’évaluation du risque par rapport à une faille nécessitant un rôle d’administration applicative, un accès local privilégié ou une exposition Internet directe.

Dans un environnement Active Directory classique, le groupe Domain Users constitue souvent le socle d’appartenance par défaut des comptes de nombreux salariés, prestataires ou comptes techniques. Cela signifie qu’une compromission initiale relativement banale — vol de mot de passe, hameçonnage, réutilisation d’identifiants, poste utilisateur déjà infecté — peut suffire à fournir le prérequis d’authentification nécessaire à l’exploitation.

Autrement dit, même si la faille n’est pas “anonyme”, elle reste hautement exploitable dans une entreprise réelle. Les attaquants n’ont pas besoin de viser directement le serveur de sauvegarde depuis Internet. Ils peuvent d’abord compromettre un compte de faible privilège, prendre pied sur le réseau interne, puis utiliser ce compte pour atteindre la brique Veeam.

Le risque est encore plus élevé lorsque les pratiques suivantes sont présentes :

serveur Veeam joint au domaine sans segmentation réseau stricte ;
accès aux services Veeam autorisé depuis de larges segments utilisateurs ;
comptes de service surdimensionnés ou réutilisés ;
absence de bastion pour l’administration ;
surveillance incomplète des appels réseau et des journaux applicatifs ;
plateforme de sauvegarde considérée comme “interne donc sûre”.

Sur le plan technique, l’advisory public mis en avant indique une capacité d’exécution de code à distance après authentification. Sans détail officiel complet sur la primitive exacte, il faut éviter toute spéculation excessive. En revanche, les conséquences pratiques sont connues et suffisamment sérieuses pour justifier un traitement immédiat.

Pourquoi une RCE sur un serveur de sauvegarde est stratégique pour un attaquant

Un serveur de sauvegarde n’est pas un serveur comme les autres. Il est souvent au cœur des opérations de continuité et de reprise. Il sait quels hôtes existent, où résident les données, quelles machines sont protégées, quels comptes sont utilisés pour les collectes, et où sont stockées les copies. Une prise de contrôle de cette brique peut offrir à l’attaquant plusieurs leviers simultanés :

accès à l’inventaire de l’infrastructure via les jobs, repositories et composants enregistrés ;
accès aux sauvegardes elles-mêmes ou à leurs métadonnées ;
capacité de sabotage des tâches planifiées de protection ;
préparation du mouvement latéral vers hyperviseurs, serveurs applicatifs, NAS, stockages ou comptes de service ;
affaiblissement de la réponse à incident en rendant la restauration plus difficile, plus lente ou impossible.

Dans les campagnes de rançongiciel observées ces dernières années, les sauvegardes sont fréquemment une cible prioritaire. Les attaquants cherchent à réduire la capacité de l’entreprise à restaurer rapidement ses systèmes, afin d’augmenter la pression opérationnelle. Une RCE sur Veeam s’inscrit donc dans une logique de chaîne d’attaque plus large : compromission initiale, élévation de capacité, neutralisation des moyens de reprise, puis impact final.

Scénario d’attaque concret en environnement d’entreprise

Un scénario réaliste, cohérent avec les faits publics, peut être résumé ainsi :

un poste utilisateur est compromis via phishing ou malware ;
l’attaquant récupère les identifiants d’un compte de domaine standard ;
ce compte, membre de Domain Users, peut s’authentifier dans le périmètre interne ;
le serveur Veeam Backup & Replication est accessible sur le réseau ;
la vulnérabilité est exploitée pour obtenir une exécution de code à distance ;
l’attaquant explore ensuite les jobs, dépôts, identifiants et relations de confiance ;
il peut tenter de désactiver des tâches, supprimer des points de restauration, ou préparer un mouvement latéral vers d’autres systèmes critiques.

Ce qui rend cette séquence préoccupante, c’est l’écart entre le niveau du compte initial et la sensibilité de la cible finale. Une simple appartenance standard au domaine ne devrait jamais permettre de menacer directement la plateforme de sauvegarde. Or c’est précisément cette rupture de cloisonnement qui rend la faille prioritaire.

Impact métier et sécurité

L’impact potentiel n’est pas limité à la confidentialité ou à l’intégrité du serveur lui-même. Il touche aussi la résilience opérationnelle de l’organisation. Parmi les conséquences possibles :

prise de contrôle du serveur de sauvegarde ;
altération ou interruption des sauvegardes ;
accès à des informations d’architecture sensibles ;
compromission de comptes ou secrets accessibles par la plateforme ;
mouvement latéral vers les systèmes protégés ;
affaiblissement des capacités de reprise après incident ;
augmentation du coût et du délai de remédiation lors d’une attaque en cours.

Pour un RSSI, cela signifie que la priorisation ne doit pas être faite uniquement sur le critère “authentifié ou non”. Il faut intégrer la surface réelle des comptes disposant du prérequis, la criticité de l’actif ciblé, et le rôle du système dans la continuité d’activité. Sur ces trois axes, un serveur Veeam est un actif à très forte valeur.

Comment patcher

La recommandation principale est simple : déployer immédiatement la mise à jour de sécurité publiée par Veeam en juin 2026 sur toutes les instances concernées de Veeam Backup & Replication. Les détails précis de version doivent être pris dans l’advisory officiel de l’éditeur, seule source de référence pour la branche corrigée adaptée à votre environnement.

Contrairement à des composants open source distribués via apt, dnf ou composer, Veeam Backup & Replication est généralement mis à jour via les mécanismes fournis par l’éditeur, l’interface d’installation Windows, ou des packages téléchargés depuis le portail officiel. Il ne serait pas exact de publier ici une commande de mise à jour générique non confirmée.

En pratique, la remédiation doit suivre une séquence maîtrisée :

identifier toutes les instances Veeam Backup & Replication ;
vérifier la version actuellement déployée ;
télécharger la mise à jour de sécurité officielle depuis Veeam ;
planifier une fenêtre de maintenance adaptée ;
appliquer le correctif sur le serveur principal puis sur les composants associés si requis par l’éditeur ;
redémarrer les services concernés si demandé ;
vérifier le retour à l’état nominal des jobs, proxys et repositories ;
contrôler les journaux pour détecter toute anomalie antérieure ou postérieure au patch.

Points de contrôle avant mise à jour

Avant l’application du correctif, il est prudent de sécuriser les éléments suivants :

export de la configuration si cette procédure fait partie de votre standard d’exploitation ;
sauvegarde des journaux applicatifs et système pour analyse ultérieure ;
inventaire des comptes de service et des dépendances ;
validation de l’espace disque disponible et de la santé de la base associée ;
information des équipes PRA et exploitation en cas d’arrêt temporaire des tâches.

Dans les environnements sensibles, il peut être utile d’exécuter quelques vérifications de base avant et après intervention. Sous Windows, par exemple :

Get-Service *Veeam* Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object { $_.ProviderName -match "Veeam" } Get-WinEvent -LogName System -MaxEvents 200 | Where-Object { $_.Message -match "Veeam" }

Ces commandes servent à l’observation opérationnelle, pas à confirmer l’absence de compromission. Elles permettent toutefois de repérer rapidement un service arrêté, un échec de démarrage ou un événement applicatif inhabituel après mise à jour.

Vérification post-correctif

Une fois la version corrigée déployée, il faut vérifier plusieurs points :

la version affichée correspond bien à celle publiée par l’éditeur comme corrigée ;
les services Veeam essentiels sont démarrés ;
les jobs de sauvegarde, réplication et restauration de test fonctionnent normalement ;
les repositories restent accessibles ;
aucune erreur inhabituelle n’apparaît dans les journaux Windows ou applicatifs ;
les accès réseau vers l’instance sont cohérents avec votre politique de segmentation.

Si vous exploitez plusieurs sites, PRA ou tenants internes, le traitement doit être mené de façon coordonnée. Une seule instance oubliée peut rester un point d’entrée critique dans le SI.

Mitigation

Lorsque le correctif ne peut pas être appliqué immédiatement, des mesures compensatoires peuvent réduire le risque, sans toutefois remplacer le patch. Dans ce cas précis, la priorité est de réduire drastiquement l’exposition du serveur Veeam aux comptes de domaine standard et de restreindre les chemins réseau permettant l’exploitation.

Réduction de la surface d’accès

limiter l’accès réseau au serveur Veeam Backup & Replication aux seuls segments d’administration et composants nécessaires ;
bloquer les accès depuis les VLAN utilisateurs standards ;
imposer un bastion d’administration plutôt qu’un accès direct ;
réévaluer les groupes AD autorisés à interagir avec la plateforme ;
restreindre les ouvertures de ports au strict besoin fonctionnel.

Dans un grand nombre d’environnements, le simple fait qu’un compte utilisateur standard puisse joindre le serveur de sauvegarde constitue déjà une faiblesse d’architecture. Cette alerte doit donc être l’occasion de revoir le cloisonnement entre postes bureautiques, serveurs d’infrastructure et composants de sauvegarde.

Durcissement des comptes et de l’authentification

désactiver ou réinitialiser rapidement les comptes suspects ;
surveiller les connexions de comptes Domain Users vers les serveurs Veeam ;
renforcer l’hygiène des mots de passe et la MFA là où elle s’applique ;
réduire l’usage des comptes de service trop privilégiés ;
séparer les comptes d’administration de sauvegarde des comptes bureautiques courants.

Une faille authentifiée devient beaucoup plus difficile à exploiter lorsque l’environnement applique réellement la séparation des usages, des comptes et des segments réseau. À l’inverse, dans un SI plat où les postes utilisateurs peuvent joindre librement les serveurs d’infrastructure, la distinction entre “authentifié” et “non authentifié” perd une grande partie de sa valeur pratique.

Protection des sauvegardes elles-mêmes

Même si le correctif vise le serveur Veeam, il est essentiel de vérifier les mécanismes de défense autour des sauvegardes :

présence de copies hors ligne, immuables ou isolées ;
séparation des plans de contrôle et des stockages ;
droits minimaux sur les repositories ;
tests réguliers de restauration ;
surveillance des suppressions, modifications ou arrêts de jobs.

Cette approche est particulièrement importante pour les organisations qui s’appuient sur des stockages externalisés, des clouds publics ou des sites distants. Le correctif règle la vulnérabilité logicielle, mais la résilience globale dépend aussi de l’architecture de sauvegarde et de la capacité à restaurer malgré la compromission d’un composant central.

Détection

En l’absence d’IoC exhaustifs publiés dans les éléments disponibles, la détection doit reposer sur une combinaison d’indices faibles autour de l’authentification, de l’activité applicative et de l’administration inhabituelle du serveur Veeam. Il faut rechercher tout comportement anormal impliquant des comptes de domaine standards interagissant avec cette brique.

IoC et signaux faibles à surveiller

connexions réseau inhabituelles vers le serveur Veeam depuis des postes utilisateurs ;
authentifications réussies de comptes non administratifs sur le serveur ;
création ou exécution de processus inattendus sur l’hôte Veeam ;
arrêt ou redémarrage anormal de services Veeam ;
modifications non planifiées des jobs, repositories ou paramètres d’infrastructure ;
échecs ou suppressions soudaines de points de restauration ;
événements Windows révélant une exécution de commandes ou scripts hors procédure ;
mouvements latéraux depuis le serveur Veeam vers d’autres actifs sensibles après une connexion suspecte.

Sur Windows, les équipes SOC et administration peuvent corréler plusieurs sources : journaux de sécurité, journaux applicatifs, solutions EDR, pare-feu internes, et traces de l’outillage Veeam lui-même. Une attention particulière doit être portée aux événements de connexion et de création de processus.

Exemples de vérifications locales utiles :

Get-WinEvent -LogName Security -MaxEvents 500 Get-WinEvent -LogName Application -MaxEvents 500 | Where-Object { $_.ProviderName -match "Veeam" } Get-Process | Sort-Object ProcessName netstat -ano

L’objectif n’est pas de publier une signature universelle, mais de fournir des axes de chasse. Si un compte bureautique standard apparaît dans des journaux d’accès à un serveur de sauvegarde, cela mérite une investigation immédiate, surtout si l’activité coïncide avec des changements de configuration, des erreurs de jobs ou des exécutions de processus inattendus.

Questions d’investigation prioritaires

Quels comptes de domaine se sont authentifiés récemment sur le serveur Veeam ?
Ces comptes faisaient-ils partie des usages normaux d’exploitation ?
Des processus non habituels ont-ils été lancés dans la même fenêtre temporelle ?
Des modifications de configuration Veeam ont-elles eu lieu sans changement déclaré ?
Des sauvegardes ont-elles été supprimées, interrompues ou rendues indisponibles ?
Le serveur Veeam a-t-il initié des connexions anormales vers d’autres systèmes après l’événement suspect ?

Si des indices convergent, il faut traiter le serveur comme potentiellement compromis, isoler la machine selon vos procédures, préserver les journaux, réinitialiser les secrets exposés et vérifier l’intégrité des sauvegardes disponibles avant toute remise en service complète.

Perspective écosystème et priorisation du risque

Cette vulnérabilité rappelle une réalité souvent sous-estimée : les composants de sauvegarde sont des cibles de premier plan pour les attaquants. Ils ne sont pas seulement des outils d’exploitation, mais des actifs de sécurité et de résilience. Une faille touchant cette couche doit donc être priorisée à un niveau comparable à celui d’un contrôleur d’infrastructure, d’un bastion ou d’une plateforme de virtualisation.

Le qualificatif “authentifiée” peut parfois conduire à une sous-priorisation, en particulier lorsque les équipes de patch management appliquent des grilles simplifiées. Or, dans un domaine Active Directory, la population de comptes authentifiés est souvent vaste. Cela réduit fortement la portée protectrice du prérequis. Une faille exploitable par un simple Domain Users ne doit pas être lue comme une vulnérabilité de second plan.

Il faut aussi considérer le contexte opérationnel : Veeam Backup & Replication est fréquemment déployé dans des environnements virtualisés, hybrides ou multi-sites. Une compromission peut donc avoir des effets en cascade sur des périmètres très différents : VMware, Hyper-V, serveurs physiques, NAS, dépôts Linux durcis, stockages objet, ou environnements de reprise externalisés. La criticité vient autant de la centralité du produit que de la diversité de ses intégrations.

Pour les organisations françaises, cette alerte est aussi un rappel utile sur la nécessité de documenter les dépendances d’administration et de sauvegarde, de tester les scénarios de restauration dégradée, et de cloisonner les accès. Les bonnes pratiques de durcissement, de segmentation et de surveillance restent déterminantes, y compris après application du correctif. Sur ce sujet, les équipes peuvent utilement compléter leur démarche avec les contenus de la catégorie /categorie/pratiques, notamment pour le hardening des serveurs critiques et la réduction de surface d’attaque.

Source originale à consulter : la communication de Veeam sur sa mise à jour de sécurité de juin 2026, relayée par The Hacker News dans l’article consacré à cette RCE affectant Veeam Backup & Replication. Tant que l’éditeur n’a pas publié davantage de détails consolidés dans l’advisory, il faut éviter les extrapolations et se concentrer sur les actions vérifiables : inventorier, patcher, segmenter, surveiller, tester la restauration.

En pratique, toute instance Veeam Backup & Replication non encore mise à jour doit être considérée comme prioritaire, en particulier si elle est jointe au domaine et accessible depuis des segments internes étendus. Le bon réflexe n’est pas seulement d’appliquer le correctif, mais aussi de vérifier si un compte standard du domaine aurait pu atteindre ce serveur, et si vos sauvegardes restent réellement restaurables en cas d’incident majeur. Pour renforcer durablement cette posture, un détour par les guides de durcissement et d’exploitation sécurisée de la catégorie /categorie/pratiques est pertinent.

Serveurs

Retour aux actualités