EnterpriseDB/barman release/3.20.1

Release 3.20.1

on GitHub

3.20.1 (2026-09-29)

Bugfixes

• Fix CVE-2026-93853 - privilege escalation issue that could delete unrelated cloud snapshots

  Before deleting a snapshot-based backup, Barman now checks, using
  metadata read directly from the cloud provider rather than from the
  backup catalog, that the snapshot's name (or, for AWS, its Name tag)
  matches the naming convention Barman uses for the backup being
  deleted. If it doesn't match, deletion is refused and an error is
  raised instead. A snapshot that cannot be found at all is treated as
  already deleted, with no error raised.

  Previously, Barman trusted the snapshot identifiers recorded in the
  backup catalog (backup.info) without further verification. On AWS,
  Azure and Google Cloud alike, anyone able to overwrite that catalog
  object could cause Barman to delete unrelated cloud snapshots --
  including snapshots outside the backup being removed -- using
  Barman's own cloud credentials on the next retention run or manual
  deletion.

  This is a privilege escalation risk specifically where the principal
  able to write the backup catalog is more restricted than Barman's own
  cloud identity (for example, a separate upload or CI principal without
  snapshot-delete permissions), the kind of least-privilege setup that
  is recommended. Deployments using a single, shared identity for both
  are not granted a new capability by this issue, but upgrading is still
  recommended.

  CVE ID: CVE-2026-93853

  References: BAR-1608.

• Fix GCS multipart backup uploads ignoring STORAGE_EMULATOR_HOST

  The multipart upload support added for Google Cloud Storage in 3.20.0
  only accounted for a custom GOOGLE_CLOUD_UNIVERSE_DOMAIN, ignoring
  STORAGE_EMULATOR_HOST and other endpoint overrides such as
  API_ENDPOINT_OVERRIDE. As a result, barman-cloud-backup against a
  GCS-compatible emulator failed, even though every other GCS operation
  correctly honored the emulator. The multipart upload URL is now
  resolved the same way as every other request made by the GCS client,
  so it respects the configured endpoint.

  References: BAR-1621.

• Fix barman-cloud-wal-restore serving an incomplete WAL, or crashing, when both the complete and .partial versions exist

  When cloud storage held both a complete WAL file and its .partial
  counterpart for the same segment (it happens only with CloudNativePG),
  barman-cloud-wal-restore could result in the incomplete .partial file being
  restored instead of the complete WAL.

  Also, even when parallel was unused, Barman would still attempt to create a spool
  directory, which could fail on a read-only filesystem or in the lack of the
  necessary permissions.

  The complete WAL is now always preferred over its .partial counterpart when both
  are present and no attempt is made to create a spool directory unnecessarily.

  NOTE: This behavior is specific to CloudNativePG and does not apply to other cloud
  storage setups.

  References: BAR-1620.

• Fix Azure disk snapshot creation with recent versions of the Azure SDK

  Creating Azure snapshots backups could fail with recent versions of the
  azure-mgmt-compute SDK (>= 38.0), which changed its API interface.
  This issue has been addressed to ensure compatibility with the updated SDK.
  Please update your azure-mgmt-compute lib to a version >= 38.0 for this release.

  References: BAR-1619.

• Fix barman-cloud-backup-delete crashing when deleting GCP snapshot backups

  barman-cloud-backup-delete could crash with an AttributeError when
  deleting a snapshot backup taken with --cloud-provider google-cloud-storage.
  This issue is now fixed.

  References: BAR-1624.