{"id":"CVE-2026-47734","aliases":["AZL-90077","CLSA-2026-1781484847","DEBIAN-CVE-2026-47734","EUVD-2026-36193","GHSA-xrvj-v92f-53gj","PYSEC-2026-2466","ROOT-APP-PYPI-CVE-2026-47734","SUSE-SU-2026:2984-1","SUSE-SU-2026:3117-1","UBUNTU-CVE-2026-47734"],"status":"published","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.","severity":{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00188,"percentile":0.08463,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400","CWE-789"],"published":"2026-06-08T23:43:42Z","modified":"2026-11-05T05:36:30Z","fixes":[{"ecosystem":"PyPI","package":"dulwich","fixed_in":["1.2.5"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:PyPI","package":"dulwich","fixed_in":["0.25.2.post4+tuxcare"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"dulwich","fixed_in":["1.2.5-1"],"sources":["osv"]},{"ecosystem":"Root:PyPI","package":"dulwich","fixed_in":["1.0.0+aikido.3","1.1.0+aikido.4","1.1.0+aikido.5","1.0.0+aikido.4"],"sources":["osv"]},{"ecosystem":"Root:PyPI","package":"rootio-dulwich","fixed_in":["1.0.0+root.io.3","1.1.0+root.io.4"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP7","package":"python3-dulwich","fixed_in":["0.20.24-150400.8.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Public Cloud 12","package":"python-dulwich","fixed_in":["0.18.5-4.6.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.0"},{"fixed":"1.2.5"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"python-dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.21.7-6"}]}]},{"source":"osv","ecosystem":"TuxCare:PyPI","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.25.2"},{"fixed":"0.25.2.post4+tuxcare"}]}],"versions":["0.25.2","0.25.2.post1+tuxcare","0.25.2.post2+tuxcare","0.25.2.post3+tuxcare"]},{"source":"osv","ecosystem":"Debian:12","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.21.2-1","0.21.5-1","0.21.6-1","0.22.5-1","0.22.7-1","0.22.7-2","0.24.10-1","0.24.2-1","0.24.2-2","1.0.0-1","1.0.0-2","1.1.0-1","1.1.0-2","1.1.0-3","1.2.0-1","1.2.1-1","1.2.11-1","1.2.12-1","1.2.5-1","1.2.7-1","1.2.7-2"]},{"source":"osv","ecosystem":"Debian:13","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.22.7-1","0.22.7-2","0.24.10-1","0.24.2-1","0.24.2-2","1.0.0-1","1.0.0-2","1.1.0-1","1.1.0-2","1.1.0-3","1.2.0-1","1.2.1-1","1.2.11-1","1.2.12-1","1.2.5-1","1.2.7-1","1.2.7-2"]},{"source":"osv","ecosystem":"Debian:14","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.5-1"}]}],"versions":["0.22.7-1","0.22.7-2","0.24.10-1","0.24.2-1","0.24.2-2","1.0.0-1","1.0.0-2","1.1.0-1","1.1.0-2","1.1.0-3","1.2.0-1","1.2.1-1"]},{"source":"osv","ecosystem":"PyPI","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.0"},{"fixed":"1.2.5"}]}],"versions":["0.1.0","0.1.1","0.10.0","0.10.1a","0.11.0","0.11.1","0.11.2","0.12.0","0.13.0","0.14.0","0.14.1","0.15.0","0.16.0","0.16.1","0.16.2","0.16.3","0.17.1","0.17.2","0.17.3","0.18.0","0.18.1","0.18.2","0.18.3","0.18.4","0.18.5","0.18.6","0.19.0","0.19.1","0.19.10","0.19.11","0.19.12","0.19.13","0.19.14","0.19.15","0.19.16","0.19.2","0.19.3","0.19.3a0","0.19.4","0.19.5","0.19.6","0.19.7","0.19.8","0.19.9","0.2.1","0.20.0","0.20.1","0.20.10","0.20.11","0.20.12","0.20.13","0.20.14","0.20.15","0.20.17","0.20.18","0.20.19","0.20.2","0.20.20","0.20.21","0.20.22","0.20.23","0.20.24","0.20.25","0.20.26","0.20.27","0.20.28","0.20.29","0.20.3","0.20.30","0.20.31","0.20.32","0.20.33","0.20.34","0.20.35","0.20.36","0.20.37","0.20.38","0.20.39","0.20.4","0.20.40","0.20.41","0.20.42","0.20.43","0.20.44","0.20.45","0.20.46","0.20.47","0.20.48","0.20.49","0.20.5","0.20.50","0.20.6","0.20.7","0.20.8","0.20.9","0.21.0","0.21.1","0.21.2","0.21.3","0.21.4","0.21.4.1","0.21.5","0.21.6","0.21.7","0.22.0","0.22.1","0.22.3","0.22.4","0.22.5","0.22.6","0.22.7","0.22.8","0.23.0","0.23.1","0.23.2","0.24.0","0.24.1","0.24.10","0.24.2","0.24.3","0.24.4","0.24.5","0.24.6","0.24.7","0.24.8","0.24.9","0.25.0","0.25.1","0.25.2","0.3.0","0.3.1","0.3.2","0.3.3","0.4.0","0.4.1","0.5.0","0.6.0","0.6.1","0.6.2","0.7.0","0.7.1","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.8.5","0.8.6","0.8.7","0.9.0","0.9.1","0.9.2","0.9.3","0.9.4","0.9.5","0.9.6","0.9.7","0.9.8","0.9.9","1.0.0","1.1.0","1.2.0","1.2.1","1.2.2","1.2.3","1.2.4"]},{"source":"osv","ecosystem":"PyPI","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.0"},{"fixed":"1.2.5"}]}],"versions":["0.1.0","0.1.1","0.10.0","0.10.1a","0.11.0","0.11.1","0.11.2","0.12.0","0.13.0","0.14.0","0.14.1","0.15.0","0.16.0","0.16.1","0.16.2","0.16.3","0.17.1","0.17.2","0.17.3","0.18.0","0.18.1","0.18.2","0.18.3","0.18.4","0.18.5","0.18.6","0.19.0","0.19.1","0.19.10","0.19.11","0.19.12","0.19.13","0.19.14","0.19.15","0.19.16","0.19.2","0.19.3","0.19.3a0","0.19.4","0.19.5","0.19.6","0.19.7","0.19.8","0.19.9","0.2.1","0.20.0","0.20.1","0.20.10","0.20.11","0.20.12","0.20.13","0.20.14","0.20.15","0.20.17","0.20.18","0.20.19","0.20.2","0.20.20","0.20.21","0.20.22","0.20.23","0.20.24","0.20.25","0.20.26","0.20.27","0.20.28","0.20.29","0.20.3","0.20.30","0.20.31","0.20.32","0.20.33","0.20.34","0.20.35","0.20.36","0.20.37","0.20.38","0.20.39","0.20.4","0.20.40","0.20.41","0.20.42","0.20.43","0.20.44","0.20.45","0.20.46","0.20.47","0.20.48","0.20.49","0.20.5","0.20.50","0.20.6","0.20.7","0.20.8","0.20.9","0.21.0","0.21.1","0.21.2","0.21.3","0.21.4","0.21.4.1","0.21.5","0.21.6","0.21.7","0.22.0","0.22.1","0.22.3","0.22.4","0.22.5","0.22.6","0.22.7","0.22.8","0.23.0","0.23.1","0.23.2","0.24.0","0.24.1","0.24.10","0.24.2","0.24.3","0.24.4","0.24.5","0.24.6","0.24.7","0.24.8","0.24.9","0.25.0","0.25.1","0.25.2","0.3.0","0.3.1","0.3.2","0.3.3","0.4.0","0.4.1","0.5.0","0.6.0","0.6.1","0.6.2","0.7.0","0.7.1","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.8.5","0.8.6","0.8.7","0.9.0","0.9.1","0.9.2","0.9.3","0.9.4","0.9.5","0.9.6","0.9.7","0.9.8","0.9.9","1.0.0","1.1.0","1.2.0","1.2.1","1.2.2","1.2.3","1.2.4"]},{"source":"osv","ecosystem":"Root:PyPI","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.0+aikido.3"},{"fixed":"1.1.0+aikido.4"},{"fixed":"1.1.0+aikido.5"},{"fixed":"1.0.0+aikido.4"}]}]},{"source":"osv","ecosystem":"Root:PyPI","package":"rootio-dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.0+root.io.3"},{"fixed":"1.1.0+root.io.4"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP7","package":"python3-dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.20.24-150400.8.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Public Cloud 12","package":"python-dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.18.5-4.6.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.11.2-1ubuntu1","0.12.0-1","0.12.0-1build1","0.12.0-1build2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.18.2-1build1","0.18.5-1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.19.11-2","0.19.14-4ubuntu1","0.19.15-1","0.19.15-1build1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.20.15-1ubuntu1","0.20.31-1ubuntu1","0.20.31-1.1","0.20.31-1.1build1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.21.6-1","0.21.6-1build1","0.21.6-1build2"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.22.7-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.0-3","1.2.12-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"dulwich","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.22.7-1","0.24.2-2","1.1.0-2ubuntu1","1.1.0-3"]}],"products":[{"vendor":"jelmer","product":"dulwich"}],"references":[{"url":"https://github.com/jelmer/dulwich/security/advisories/GHSA-xrvj-v92f-53gj","tags":["x_refsource_CONFIRM","advisory","web","report"]},{"url":"https://github.com/jelmer/dulwich/releases/tag/dulwich-1.2.5","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-47734","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-xrvj-v92f-53gj","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/47xxx/CVE-2026-47734.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-47734","tags":["advisory"]},{"url":"https://github.com/jelmer/dulwich","tags":["package"]},{"url":"https://pypi.org/project/dulwich","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20262984-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1268138","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-47734","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20263117-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-47734","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-47734","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-47734","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.","status":"published","published":"2026-06-10T22:11:02.704Z","modified":"2026-06-11T16:14:16.785Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T13:36:29.327819Z"}],"euvd":[{"id":"EUVD-2026-36193","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.","status":"published","published":"2026-06-10T22:11:02Z","modified":"2026-06-11T16:14:16Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T18:20:44.061211Z"}],"ghsa":[{"id":"GHSA-xrvj-v92f-53gj","title":"Dulwich has unbounded memory allocation in receive-pack from crafted thin packs","description":"## Impact\n\nAn uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).\n\nA 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.\n\nWho is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -\nfor example via dulwich.server functionality, the HTTP  smart server, or anything built on ReceivePackHandler. \n\n## Patches\n\nPatched in 1.2.5.\n\nadd_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.\n\nUsers 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.\n\n## Workarounds\n\nOn unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:\n\n- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.\n- 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.\n\n##  Resources\n\n- git's receive.maxInputSize / git index-pack --max-input-size documentation \n- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney","status":"published","published":"2026-06-08T23:43:42Z","modified":"2026-06-11T14:07:19Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T14:40:26.12116Z"}],"nvd":[{"id":"CVE-2026-47734","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.","status":"published","published":"2026-06-10T23:16:48.807Z","modified":"2026-07-23T09:10:00.113Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T14:12:23.485267Z"}],"osv":[{"id":"CVE-2026-47734","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.","status":"published","published":"2026-06-10T22:11:02.704Z","modified":"2026-10-28T02:30:50.059444226Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T15:45:06.231145Z"},{"id":"DEBIAN-CVE-2026-47734","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.","status":"published","published":"2026-06-10T23:16:48.807Z","modified":"2026-10-01T03:03:15.710646006Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:56.444225Z"},{"id":"GHSA-xrvj-v92f-53gj","title":"Dulwich has unbounded memory allocation in receive-pack from crafted thin packs","description":"## Impact\n\nAn uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).\n\nA 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.\n\nWho is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -\nfor example via dulwich.server functionality, the HTTP  smart server, or anything built on ReceivePackHandler. \n\n## Patches\n\nPatched in 1.2.5.\n\nadd_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.\n\nUsers 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.\n\n## Workarounds\n\nOn unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:\n\n- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.\n- 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.\n\n##  Resources\n\n- git's receive.maxInputSize / git index-pack --max-input-size documentation \n- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney","status":"published","published":"2026-06-08T23:43:42Z","modified":"2026-07-13T16:43:32.716665118Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400","CWE-789"],"updated_at":"2026-11-02T15:47:00.198893Z"},{"id":"PYSEC-2026-2466","title":"Dulwich has unbounded memory allocation in receive-pack from crafted thin packs","description":"## Impact\n\nAn uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).\n\nA 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.\n\nWho is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -\nfor example via dulwich.server functionality, the HTTP  smart server, or anything built on ReceivePackHandler. \n\n## Patches\n\nPatched in 1.2.5.\n\nadd_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.\n\nUsers 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.\n\n## Workarounds\n\nOn unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:\n\n- Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.\n- 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.\n\n##  Resources\n\n- git's receive.maxInputSize / git index-pack --max-input-size documentation \n- Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney","status":"published","published":"2026-07-13T15:46:15.665113Z","modified":"2026-07-13T16:31:41.594863437Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:52:55.961245Z"},{"id":"UBUNTU-CVE-2026-47734","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.","status":"published","published":"2026-06-10T23:16:00Z","modified":"2026-10-17T12:58:57.035713846Z","cvss":[{"version":"3.1","score":5.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:56:33.391918Z"},{"id":"AZL-90077","title":"CVE-2026-47734 affecting package python-dulwich 0.21.7-6","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.","status":"published","published":"2026-06-10T23:16:48Z","modified":"2026-11-05T05:36:30Z","updated_at":"2026-11-05T16:41:25.633663Z"},{"id":"CLSA-2026-1781484847","title":"TuxCare security update for dulwich (1 CVE)","description":"TuxCare rebuilt dulwich to address 1 CVE. Fixed in 0.25.2.post4+tuxcare.","status":"published","published":"2026-08-04T14:52:37Z","modified":"2026-10-15T09:48:01.240174196Z","updated_at":"2026-11-02T15:43:45.445699Z"},{"id":"ROOT-APP-PYPI-CVE-2026-47734","title":"CVE-2026-47734 in dulwich - Patched by Root","description":"Root has patched CVE-2026-47734 in the dulwich package for Root:PyPI. Multiple fixed versions available.","status":"published","published":"2026-08-10T11:39:57Z","modified":"2026-08-10T13:45:16.867093839Z","updated_at":"2026-11-02T15:53:28.259095Z"},{"id":"SUSE-SU-2026:2984-1","title":"Security update for python3-dulwich","description":"This update for python3-dulwich fixes the following issues:\n\n- CVE-2026-47734: Do not honour receive.maxInputSize to bound received packs (bsc#1268138)\n","status":"published","published":"2026-07-14T13:21:03Z","modified":"2026-07-15T10:00:09.165431108Z","updated_at":"2026-11-02T15:54:04.987808Z"},{"id":"SUSE-SU-2026:3117-1","title":"Security update for python-dulwich","description":"This update for python-dulwich fixes the following issue\n\n- CVE-2026-47734: Unbounded memory allocation in receive-pack from crafted thin packs (bsc#1268138).\n","status":"published","published":"2026-07-17T15:37:51Z","modified":"2026-07-18T08:45:13.973968934Z","updated_at":"2026-11-02T15:54:04.987808Z"}]}}