CVE-2026-93853: Barman snapshot backup deletion trusts unverified backup catalog metadata
Unverified ownership in Barman snapshot backup deletion allows a principal who can write the backup catalog to cause Barman to delete unrelated cloud snapshots. When a snapshot backup is deleted, either explicitly or by retention policy enforcement, Barman reads the snapshot identifiers from the backup.info file and passes them to the cloud provider's delete API using Barman's own credentials, without verifying that the snapshots belong to that backup. An attacker who can overwrite backup.info but lacks snapshot delete permissions can substitute the identifiers of other snapshots, causing Barman to delete any snapshot its cloud identity can reach on AWS, Microsoft Azure, or Google Cloud. Exploitation requires a deployment where the principal that writes the backup catalog is separate from the identity Barman uses to delete snapshots. Barman versions from 3.4.0 (Google Cloud), 3.6.0 (Azure), and 3.7.0 (AWS) up to and including 3.20.0 are affected. The issue is fixed in Barman 3.20.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Barmanto a version that resolves this vulnerability.Fixed in 3.20.1
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Deployments using snapshot backups on AWS, Microsoft Azure, or Google Cloud are affected if they run a vulnerable Barman version and the principal that can modify the backup catalog is separate from Barman's cloud identity. The relevant affected version ranges begin at 3.4.0 for Google Cloud, 3.6.0 for Azure, and 3.7.0 for AWS, through 3.20.0.
What access does an attacker need to exploit it?
An attacker needs the ability to overwrite the backup catalog's backup.info file. They do not need cloud snapshot deletion permissions, because Barman performs the deletion with its own cloud credentials.
What can an attacker delete?
An attacker can replace the snapshot identifiers in backup.info with identifiers for unrelated snapshots. Barman may then delete any snapshots reachable by its cloud identity when the backup is explicitly deleted or when retention policy enforcement deletes it.
How can the risk be reduced if an immediate upgrade is not possible?
Restrict write access to the backup catalog so untrusted or lower-privileged principals cannot overwrite backup.info. Also limit the snapshots that Barman's cloud identity can reach, reducing the set of snapshots that could be deleted through manipulated metadata.
What version contains the fix?
The issue is fixed in Barman 3.20.1.