{"api_version":"1","generated_at":"2026-06-11T18:44:17+00:00","cve":"CVE-2026-47734","urls":{"html":"https://cve.report/CVE-2026-47734","api":"https://cve.report/api/cve/CVE-2026-47734.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-47734","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-47734"},"summary":{"title":"Dulwich 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.","state":"PUBLISHED","assigner":"GitHub_M","published_at":"2026-06-10 23:16:48","updated_at":"2026-06-11 15:21:07"},"problem_types":["CWE-400","CWE-789","CWE-400 CWE-400: Uncontrolled Resource Consumption","CWE-789 CWE-789: Memory Allocation with Excessive Size Value"],"metrics":[{"version":"3.1","source":"security-advisories@github.com","type":"Secondary","score":"5.7","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","baseScore":5.7,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"REQUIRED","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"5.7","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","data":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":5.7,"baseSeverity":"MEDIUM","confidentialityImpact":"NONE","integrityImpact":"NONE","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"REQUIRED","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","version":"3.1"}}],"references":[{"url":"https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj","name":"https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5","name":"https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-47734","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-47734","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"jelmer","product":"dulwich","version":"affected >= 0.1.0, < 1.2.5","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"product":"dulwich","vendor":"jelmer","versions":[{"status":"affected","version":">= 0.1.0, < 1.2.5"}]}],"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":5.7,"baseSeverity":"MEDIUM","confidentialityImpact":"NONE","integrityImpact":"NONE","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"REQUIRED","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","version":"3.1"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-400","description":"CWE-400: Uncontrolled Resource Consumption","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-789","description":"CWE-789: Memory Allocation with Excessive Size Value","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-06-10T22:11:02.704Z","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","shortName":"GitHub_M"},"references":[{"name":"https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj","tags":["x_refsource_CONFIRM"],"url":"https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj"},{"name":"https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5","tags":["x_refsource_MISC"],"url":"https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5"}],"source":{"advisory":"GHSA-xrvj-v92f-53gj","discovery":"UNKNOWN"},"title":"Dulwich has unbounded memory allocation in receive-pack from crafted thin packs"}},"cveMetadata":{"assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","assignerShortName":"GitHub_M","cveId":"CVE-2026-47734","datePublished":"2026-06-10T22:11:02.704Z","dateReserved":"2026-05-19T22:16:39.503Z","dateUpdated":"2026-06-10T22:11:02.704Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-06-10 23:16:48","lastModifiedDate":"2026-06-11 15:21:07","problem_types":["CWE-400","CWE-789","CWE-400 CWE-400: Uncontrolled Resource Consumption","CWE-789 CWE-789: Memory Allocation with Excessive Size Value"],"metrics":{"cvssMetricV31":[{"source":"security-advisories@github.com","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","baseScore":5.7,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"REQUIRED","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":2.1,"impactScore":3.6}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"47734","Ordinal":"1","Title":"Dulwich has unbounded memory allocation in receive-pack from cra","CVE":"CVE-2026-47734","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"47734","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Dulwich has unbounded memory allocation in receive-pack from cra"}]}}}