En durcissant NimbusBackup, nous avons repéré dans l'outil que nous opérons — Proxmox Backup Server — un comportement qui nous semblait problématique, et la lecture de son code a confirmé la faiblesse. Nous l'avons signalée à l'éditeur, nous avons protégé nos clients avant tout correctif, et nous avons attendu l'avis officiel pour publier ces lignes. Voici comment, et pourquoi cet ordre compte.
Nous ne revendiquons pas une « première découverte » : Proxmox avait déjà identifié le sujet. Il s'agit d'une découverte indépendante, faite depuis le terrain, et d'un exemple de divulgation coordonnée qui s'est bien passée.
Le contexte
RDEM Systems opère NimbusBackup, un service de Proxmox Backup Server managé et externalisé. Notre modèle de sécurité suit les recommandations de Proxmox contre les rançongiciels :
- les jetons des clients n'ont que le rôle
DatastoreBackup: ils écrivent, ils ne suppriment pas ; - la rétention s'exécute côté serveur, dans des tâches de prune ;
- les suppressions sont faites par l'opérateur seul, sur ticket (48 h, double validation).
Ce modèle correspond à un mécanisme d'immuabilité que l'ANSSI reconnaît dans son guide Sauvegarde des systèmes d'information (BP-100, v1.1 du 27/11/2025, tableau 2) : des « comptes techniques et droits RBAC distincts entre opérations d'écriture unique (sauvegarde) et opérations de lectures multiples (restauration) ». Le même guide juge la copie hors ligne « plus robuste qu'une solution WORM en ligne » — c'est pourquoi nous proposons aussi une copie hors ligne (AirGapped).
Fin septembre 2026, nous retravaillions notre page sur la sauvegarde immuable avec une question simple : qu'est-ce qui protège vraiment les sauvegardes d'un client si son serveur Proxmox VE est compromis ?
La démarche
La documentation est claire : le rôle DatastoreBackup permet de sauvegarder, pas de supprimer. C'est vrai, et cela ne répond qu'à moitié à la question. Car si le compte du client ne supprime pas, quelque chose supprime quand même : la rétention. Nous nous sommes donc posé la question d'opérateur : « qui supprime, et sur quelle base ? »
Nous avons lu le code de proxmox-backup (branche master au 28/09/2026) : d'un côté la création d'une sauvegarde, de l'autre la logique de rétention. En les lisant côte à côte, un cas nous a semblé mal couvert. Nous l'avons vérifié uniquement sur notre propre datastore de test, jamais sur les données d'un client, avec un jeton limité à DatastoreBackup.
La conclusion tient en une phrase : l'écriture seule protège bien contre la suppression directe, mais elle ne suffit pas, à elle seule, à garantir tout l'historique. L'avis de sécurité PSA-2026-00086-1 de Proxmox en donne le résumé ; les pistes de correction sont détaillées plus bas.
Protéger nos clients, avant tout correctif
Notre signalement contenait une proposition de correctif. Nous ne l'avons pourtant pas déployée nous-mêmes, pour trois raisons : maintenir un PBS recompilé hors des paquets officiels crée sa propre dette (il faut réappliquer le correctif à chaque mise à jour) ; le réglage en jeu est un arbitrage que l'éditeur est mieux placé pour trancher sur toute sa base installée ; et la valeur par défaut lui revient.
À la place, nous avons mis en production, en une heure environ après le signalement, une détection côté opérateur : une vérification horaire, sur tous nos serveurs PBS et tous leurs datastores, qui remonte toute anomalie de datation d'une sauvegarde et qui liste aussi les datastores qu'elle n'a pas pu contrôler — un trou de couverture ne doit jamais passer pour un « tout va bien ». Elle ne modifie pas PBS et laisse à notre astreinte le temps d'agir.
Le client, lui, reçoit une notification neutre, sans mention de faille : elle reste vraie même quand la cause est une simple horloge déréglée. Elle l'invite à vérifier l'horloge de la machine sauvegardée et à nous répondre ; sans réponse sous 7 jours, nous supprimons les sauvegardes anormales, après vérification de notre côté.
La réaction de Proxmox
Nous avons signalé le 1er octobre 2026 en fin de journée, en privé, via security@proxmox.com, avec notre analyse, une reproduction sur notre banc et quatre pistes de correction. L'équipe de sécurité de Proxmox a répondu en moins de 16 heures.
Deux de nos quatre pistes rejoignent les correctifs de Proxmox ; les deux autres ont été écartées, avec des raisons que nous partageons. Le détail de nos quatre pistes et des réponses de Proxmox est repris ci-dessous.
L'avis de sécurité de Proxmox (PSA-2026-00086-1, 10 novembre 2026) l'indique : le problème a été découvert en interne par Proxmox et signalé de façon indépendante par Richard Demongeot (RDEM Systems). L'avis renvoie aussi vers cette page.
| Piste de notre signalement (1er octobre) | Réponse de Proxmox (2 octobre) et correctif |
|---|---|
| A. Refuser les sauvegardes datées dans le futur, avec une marge pour la dérive d'horloge. | Retenue. Un nouveau snapshot daté trop loin dans le futur est refusé. La tolérance se règle par datastore : une minute par défaut, jusqu'à un jour. |
| B. Faire ignorer par la rétention les snapshots datés dans le futur. | Retenue. Le prune ignore désormais toujours les snapshots datés dans le futur. |
C. Exiger un droit plus élevé pour retirer le drapeau protected. | Écartée. Pour Proxmox, le drapeau protège contre l'erreur, pas contre un acteur malveillant ; couvrir ce cas demanderait un second niveau de protection. |
| D. Notifier la création d'un snapshot daté dans le futur. | Écartée. Seule, elle n'aide pas, et avec A et B elle ne peut plus se déclencher. Nous l'avons gardée côté opérateur, en attendant le correctif. |
Le 3 novembre 2026, avant la publication des paquets corrigés, l'équipe de sécurité de Proxmox nous a transmis une version de test de PBS intégrant ses correctifs, ainsi que les correctifs eux-mêmes, pour que nous puissions les tester sur nos propres serveurs. Nous l'avons vérifiée et testée, puis installée le jour même sur nos serveurs. Nous hébergeons les sauvegardes de nos clients : dès lors qu'une version corrigée, produite par l'éditeur lui-même, était disponible, il ne nous a pas semblé raisonnable d'attendre quelques jours de plus pour l'appliquer. C'est le correctif de Proxmox ; nous n'y avons rien changé.
Le point important : les correctifs publiés rejoignent ce que nous avions proposé, et l'échange a été rapide et de qualité. C'est exactement ce que la divulgation coordonnée est censée produire.
Chronologie
- Fin septembre 2026 : lecture du code de Proxmox Backup Server (branche master du 28 septembre).
- 1er octobre, 17 h 26 : la faiblesse est confirmée sur notre banc de test.
- 1er octobre, 18 h 23 : signalement privé à l'équipe sécurité de Proxmox, CERT-FR en copie, avec une première version du correctif.
- 1er octobre, 19 h 24 : mise en production de notre détection côté opérateur.
- 2 octobre : réponse de Proxmox, qui connaissait déjà le problème et nous demande la confidentialité jusqu'aux paquets corrigés.
- 20 octobre : faute de date de correction, nous communiquons une date limite de divulgation, le 1er décembre 2026.
- 3 novembre : Proxmox nous transmet sa version corrigée pour test. Nous la vérifions, la testons et l'installons le jour même : dès le 3 novembre, nos serveurs PBS tournent sur la version corrigée.
- 4 novembre : PBS 4.2.9-1, version officielle corrigée, arrive sur le dépôt no-subscription de Proxmox.
- 5 novembre : nos 7 serveurs PBS passent sur les paquets officiels 4.2.9-1.
- 10 novembre : PBS 4.2.9-1 est disponible sur les dépôts enterprise de Proxmox, et l'avis de sécurité PSA-2026-00086-1 est publié. Cette page est publiée le même jour.
Ce que ça change pour vous
- Si vous exploitez votre propre serveur PBS, mettez-le à jour en 4.2.9-1 ou version ultérieure. Voir l'avis de sécurité PSA-2026-00086-1 de Proxmox.
- Rien ne change dans votre usage normal de NimbusBackup. Vos sauvegardes, vos restaurations et votre client (Proxmox VE,
proxmox-backup-client, Nimbus Backup pour Windows) fonctionnent comme avant. - Gardez l'horloge de vos serveurs à l'heure (NTP ou NTS). Depuis ce correctif, une sauvegarde datée de plus d'une minute dans le futur est refusée. C'est sans effet sur un serveur synchronisé.
- Rappel de l'ANSSI : la séparation des droits est un mécanisme d'immuabilité reconnu, mais la copie hors ligne reste la plus robuste. Le « compromis acceptable » du guide : des sauvegardes régulières en ligne, et une copie hors ligne à une fréquence moindre.
- Ce que fait Nimbus : nos serveurs PBS tournent sur la version corrigée depuis le 3 novembre et sur les paquets officiels 4.2.9-1 depuis le 5 novembre ; notre détection reste active ; une copie hors ligne est disponible avec l'offre AirGapped.
Ce que nous en retenons
- Repérer ce qui semble problématique, puis le confirmer dans le code.
- L'ordre compte : signaler d'abord, protéger ses clients ensuite, publier en dernier.
- La défense en profondeur fonctionne : une détection et une copie hors ligne, en attendant le correctif officiel. Aucune mesure seule ne suffit.
- Il faut promettre au plus juste : c'est le sens de notre page sur l'immuabilité.
NimbusBackup est notre service de Proxmox Backup Server managé, avec séparation des droits et copie hors ligne.