CVE-2026-47734: Dulwich has unbounded memory allocation in receive-pack from crafted thin packs
Impact
An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).
A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge destsize. When dulwich ingested it via addthinpack / applydelta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.
Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler.
Patches
Patched in 1.2.5.
addthinpack now accepts a maxinputsize keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.
Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment.
Workarounds
On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:
- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches. - Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.
Resources
- git's receive.maxInputSize / git index-pack --max-input-size documentation - Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney
Other sources
Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.1.0 and prior to version 1.2.5, a client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge destsize. When dulwich ingested it via addthinpack / applydelta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler - are impacted. The issue is patched in 1.2.5. addthinpack now accepts a maxinputsize keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches and/or run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/dulwichto a version that resolves this vulnerability.Fixed in 1.2.5 - Upgrade
Upgrade
Dulwichto a version that resolves this vulnerability.Fixed in 1.2.5 - Configuration
Set receive.maxInputSize in the server repository configuration to a sane byte limit for the environment.
Dulwich Git server receive.maxInputSize = a sane bound for the environment - Compensating control
Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it on servers that only need to serve fetches.
- Compensating control
Run the server under an OS-level memory limit, such as ulimit, cgroups/MemoryMax, or a container memory limit.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-47734?
The severity of CVE-2026-47734 is rated as medium with a score of 5.7.
What type of vulnerability is CVE-2026-47734?
CVE-2026-47734 is an uncontrolled-resource-consumption vulnerability leading to denial-of-service.
How does CVE-2026-47734 impact software performance?
CVE-2026-47734 can lead to memory exhaustion, causing the software to become unresponsive.
Who can exploit CVE-2026-47734?
A client with push access can exploit CVE-2026-47734 by pushing a crafted thin pack.
How can I mitigate the risk of CVE-2026-47734?
To mitigate CVE-2026-47734, ensure to update to the latest version of dulwich that addresses this vulnerability.