GHSA-GFP8-W835-V44J

Vulnerability from github – Published: 2026-10-15 20:09 – Updated: 2026-10-15 20:09
VLAI
Summary
borg extract might modify out-of-tree files when extracting maliciously crafted archives
Details

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].

Severity
5.3 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "borgbackup"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "borgbackup"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.0.0b22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:09:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA maliciously crafted archive could contain a symlink (e.g. \"evil\" -\u003e \"/etc\") followed by an item below it (\"evil/passwd\"), or an item whose path embeds \"..\" (e.g. \"a/../../etc/passwd\").\n\nWhen extracting such items, borg followed the symlink / resolved the \"..\", so it could delete or overwrite files outside the extraction directory.\n\nIn a quite similar scenario, a crafted archive could contain a slave hardlink item with the hardlink source pointing outside the extraction directory.\n\nWhen extracting such an item, borg would hard-link the outside and the inside item.\n    \nNote: 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.\n\nAffected: likely all borg releases before 1.4.5 (and also all borg 2.0.0 betas before b22).\n\n### Patches\n- 1.4.x release series: fix released with 1.4.5. commits 3e9ed6d1ad6d3531b39c07b8ef3ecf41fce4437f and 141888f2fabcd57a300547c2aa63212cb213924d.\n- 1.2.x release series: no new releases any more, fix commits available on 1.2-maint branch: 0ac568e290518c3bbe781459978720dde7fab224 and d907f2cb57337041c4fa55ca4682895535e5076b\n- 2.0.0 betas: fix will be in 2.0.0b22, fix commits on master branch: 2d632531028b09da8ab5d1450f89bebcc205d640 and 4f37fdfed10b50559a0dd333b0d5581c642af329\n\n### Workarounds\nFor encrypted or authenticated repositories, do not share borg key and passphrase with potential attackers.\n\nFor 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.\n\n### References\nThis issue was first discovered by AI in a private code security review initiated by @ThomasWaldmann.\n\nA few days later, it was also independently reported to @ThomasWaldmann by:\n- Michael Head (machin0r)\n- Chinnapak Charoensiri [Github: Ziim-eiei].",
  "id": "GHSA-gfp8-w835-v44j",
  "modified": "2026-10-15T20:09:23Z",
  "published": "2026-10-15T20:09:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/security/advisories/GHSA-gfp8-w835-v44j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/0ac568e290518c3bbe781459978720dde7fab224"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/141888f2fabcd57a300547c2aa63212cb213924d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/2d632531028b09da8ab5d1450f89bebcc205d640"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/3e9ed6d1ad6d3531b39c07b8ef3ecf41fce4437f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/4f37fdfed10b50559a0dd333b0d5581c642af329"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/d907f2cb57337041c4fa55ca4682895535e5076b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/borgbackup/borg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/releases/tag/1.4.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/releases/tag/2.0.0b22"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "borg extract might modify out-of-tree files when extracting maliciously crafted archives"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.