GitHub Advisoryadvisory · PyPI

GHSA-8w8g-wq8h-fq33 Dulwich: Symlink write-through in checkout(paths=[]) via raw os.open bypasses all symlink protections

HIGH Published 2026-10-02 Modified 2026-10-02 Official page ↗
Ecosystem
PyPI
Packages
dulwich
Severity
High
CVSS vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Weaknesses
CWE-59, CWE-61
Reviewed
2026-10-02

Affected packages

• PyPI dulwich: >= 0.24.0, < 1.2.8 → fixed in 1.2.8

Description

Summary Dulwich's `porcelain.checkout(paths=[...])` code path writes files using raw `os.open(file_path, O_WRONLY|O_CREAT|O_TRUNC, mode)` followed by `f.write(obj.data)`. This code path does NOT call `build_file_from_blob()` at all, completely bypassing any symlink protections (including the unreleased d09f8af fix). `os.open` without `O_NOFOLLOW` follows symlinks at both the target file and intermediate directories, allowing arbitrary file writes. Root Cause At `dulwich/porcelain/__init__.py:5661-5675`, the `checkout(paths=[...])` implementation: ```python file_path = _checked_worktree_path(r, path) os.makedirs(os.path.dirname(file_path), exist_ok=True) flags = os.O_WRONLY | os.O_CREAT | os.O_TRUNC with os.fdopen(os.open(file_path, flags, mode), "wb") as f: f.write(obj.data) ``` `_checked_worktree_path()` (line 601-631) only performs name validation — checking that the path doesn't start with `/` or `\\` and that components pass `INVALID_DOTNAMES` checks. It performs zero filesystem symlink detection. Impact An attacker can craft a malicious repository that, when a victim clones it and runs `checkout(paths=[...])`, writes attacker-controlled content (with attacker-controlled permissions) to any filesystem location accessible to the user. Writing to `.git/hooks/post-checkout` achieves RCE on the next git checkout. Attack Scenario 1. Attacker creates a repository where HEAD has `trigger` as a symlink (mode 120000, content `../../.git/hooks/post-checkout`), and tag `v1.0` has `trigger` as an executable file (mode 100755, content `#!/bin/sh\nmalicious_payload`) 2. Victim clones the repository — worktree has `trigger` → `../../.git/hooks/post-checkout` (a symlink) 3. Victim runs `porcelain.checkout(repo, target="v1.0", paths=["trigger"])` to restore a specific file from a tag 4. `_checked_worktree_path(r, "trigger")` passes — name validation only, no symlink check 5. `os.open("trigger", O_WRONLY|O_CREAT|O_TRUNC, 0o755)` follows the symlink → opens `.git/hooks/post-checkout` for writing 6. `f.write(obj.data)` writes the malicious payload to the hook 7. Next checkout operation triggers the hook → RCE Suggested Fix Replace the raw `os.open` path with a call to `build_file_from_blob` (once that function is hardened against intermediate symlinks), or add explicit symlink detection: resolve the path with `os.path.realpath()` and verify it stays within the worktree root before opening. Reported by zx (Jace)

Related

Weakness · CWE (2)

  • CWE-59 Improper Link Resolution Before File Access weakness
  • CWE-61 UNIX Symbolic Link (Symlink) Following weakness

References