Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

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

HIGHFix: jelmer/dulwich@9389fcb

GHSA-8w8g-wq8h-fq33 is a high-severity (CVSS 8.6) remote code execution vulnerability in dulwich. A fix is available for dulwich — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 2, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐍dulwich

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

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:

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)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIdulwich≥ 0.24.0&&< 1.2.81.2.8pip install --upgrade 'dulwich==1.2.8'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dulwich, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update dulwich to 1.2.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8w8g-wq8h-fq33 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

## 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_worktr
O3 Security · Impact-Aware SCA

Is GHSA-8w8g-wq8h-fq33 in your dependencies?

Find it across PyPI, including transitive dependencies.

Dulwich: Symlink write-through in checkout(paths=[]) via…