While hardening NimbusBackup, we spotted a behaviour in the tool we operate — Proxmox Backup Server — that looked problematic, and reading its code confirmed the weakness. We reported it to the vendor, we protected our clients before any fix, and we waited for the official advisory before publishing this. Here is how, and why that order matters.
We do not claim a "first discovery": Proxmox had already identified the matter. This is an independent discovery, made from the field, and an example of coordinated disclosure that went well.
The context
RDEM Systems operates NimbusBackup, a managed, offsite Proxmox Backup Server service. Our security model follows Proxmox's own ransomware recommendations:
- client tokens only hold the
DatastoreBackuprole: they write, they do not delete; - retention runs server-side, in prune jobs;
- deletions are performed by the operator only, by ticket (48 h, two-channel validation).
This model matches an immutability mechanism that France's ANSSI recognises in its backup guide (BP-100, v1.1, 27 Nov 2025, table 2): "technical accounts and distinct RBAC rights between write-once (backup) and read-many (restore) operations". The same guide considers an offline copy "more robust than an online WORM solution" — which is why we also offer an offline (AirGapped) copy.
In late September 2026 we were reworking our immutable-backup page with a simple question: what actually protects a client's backups if their Proxmox VE server is compromised?
The approach
The documentation is clear: the DatastoreBackup role allows backing up, not deleting. True — and it only half-answers the question. Because if the client's account does not delete, something still does: retention. So we asked the operator's question: "who deletes, and on what basis?"
We read the proxmox-backup code (master branch, 28 Sep 2026): backup creation on one side, retention logic on the other. Reading them side by side, one case looked poorly covered. We verified it only on our own test datastore, never on client data, with a token limited to DatastoreBackup.
The takeaway fits in one sentence: write-only protects well against direct deletion, but on its own it is not enough to guarantee the whole history. Proxmox'ssecurity advisory PSA-2026-00086-1 gives the summary; the fix directions are detailed below.
Protecting our clients, before any fix
Our report included a proposed fix. We did not deploy it ourselves, for three reasons: running a recompiled PBS outside the official packages creates its own debt (the patch must be re-applied at every update); the setting involved is a trade-off the vendor is better placed to decide across its whole installed base; and the default value is theirs to set.
Instead, about one hour after the report, we put a detection into production: an hourly check, across all our PBS servers and all their datastores, that flags any anomaly in a backup's date and also lists the datastores it could not check — a coverage gap must never pass for "all clear". It does not modify PBS, and it gives our on-call team time to act.
The client receives a neutral notification, with no mention of a flaw: it stays true even when the cause is a mis-set clock. It asks them to check the clock of the backed-up machine and to reply; without a reply within 7 days, we delete the abnormal backups, after checking on our side.
How Proxmox responded
We reported late on 1 October 2026, privately, via security@proxmox.com, with our analysis, a reproduction on our bench and four fix directions. Proxmox's security team replied in under 16 hours.
Two of our four directions match the fixes Proxmox shipped; the other two were set aside, with reasons we share. The detail of our four directions and Proxmox's replies is given below.
Proxmox's security advisory (PSA-2026-00086-1, 10 November 2026) states it: the issue was discovered internally at Proxmox and independently reported by Richard Demongeot (RDEM Systems). The advisory also links to this page.
| Direction in our report (1 October) | Proxmox's reply (2 October) and the fix |
|---|---|
| A. Reject backups dated in the future, with a margin for clock drift. | Adopted. New snapshots dated too far in the future are rejected. The tolerance is set per datastore: one minute by default, up to one day. |
| B. Make retention ignore snapshots dated in the future. | Adopted. Pruning now always ignores snapshots dated in the future. |
C. Require a higher privilege to remove the protected flag. | Set aside. For Proxmox, the protection flag guards against accidental deletion, not against a malicious actor. Covering that case would take a second level of protection. |
| D. Send a notification when a snapshot dated in the future is created. | Set aside. On its own it does not help, and with A and B in place it can no longer fire. We kept it on the operator side anyway, until the fix shipped. |
On 3 November 2026, before the fixed packages were released, the Proxmox security team sent us a test build of PBS with their fixes, along with the patches themselves, so that we could test them on our own servers. We checked and tested it, then installed it on our servers the same day. We host our customers' backups: once a fixed version, built by the vendor itself, was available, waiting a few more days to apply it did not seem reasonable to us. This is the Proxmox fix; we changed nothing in it.
The key point: the released fixes converge with what we proposed, and the exchange was fast and sound. That is exactly what coordinated disclosure is meant to produce.
Timeline
- Late September 2026: we read the Proxmox Backup Server source code (master branch of 28 September).
- 1 October, 17:26 (CEST): the weakness is confirmed on our test bench.
- 1 October, 18:23: private report to the Proxmox security team, CERT-FR in copy, with a first version of the fix.
- 1 October, 19:24: our operator-side detection goes live.
- 2 October: Proxmox replies; they already knew about the issue and ask us to keep it private until fixed packages are released.
- 20 October: with no fix date yet, we give a disclosure deadline of 1 December 2026.
- 3 November: Proxmox sends us their fixed version for testing. We check it, test it and install it the same day: from 3 November, our PBS servers run the fixed version.
- 4 November: PBS 4.2.9-1, the official fixed version, lands in the Proxmox no-subscription repository.
- 5 November: our 7 PBS servers move to the official 4.2.9-1 packages.
- 10 November: PBS 4.2.9-1 is available in the Proxmox enterprise repositories and security advisory PSA-2026-00086-1 is published. This page goes live the same day.
What it changes for you
- If you run your own PBS server, update it to 4.2.9-1 or later. See Proxmox security advisory PSA-2026-00086-1.
- Nothing changes in your normal use of NimbusBackup. Your backups, your restores and your client (Proxmox VE,
proxmox-backup-client, Nimbus Backup for Windows) work as before. - Keep your servers' clocks in sync (NTP or NTS). Since this fix, a backup dated more than one minute in the future is rejected. A synchronized server is not affected.
- ANSSI reminder: role separation is a recognised immutability mechanism, but the offline copy remains the most robust. The guide's "acceptable compromise": regular online backups, plus an offline copy at a lower frequency.
- What Nimbus does: our PBS servers have run the fixed version since 3 November and the official 4.2.9-1 packages since 5 November; our detection keeps running; and an offline copy is available with the AirGapped plan.
What we take away
- Spot what looks problematic, then confirm it in the code.
- Order matters: report first, protect your clients next, publish last.
- Defence in depth works: a detection and an offline copy, while waiting for the official fix. No single measure is enough.
- Promise exactly what you can deliver — the point of our immutability page.
NimbusBackup is our managed Proxmox Backup Server service, with role separation and an offline copy.