Answer in brief
CVE-2026-62268 records a Medium severity vulnerability in borg extract might modify out-of-tree files when extracting maliciously crafted archives. The current sources do not mark it as known exploited. The current feed maps borgbackup (pip), borgbackup (pip), borgbackup (pypi), borgbackup (pypi). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps borgbackup (pip), borgbackup (pip), borgbackup (pypi), borgbackup (pypi). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| borgbackuppip | <1.4.5 | 1.4.5 |
| borgbackuppip | >=2.0.0b1,<2.0.0b22 | 2.0.0b22 |
| borgbackuppypi | >=0 <1.4.5 | 1.4.5 |
| borgbackuppypi | >=2.0.0b1 <2.0.0b22 | 2.0.0b22 |
Published upstream
Oct 15, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Oct 15, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Oct 15, 2026
### Impact A maliciously crafted archive could contain a symlink (e.g. "evil" -> "/etc") followed by an item below it ("evil/passwd"), or an item whose path embeds ".." (e.g. "a/../../etc/passwd"). When extracting such items, borg followed the symlink / resolved the "..", so it could delete or overwrite files outside the extraction directory. In a quite similar scenario, a crafted archive could contain a slave hardlink item with the hardlink source pointing outside the extraction directory. When extracting such an item, borg would hard-link the outside and the inside item. Note: that sounds bad, but it is no big issue in practice: to create such a malicious archive, the attacker would need repository access and (for encrypted or authenticated repos) also the borg key and passphrase. Affected: likely all borg releases before 1.4.5 (and also all borg 2.0.0 betas before b22). ### Patches - 1.4.x release series: fix released with 1.4.5. commits 3e9ed6d1ad6d3531b39c07b8ef3ecf41fce4437f and 141888f2fabcd57a300547c2aa63212cb213924d. - 1.2.x release series: no new releases any more, fix commits available on 1.2-maint branch: 0ac568e290518c3bbe781459978720dde7fab224 and d907f2cb57337041c4fa55ca4682895535e5076b - 2.0.0 betas: fix will be in 2.0.0b22, fix commits on master branch: 2d632531028b09da8ab5d1450f89bebcc205d640 and 4f37fdfed10b50559a0dd333b0d5581c642af329 ### Workarounds For encrypted or authenticated repositories, do not share borg key and passphrase with potential attackers. For all kinds of repositories, do not share repository access with potential attackers. Usually, the repository access is protected by means outside of borg; e.g. a ssh key for remote repositories or physical access to local storage media. ### References This issue was first discovered by AI in a private code security review initiated by @ThomasWaldmann. A few days later, it was also independently reported to @ThomasWaldmann by: - Michael Head (machin0r) - Chinnapak Charoensiri [Github: Ziim-eiei].
Quoted source text, attributed separately from HOL analysis.