CVE-2026-47734

What it actually does

Dulwich versions before 1.2.5 can allocate excessive memory when processing a crafted thin Git pack during push handling. A client with push access can send a very small pack whose delta header declares an attacker-controlled, extremely large destination size; vulnerable add_thin_pack/apply_delta processing trusts that declared size and allocates memory disproportionate to the actual input. This can exhaust process or host memory and terminate the Dulwich-based Git service, causing denial of service. The vulnerable exposure is primarily Dulwich-based servers that accept pushes through git-receive-pack, dulwich.server, the HTTP smart server, or code built on ReceivePackHandler.

Why it matters to the business

An authenticated user or compromised push credential can disrupt Dulwich-backed Git hosting by crashing or severely degrading the service with very little network traffic. This can interrupt source-code collaboration, CI/CD workflows, release processes, and automation that depends on repository pushes. The risk is lower than unauthenticated remote code execution because push access is required and there is no known KEV listing or mature public exploitation indicated, but the attack is low-complexity once push access is available and can affect availability significantly.

How an attack unfolds

An attacker first obtains legitimate or stolen credentials that allow pushing to a repository served by a vulnerable Dulwich-based Git server. The attacker initiates a Git push over SSH, HTTP smart Git, or another integration path that invokes Dulwich receive-pack handling. Instead of sending a normal pack, the attacker submits a tiny crafted thin pack containing a delta header with a very large declared destination size. During ingestion, vulnerable Dulwich code processes the delta and allocates memory according to the declared size rather than the small amount of data actually received. The allocation can consume hundreds of megabytes or more per attempt, triggering Python MemoryError, container or systemd memory-limit enforcement, Linux OOM killer activity, or full service unavailability. Repeated attempts can keep the Git service unstable until the vulnerable package is upgraded or push access is restricted.

How to fix it

Upgrade Dulwich to version 1.2.5 or later everywhere it is used to implement Git push handling. After upgrading, configure receive.maxInputSize in the repository configuration to a sane maximum pack input size for the environment; patched ReceivePackHandler passes this value through to add_thin_pack, and oversized input is rejected with PackInputTooLarge. Do not rely on receive.maxInputSize as a workaround on unpatched versions because it has no effect before the fix. Until upgrades are complete, restrict push access to trusted authenticated clients, disable dulwich-receive-pack on servers that only need fetch/read-only access, and run the service under operating-system or platform memory limits such as ulimit, cgroups, systemd MemoryMax, or container memory limits to contain crashes to the service rather than the host.

How to confirm the fix worked

Confirm all deployed Dulwich installations report version 1.2.5 or later using package inventory, dependency lockfiles, runtime package inspection, and container image scans. Verify that servers accepting pushes are actually using the upgraded library and were restarted or redeployed after the upgrade. Confirm repository configuration includes an appropriate receive.maxInputSize value where push handling is enabled. Test exposure by attempting a normal push and confirming it still succeeds, then test an oversized-pack condition in a non-production environment and confirm the server rejects it with PackInputTooLarge or an equivalent controlled error rather than growing memory without bound. Review service resource limits to ensure memory exhaustion is contained even if another parsing issue is encountered.

Typical attack path

1. Identify a Dulwich-based Git service that accepts pushes through git-receive-pack, dulwich.server, HTTP smart Git, or ReceivePackHandler-based code.
2. Obtain or use existing credentials with push permission to at least one repository.
3. Start a Git push session to the vulnerable service.
4. Send a tiny crafted thin pack with a delta header declaring an excessively large destination size.
5. Cause Dulwich to allocate memory based on the attacker-controlled declared size.
6. Trigger process crash, container restart, system OOM kill, or degraded availability of the Git service.
7. Repeat the push attempt as needed to sustain denial of service.

How to detect it

Because this vulnerability causes denial of service rather than code execution, evidence is most likely in service availability, authentication, Git push, application, container, systemd, and kernel logs. Look for authenticated push attempts immediately followed by sharp memory growth, Python MemoryError exceptions, process restarts, container OOMKilled states, systemd memory-limit terminations, or Linux OOM killer messages involving Dulwich, git-receive-pack, or the application embedding Dulwich. For HTTP smart Git deployments, review web access logs for POST requests to git-receive-pack endpoints that return 500, 502, 503, 504, connection reset, or unusually small request bodies before a service crash. For SSH or custom protocol deployments, correlate receive-pack session starts with abrupt disconnects and process termination. On patched systems, repeated PackInputTooLarge exceptions may indicate probing or attempted exploitation. Preserve the source account, source IP, repository path, request timestamp, and any pack-processing stack traces for investigation. Absence of persistence artifacts is expected unless the attacker also used separate compromised credentials or vulnerabilities.

• POST /git-receive-pack
• git-receive-pack
• dulwich-receive-pack
• dulwich.server
• ReceivePackHandler
• add_thin_pack
• apply_delta
• PackInputTooLarge
• MemoryError
• Out of memory: Killed process
• Killed process
• oom-kill
• OOMKilled
• MemoryMax
• Cannot allocate memory
• receive.maxInputSize

What your security team should do

• Prioritize upgrading all Dulwich-based Git servers that accept pushes to Dulwich 1.2.5 or later.
• Inventory applications, internal tools, containers, and appliances that embed Dulwich server functionality, HTTP smart Git support, dulwich-receive-pack, or ReceivePackHandler.
• Set receive.maxInputSize after upgrading and standardize an organization-approved maximum based on expected repository and pack sizes.
• Temporarily disable push support or restrict it to trusted networks and authenticated users until all vulnerable instances are upgraded.
• Add process, container, or systemd memory limits for Dulwich-based Git services to prevent host-wide outages.
• Review push access permissions and revoke stale credentials, especially for service accounts and former users.
• Monitor authentication and push logs for repeated failed or interrupted git-receive-pack sessions, OOM events, and PackInputTooLarge exceptions.
• Ensure CI/CD and developer workflows have fallback plans if a Git hosting component becomes unavailable.