Learn Borg Backup - CVE & Security Releases

#Introduction

The last thirteen episodes built up your defenses: encryption, append-only, access control. But a secure configuration means nothing if the binary running it has holes. Episode 15 covers security from the other side: security releases. Borg 1.4.5 (released 1 July 2026) is a real example — understanding the contents of a security release and the upgrade ritual is part of an SRE's job.

#Borg 1.4.5: A Security Release

#Release Context

Borg 1.4.5 is a security release — a release whose main content is not new features but security fixes. In the real world, security releases are flagged and shipped quickly; good organizations schedule an upgrade right after the release, not waiting for "free time".

The two CVEs fixed in 1.4.5:

#CVE-2026-35568: Metadata Discarding on a Corrupt Encrypted Repository

This issue relates to how Borg handles archive metadata when an encrypted repository encounters corrupt data. On versions before 1.4.5, certain scenarios could cause archive metadata to be discarded — in other words, the part of the repository structure holding file information could be lost or ignored when corruption was detected. The impact: an archive that should still be partially readable becomes incomplete, deepening damage that could actually have been contained.

#CVE-2026-35569: Cache Corruption

The second CVE concerns the repository cache — the local catalog that stores chunk metadata to speed up operations. On vulnerable versions, certain conditions could corrupt the cache and make it behave inconsistently, leading to incorrect verification or operations on the wrong data. A silently corrupt cache is one of the worst enemies of a backup system: everything looks normal until restore time.

#Practice: Always Upgrade to 1.4.5+

#Check the Current Version

borg --version

A version below 1.4.5 means you are still exposed to both CVEs above.

#Upgrade

sudo apt update && sudo apt upgrade -y borgbackup

sudo dnf update -y borgbackup

For pip/pipx installations:

pip install --upgrade borgbackup

Verify after the upgrade:

borg --version

#Compatibility Considerations

Borg 1.4.x keeps repository format compatibility with 1.2/1.3 — your repository does not need to be reinitialized. Check the changelog before upgrading on a staging environment, and test borg list plus one small restore after the upgrade before moving on to production.

#Routine borg check: Part of Your Security Posture

The integrity verification we built in episode 12 is not just maintenance — it is an early detector for corruption related to this class of CVE:

• Monthly borg check detects structural anomalies early.
• Yearly borg check --verify-data confirms chunk contents are still intact.
• Check results are monitored (episode 20) so anomalies do not shout into an empty room.

#Common Pitfalls

• Delaying the upgrade: "backups are not connected to the internet" is an assumption that is often wrong — a remote repo via SSH still needs a secure client/server.
• Not reading the changelog: a blind upgrade risks missing a breaking change; read the release notes first.
• One borg version for everything: make sure the client and server are upgraded together; an extreme version mismatch can make a repo unreadable (episode 16).
• Cache never cleaned: if you suspect cache corruption, clear the local borg cache (the ~/.cache/borg folder) — it will be rebuilt from the repo; the backup data is unaffected.

#Closing

• Borg 1.4.5 (1 July 2026) is a security release that must be adopted.
• CVE-2026-35568: metadata discarding on a corrupt encrypted repo.
• CVE-2026-35569: cache corruption.
• The ritual: check the version, upgrade, verify borg --version, then borg check.
• Routine borg check is part of the security posture, not just maintenance.

In episode 16 we equip you for when things do not go smoothly: troubleshooting — borg check, --debug-topic, logging with BORG_LOGGING_CONF, common cases like repo lock, corruption, and version mismatch, and recovery from damaged segments.