CVE-2026-47734: CWE-400: Uncontrolled Resource Consumption in jelmer dulwich
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 dest_size. When dulwich ingested it via add_thin_pack / apply_delta, 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. add_thin_pack now accepts a max_input_size 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.
AI Analysis
Technical Summary
CVE-2026-47734 describes an uncontrolled resource consumption vulnerability (CWE-400) in the Dulwich Git implementation. Versions >=0.1.0 and <1.2.5 allow a client with push access to send a crafted thin pack whose delta header specifies a large destination size, causing Dulwich to allocate hundreds of megabytes of memory disproportionate to the actual data received. This occurs in the add_thin_pack/apply_delta functions when processing git-receive-pack requests. The vulnerability impacts any Dulwich-based Git server that accepts pushes, including those using dulwich.server or ReceivePackHandler. The issue is fixed in Dulwich 1.2.5 by adding a max_input_size parameter and enforcing receive.maxInputSize repository config limits, raising exceptions when exceeded. Prior to 1.2.5, no such limits exist, so mitigation requires restricting push access or applying OS-level memory constraints.
Potential Impact
An attacker with push access can cause the Dulwich Git server to allocate excessive memory, potentially leading to denial of service by exhausting server resources. This does not impact confidentiality or integrity but can disrupt availability of the Git service. The vulnerability affects any server exposing git-receive-pack functionality using vulnerable Dulwich versions.
Mitigation Recommendations
A patch is available in Dulwich version 1.2.5 that introduces input size limits to prevent excessive memory allocation. Operators should upgrade to version 1.2.5 or later and configure receive.maxInputSize in repository settings to a suitable limit. Until upgrading, restrict push access to trusted, authenticated clients only or disable push functionality if not needed. Additionally, apply OS-level memory limits (e.g., ulimit, cgroups, container memory limits) to contain potential resource exhaustion from malicious pushes. Note that receive.maxInputSize settings have no effect on unpatched versions.
CVE-2026-47734: CWE-400: Uncontrolled Resource Consumption in jelmer dulwich
Description
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 dest_size. When dulwich ingested it via add_thin_pack / apply_delta, 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. add_thin_pack now accepts a max_input_size 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.
CVSS v3.1
Score 5.7medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-47734 describes an uncontrolled resource consumption vulnerability (CWE-400) in the Dulwich Git implementation. Versions >=0.1.0 and <1.2.5 allow a client with push access to send a crafted thin pack whose delta header specifies a large destination size, causing Dulwich to allocate hundreds of megabytes of memory disproportionate to the actual data received. This occurs in the add_thin_pack/apply_delta functions when processing git-receive-pack requests. The vulnerability impacts any Dulwich-based Git server that accepts pushes, including those using dulwich.server or ReceivePackHandler. The issue is fixed in Dulwich 1.2.5 by adding a max_input_size parameter and enforcing receive.maxInputSize repository config limits, raising exceptions when exceeded. Prior to 1.2.5, no such limits exist, so mitigation requires restricting push access or applying OS-level memory constraints.
Potential Impact
An attacker with push access can cause the Dulwich Git server to allocate excessive memory, potentially leading to denial of service by exhausting server resources. This does not impact confidentiality or integrity but can disrupt availability of the Git service. The vulnerability affects any server exposing git-receive-pack functionality using vulnerable Dulwich versions.
Mitigation Recommendations
A patch is available in Dulwich version 1.2.5 that introduces input size limits to prevent excessive memory allocation. Operators should upgrade to version 1.2.5 or later and configure receive.maxInputSize in repository settings to a suitable limit. Until upgrading, restrict push access to trusted, authenticated clients only or disable push functionality if not needed. Additionally, apply OS-level memory limits (e.g., ulimit, cgroups, container memory limits) to contain potential resource exhaustion from malicious pushes. Note that receive.maxInputSize settings have no effect on unpatched versions.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-05-19T22:16:39.503Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a29e5e331875706499a399d
Added to database: 6/10/2026, 10:32:03 PM
Last enriched: 6/10/2026, 10:46:11 PM
Last updated: 6/10/2026, 11:48:10 PM
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.