Skip to main content
CVE-2026-114098VulnerabilityPublished Updated

stash pop · Dulwich: Symlink directory traversal

Affects conda-lockSource GCVE Database

0
Compare
Authoritative record:CVE-2026-114098· High 7.3

Not known to be exploited · CVSS 7.3 High.

Data as of 30 Oct 2026, 07:30 UTC

CVSS 4.0 base score
7.3High
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (VulnCheck)CVSS 4.07.3
CNA (VulnCheck)CVSS 3.17.8
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 21 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Homebrewconda-lockpkg:brew/conda-lockOther threatsAffected
  • >=3.0.0
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## Summary Dulwich's `stash.py:pop()` function is vulnerable to symlink directory traversal, allowing an attacker to write arbitrary files outside the repository worktree when a victim pops a stash in a malicious repository. ## Root Cause The `pop()` function at `dulwich/stash.py:236` uses `os.path.exists(parent_dir)` to check if a parent directory exists before writing stashed files. `os.path.exists()` follows symlinks, so when an intermediate directory in the path is a symlink pointing outside the worktree (e.g., `link → ../../.git/hooks`), the check passes and subsequent file writes resolve through the symlink. The `validate_path()` function (line 228) only validates path component names against `INVALID_DOTNAMES` — it performs zero filesystem symlink detection. On dulwich 1.2.7 (latest release), `build_file_from_blob()` has no symlink protection whatsoever. ## Impact An attacker can craft a malicious repository that, when a victim clones it and performs a stash pop operation, writes attacker-controlled content to arbitrary filesystem locations. Writing to `.git/hooks/post-checkout` achieves Remote Code Execution on the victim's machine on the next git checkout operation. ## Attack Scenario 1. Attacker creates a repository with branch `main` containing `link` (symlink → `../../.git/hooks`) and branch `feature` containing `link/post-checkout` (executable payload) 2. Victim clones the repository (landing on `main` — symlink `link` exists in worktree) 3. Victim checks out `feature`, makes changes, runs `stash.push()` 4. Victim checks out `main` (restoring the `link` symlink) 5. Victim runs `stash.pop(0)` — stash contains `link/post-checkout` 6. `os.path.exists("link")` returns True (symlink to existing directory), `os.makedirs` skipped 7. `build_file_from_blob(blob, mode, "link/post-checkout")` → `open("link/post-checkout", "wb")` follows the intermediate symlink → payload written to `.git/hooks/post-checkout` 8. Next checkout operation triggers the hook → RCE ## Suggested Fix Before writing any file, verify that no component of the target path resolves through a symlink outside the worktree. Use `os.path.realpath(parent_dir)` and confirm it stays within the repository root. Alternatively, use `os.open()` with `O_NOFOLLOW` on each path component. Reported by **zx (Jace)**

References

Community reviews

Loading reviews…