Veeam CVE-2026-44963 : n'importe quel compte de domaine peut prendre le contrôle de vos sauvegardes

La CVE-2026-44963 (CVSS 9.4) permet à tout utilisateur de domaine authentifié d'exécuter du code à distance sur un serveur Veeam Backup & Replication joint au domaine. Comme les sauvegardes sont la cible privilégiée des ransomwares, cette faille mérite un traitement prioritaire. Analyse, périmètre et durcissement.

Le 9 juin 2026, Veeam a publié un correctif (KB4830) pour une vulnérabilité critique de son produit phare, Veeam Backup & Replication (VBR). La CVE-2026-44963, notée CVSS 9.4, permet à n'importe quel utilisateur de domaine authentifié d'exécuter du code à distance sur le serveur de sauvegarde. Pas besoin d'être administrateur, ni d'avoir un rôle Veeam : un simple compte du domaine Active Directory suffit.

Pour comprendre pourquoi cette faille est plus grave que son score ne le laisse deviner, il faut se rappeler une réalité du paysage des menaces : les serveurs de sauvegarde sont la cible numéro un des opérateurs de ransomware. Détruire ou chiffrer les backups avant de déclencher le chiffrement principal, c'est garantir que la victime n'aura d'autre choix que de payer. Une RCE sur le serveur Veeam, c'est exactement la clé que ces acteurs recherchent.

La faille : une barrière de privilège anormalement basse

Le point qui doit alerter, c'est le niveau de privilège requis. La plupart des RCE critiques exigent au minimum des droits élevés ou une chaîne d'exploitation. Ici, tout compte de domaine valide — y compris le plus banal des comptes utilisateur — peut déclencher l'exécution de code sur le serveur de sauvegarde. Dans un environnement d'entreprise typique, cela signifie que la compromission d'un seul poste de travail, ou un compte aux identifiants faibles, ouvre directement la voie vers l'infrastructure de backup.

La faille a été rapportée par Sina Kheirkhah (@SinSinology) de l'équipe watchTowr, chercheur déjà à l'origine de plusieurs découvertes notables dans des produits d'infrastructure. À la date de divulgation, aucune exploitation en conditions réelles n'était documentée — mais l'historique invite à la prudence : quatre vulnérabilités Veeam figurent déjà au catalogue KEV de la CISA, toutes ayant été abusées par des gangs de ransomware. Le délai entre divulgation et exploitation de masse, pour ce type de produit, se compte généralement en jours ou semaines.

Périmètre : seuls les serveurs joints au domaine sont affectés

C'est la nuance déterminante, et aussi la piste de durcissement la plus importante. La CVE-2026-44963 ne touche que les serveurs Veeam joints à un domaine Active Directory. Les serveurs configurés en workgroup (groupe de travail, hors domaine) ne sont pas concernés par ce vecteur, puisque la notion d'« utilisateur de domaine authentifié » n'existe pas pour eux.

Côté versions :

  • Affectés : VBR 12.3.2.4465 et toutes les versions v12 antérieures.
  • Corrigé dans : la version 12.3.2.4854.
  • Non affecté : la branche v13.x, dont les changements d'architecture suppriment ce vecteur.

Pourquoi les sauvegardes méritent un traitement à part

Il y a une ironie cruelle à voir le système censé garantir la résilience devenir lui-même un point de défaillance unique. La stratégie de sauvegarde 3-2-1 — trois copies, deux supports, une hors site — que je détaille dans mon guide des stratégies de sauvegarde Linux, repose sur l'hypothèse que l'attaquant ne peut pas atteindre toutes les copies d'un coup. Une RCE sur le serveur d'orchestration des sauvegardes met justement cette hypothèse en défaut : depuis le serveur Veeam, on peut potentiellement toucher l'ensemble des dépôts qu'il pilote.

D'où l'importance des principes d'immuabilité et d'isolation : des dépôts en écriture unique (WORM), des copies air-gapped, et un compte de service Veeam strictement séparé des comptes du domaine de production. Une faille comme celle-ci rappelle que la sauvegarde n'est une assurance que si elle survit à la compromission de ce qu'elle protège.

Plan d'action

  1. Mettre à jour immédiatement vers VBR 12.3.2.4854 (ou migrer vers la branche v13.x). C'est la priorité non négociable.
  2. Évaluer le passage en workgroup. Sortir le serveur Veeam du domaine est une best practice de sécurité recommandée par Veeam de longue date : elle réduit drastiquement la surface d'attaque héritée d'Active Directory, et neutralise ce vecteur précis.
  3. Isoler le réseau de gestion Veeam des réseaux utilisateurs, et restreindre les comptes pouvant atteindre le serveur.
  4. Renforcer l'immuabilité des dépôts (hardened repositories, immutabilité côté stockage objet) pour qu'une compromission du serveur ne permette pas la suppression des points de restauration.
  5. Auditer les accès récents au serveur de sauvegarde et surveiller toute exécution de processus inhabituelle.

FAQ

Mon serveur Veeam est en workgroup, suis-je vulnérable à la CVE-2026-44963 ?

Non. La faille requiert un utilisateur de domaine authentifié pour être exploitée ; elle ne concerne donc que les serveurs Veeam Backup & Replication joints à un domaine Active Directory. Une configuration en workgroup neutralise ce vecteur. C'est d'ailleurs la raison pour laquelle Veeam recommande de longue date d'exploiter le serveur de sauvegarde hors du domaine de production.

Quelle version corrige la vulnérabilité ?

La version 12.3.2.4854 corrige la faille. Toutes les versions v12 jusqu'à 12.3.2.4465 incluse sont vulnérables. La branche v13.x n'est pas affectée grâce à des changements d'architecture. Si vous êtes sur une v12, la mise à jour vers 12.3.2.4854 ou la migration vers v13.x sont les deux voies de remédiation.

La faille est-elle déjà exploitée par des attaquants ?

Aucune exploitation en conditions réelles n'était documentée à la date de divulgation. Toutefois, les serveurs de sauvegarde sont une cible de choix pour les ransomwares, et quatre vulnérabilités Veeam figurent déjà au catalogue KEV de la CISA, toutes exploitées par des gangs de ransomware. Le risque d'exploitation rapide est donc élevé : il faut traiter ce correctif en urgence, sans attendre une preuve d'exploitation active.

Pourquoi un simple compte utilisateur peut-il compromettre tout le système de sauvegarde ?

Parce que la vulnérabilité abaisse la barrière de privilège à n'importe quel compte de domaine authentifié, là où une RCE critique exige normalement des droits élevés. Dans un réseau d'entreprise, la compromission d'un seul poste ou d'un compte faible suffit alors à atteindre le serveur Veeam. Et comme ce serveur orchestre l'ensemble des sauvegardes, le contrôler revient à pouvoir saboter la capacité de restauration — exactement l'objectif d'un opérateur de ransomware avant de déclencher son chiffrement.

Conclusion

La CVE-2026-44963 n'est pas qu'une RCE de plus : c'est une attaque potentielle contre votre filet de sécurité de dernier recours. Le faible niveau de privilège requis, combiné à l'attrait que représentent les serveurs de sauvegarde pour les ransomwares, en fait un correctif à appliquer sans délai. Mettez à jour vers 12.3.2.4854, envisagez sérieusement le passage en workgroup, et profitez de l'occasion pour vérifier que vos dépôts sont immuables et isolés. Une sauvegarde ne vaut que si elle survit à l'attaque qu'elle est censée corriger.

Cet article vous a plu ?

Commentaires

Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.