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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-47734)

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2026 advisory.

    Dulwich through 1.1.0 was found to be missing SSH host key verification in contrib/paramiko_vendor.py.
    (CVE-2026-38974)

    Arbitrary file write leading to remote code execution when cloning or checking out a malicious Git     repository on Windows.

    Dulwich's path-element validator accepted tree entries whose filenames contained bytes that Windows     interprets as structural path syntax:

    \ -- the Windows path separator. A single tree entry named .git\hooks\pre-commit.exe was treated as one     valid filename on POSIX but materialized as nested directories .git/hooks/pre-commit.exe on Windows,     planting a file inside the victim's .git directory. Git for Windows thenexecutes that hook on the next git     commit, giving the attacker arbitrary code execution in the victim's user context. The same primitive can     be used with ..\outside.txt to escape the work tree.: -- the NTFS alternate-data-stream marker.
    .git::$INDEX_ALLOCATION writes directly into the victim's .git entity, bypassing the .git-as-a-directory     check.git~ -- NTFS 8.3 short-name aliases of .git. Only the literal git1 was rejected; git2, git10, GIT1,     etc. were all accepted.Contributing configuration bugs made matters worse. The core.protectNTFS and     core.protectHFS settings were looked up under a wrong option name and so user-set values were silently     ignored, and core.protectNTFS only defaulted to true on Windows (Git upstream has defaulted it to true     everywhere since CVE-2019-1353). Both have been corrected.

    Anyone who clones, fetches, or checks out an untrusted repository with Dulwich on Windows - either through     the Dulwich CLI, porcelain.clone, or any downstream tool built on Dulwich - is impacted. POSIX clones are     not directly exploitable (on POSIX \ is a literal filename byte), but a POSIX user can unknowingly     propagate a malicious tree to Windows consumers via push or re-publication. (CVE-2026-42305)

    An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 /     CWE-789).

    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.

    Who is impacted: 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. (CVE-2026-47734)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLES12 / SLES_SAP12 host has a package installed that is affected by a vulnerability as referenced in the SUSE-SU-2026:3117-1 advisory.

    This update for python-dulwich fixes the following issue

    - CVE-2026-47734: Unbounded memory allocation in receive-pack from crafted thin packs (bsc#1268138).

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has a package installed that is affected by a vulnerability as referenced in the SUSE-SU-2026:2984-1 advisory.

    - CVE-2026-47734: Do not honour receive.maxInputSize to bound received packs (bsc#1268138)

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Fedora 44 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-fbd55e52fb advisory.

    1.2.9, CVE fixes

Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-47734)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
473058	Chainguard: request-1276: security update to 0.30.1-r3	Tenable Cloud Security	Chainguard Local Security Checks	Local	medium
473058	Chainguard: request-1276: security update to 0.30.1-r3	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	Local	medium
460970	Echo: dulwich: security update to 1.2.5	Tenable Cloud Security	Echo Local Security Checks	Local	medium
460970	Echo: dulwich: security update to 1.2.5	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
332007	Amazon Linux 2023 : python3-dulwich (ALAS2023-2026-2026)	Nessus	Amazon Linux Local Security Checks	Local	high
327732	SUSE SLES12 Security Update : python-dulwich (SUSE-SU-2026:3117-1)	Nessus	SuSE Local Security Checks	Local	medium
326940	SUSE SLED15 / SLES15 Security Update : python3-dulwich (SUSE-SU-2026:2984-1)	Nessus	SuSE Local Security Checks	Local	medium
326391	Fedora 44 : python-dulwich (2026-fbd55e52fb)	Nessus	Fedora Local Security Checks	Local	high
443077	SCA: security update for dulwich (GHSA-xrvj-v92f-53gj)	Tenable Cloud Security	SCA Checks	Local	medium
443077	SCA: security update for dulwich (GHSA-xrvj-v92f-53gj)	Tenable Self-Hosted Container Security	SCA Checks	Local	medium
317719	Linux Distros Unpatched Vulnerability : CVE-2026-47734	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-47734

medium

Tenable Plugins

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium