Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-47734Dulwich has unbounded memory allocation in receive-pack from crafted thin packs

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.

Timeline

  1. ID reserved

    By GitHub_M

  2. · 22 days later

    Published

  3. · 1 day later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-47734, by who scored it
Scored byCVSSScoreVector
GitHub_MCNA (assigner)3.1Medium5.7CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
NVDNVD · Deferred3.1Medium5.7CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
EPSS (exploitation in 30 days)
0.19% · top 91% of all CVEs (13 Nov 2026)
CISA SSVC
Exploitation: none · Automatable: no · Technical impact: partial
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Medium 5.7.

Affected products

Affected packages

From reviewed advisories of the GitHub Advisory Database.

References

References2

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-47734 badge
[![CVE-2026-47734](https://cveledger.app/badge/CVE-2026-47734.svg)](https://cveledger.app/cve/CVE-2026-47734)

Record last updated .