<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T07:34:49.259933+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-47712</id>
    <title>CVE-2026-47712 — Dulwich doesn't sanitize commit subjects in `porcelain.format_patch`</title>
    <updated>2026-09-29T07:34:49.313816+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> jelmer dulwich</p>
<p>Dulwich is a pure-Python implementation of the Git file formats and protocols. Starting in version 0.24.0 and prior to version 1.2.5, dulwich.porcelain.format_patch(outdir=...) derives each patch filename from the commit's subject line. Prior to this fix, get_summary only replaced spaces with dashes - path separators (/, \), parent-directory components (..), and other filename-hostile characters (e.g. :) were preserved verbatim and passed straight into os.path.join(outdir, f"{i:04d}-{summary}.patch"). A malicious commit subject could therefore direct the generated patch file outside the requested outdir. This is fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later. dulwich.patch.get_summary now mirrors git's format_sanitized_subject: only `[A-Za-z0-9._]` are kept, runs of other characters collapse to a single -, consecutive . collapse to a single ., trailing ./- are stripped, and the result is length-limited. This makes the returned string safe to embed as a filename component, so format_patch can no longer be steered out of outdir via the commit subject. Until upgrading, callers that pass untrusted commits to   porcelain.format_patch can use stdout=True and write the patch to a destination they control, rather than letting format_patch choose the filename; validate the chosen path before opening - e.g. compare os.path.realpath(returned_path) against  os.path.realpath(outdir) and reject any patch whose resolved path is not inside outdir; and/or pre-screen commits a…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-47712"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-555p-6grf-mh7f</id>
    <title>GHSA-555p-6grf-mh7f — Dulwich doesn't sanitize commit subjects in `porcelain.format_patch`</title>
    <updated>2026-09-29T07:34:49.314011+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: dulwich</p>
<p>### Impact</p>
<p>dulwich.porcelain.format_patch(outdir=...) derives each patch filename from the commit's subject line. Prior to this fix, get_summary only replaced spaces with dashes - path separators (/, \),   parent-directory components (..), and   other filename-hostile characters (e.g. :)  were preserved verbatim and passed   straight into os.path.join(outdir,   f"{i:04d}-{summary}.patch").</p>
<p>A malicious commit subject could therefore direct the generated patch file outside the requested outdir. Reduced examples:</p>
<p>- x/../../x produced &lt;outdir&gt;/0001-x/../../x.patch, resolving
  two directories above outdir.
- x\..\..\x produced the equivalent escape on Windows, here \ is also a path separator.</p>
<p>Related issues from the same root cause:</p>
<p>- Subjects containing characters that are illegal in Windows filenames (e.g. :) caused format_patch to fail outright on  Windows, where git would have succeeded.
- Very long subjects produced excessively long filenames that could exceed filesystem limits; git truncates them.</p>
<p>Anyone calling porcelain.format_patch (or the dulwich format-patch CLI) against untrusted commits - for example, a service that runs format-patch over user-supplied repositories or pull requests - could have patch files written to attacker-chosen locations within the process's write permissions.</p>
<p>### Patches</p>
<p>Fixed in Dulwich 1.2.5. Users should upgrade.</p>
<p>dulwich.patch.get_summary now mirrors git's format_sanitized_subject: only `[A-Za-z0-9._]` are kept, runs of other char…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-555p-6grf-mh7f"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2026-2462</id>
    <title>PYSEC-2026-2462 — Dulwich doesn't sanitize commit subjects in `porcelain.format_patch`</title>
    <updated>2026-09-29T07:34:49.314114+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: dulwich</p>
<p>### Impact</p>
<p>dulwich.porcelain.format_patch(outdir=...) derives each patch filename from the commit's subject line. Prior to this fix, get_summary only replaced spaces with dashes - path separators (/, \),   parent-directory components (..), and   other filename-hostile characters (e.g. :)  were preserved verbatim and passed   straight into os.path.join(outdir,   f"{i:04d}-{summary}.patch").</p>
<p>A malicious commit subject could therefore direct the generated patch file outside the requested outdir. Reduced examples:</p>
<p>- x/../../x produced &lt;outdir&gt;/0001-x/../../x.patch, resolving
  two directories above outdir.
- x\..\..\x produced the equivalent escape on Windows, here \ is also a path separator.</p>
<p>Related issues from the same root cause:</p>
<p>- Subjects containing characters that are illegal in Windows filenames (e.g. :) caused format_patch to fail outright on  Windows, where git would have succeeded.
- Very long subjects produced excessively long filenames that could exceed filesystem limits; git truncates them.</p>
<p>Anyone calling porcelain.format_patch (or the dulwich format-patch CLI) against untrusted commits - for example, a service that runs format-patch over user-supplied repositories or pull requests - could have patch files written to attacker-chosen locations within the process's write permissions.</p>
<p>### Patches</p>
<p>Fixed in Dulwich 1.2.5. Users should upgrade.</p>
<p>dulwich.patch.get_summary now mirrors git's format_sanitized_subject: only `[A-Za-z0-9._]` are kept, runs of other char…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2026-2462"/>
  </entry>
</feed>
