<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 14:59:59 +0000</lastBuildDate>
    <item>
      <title>BREW-acronym-CVE-2026-78680 — NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary</title>
      <link>https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-78680</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: acronym&lt;/p&gt;
&lt;p&gt;Two NLTK sites executed the Graphviz `dot` program by bare name, so process creation resolved it via the search path — and on Windows via the current working directory — rather than a validated absolute location. An attacker who can place a file named `dot` where resolution looks (the CWD on Windows, or a writable/relative entry such as `.` on `PATH`) has their binary executed in place of Graphviz (arbitrary code execution).&lt;/p&gt;
&lt;p&gt;Affected (&amp;lt;= 3.10.2):
- `nltk.parse.dependencygraph.dot2img` — called `find_binary(&amp;#34;dot&amp;#34;)` but discarded the returned validated path and then ran the bare name `[&amp;#34;dot&amp;#34;, ...]`, so the validation had no effect.
- `nltk.translate.api.AlignedSent._repr_svg_` — ran the bare name with no validation at all (IPython SVG rendering).&lt;/p&gt;
&lt;p&gt;This is the same class already fixed for the senna, weka, boxer, malt, repp and hunpos wrappers. `nltk.internals.find_binary` refuses a CWD-relative match for a bare tool name and returns only a trusted absolute path; the fix runs that path in both sites.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration
Captured output, not illustrative. A `./dot` that writes a `PWNED` marker, planted in the CWD with `.` prepended to `PATH`.&lt;/p&gt;
&lt;p&gt;**The vulnerable behaviour (old bare-name exec):**
```
Control (OLD behavior) — bare [&amp;#39;dot&amp;#39;] in this dir with &amp;#39;.&amp;#39; on PATH:
  bare [&amp;#39;dot&amp;#39;] executed planted binary = True
```&lt;/p&gt;
&lt;p&gt;**The patched functions refuse it:**
```
FIXED code, with ./dot planted and &amp;#39;.&amp;#39; on PATH:
  dependencygraph.dot2img : Exception &amp;#34;Cannot find the dot binary...…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: acronym&lt;/p&gt;
&lt;p&gt;Two NLTK sites executed the Graphviz `dot` program by bare name, so process creation resolved it via the search path — and on Windows via the current working directory — rather than a validated absolute location. An attacker who can place a file named `dot` where resolution looks (the CWD on Windows, or a writable/relative entry such as `.` on `PATH`) has their binary executed in place of Graphviz (arbitrary code execution).&lt;/p&gt;
&lt;p&gt;Affected (&amp;lt;= 3.10.2):
- `nltk.parse.dependencygraph.dot2img` — called `find_binary(&amp;#34;dot&amp;#34;)` but discarded the returned validated path and then ran the bare name `[&amp;#34;dot&amp;#34;, ...]`, so the validation had no effect.
- `nltk.translate.api.AlignedSent._repr_svg_` — ran the bare name with no validation at all (IPython SVG rendering).&lt;/p&gt;
&lt;p&gt;This is the same class already fixed for the senna, weka, boxer, malt, repp and hunpos wrappers. `nltk.internals.find_binary` refuses a CWD-relative match for a bare tool name and returns only a trusted absolute path; the fix runs that path in both sites.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration
Captured output, not illustrative. A `./dot` that writes a `PWNED` marker, planted in the CWD with `.` prepended to `PATH`.&lt;/p&gt;
&lt;p&gt;**The vulnerable behaviour (old bare-name exec):**
```
Control (OLD behavior) — bare [&amp;#39;dot&amp;#39;] in this dir with &amp;#39;.&amp;#39; on PATH:
  bare [&amp;#39;dot&amp;#39;] executed planted binary = True
```&lt;/p&gt;
&lt;p&gt;**The patched functions refuse it:**
```
FIXED code, with ./dot planted and &amp;#39;.&amp;#39; on PATH:
  dependencygraph.dot2img : Exception &amp;#34;Cannot find the dot binary...…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-acronym-cve-2026-78680</guid>
    </item>
    <item>
      <title>CVE-2026-78680 — NLTK before 3.10.3 Arbitrary Code Execution via Graphviz dot Binary</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-78680</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nltk&lt;/p&gt;
&lt;p&gt;NLTK versions before 3.10.3 fail to use validated absolute paths when invoking the Graphviz dot binary in dependencygraph.dot2img and AlignedSent._repr_svg_, allowing attackers to execute arbitrary code by placing a malicious dot binary in the search path or current working directory. Attackers can exploit bare-name binary resolution on Windows via the current working directory or on Unix-like systems via relative PATH entries to execute their binary instead of the legitimate Graphviz tool.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; nltk&lt;/p&gt;
&lt;p&gt;NLTK versions before 3.10.3 fail to use validated absolute paths when invoking the Graphviz dot binary in dependencygraph.dot2img and AlignedSent._repr_svg_, allowing attackers to execute arbitrary code by placing a malicious dot binary in the search path or current working directory. Attackers can exploit bare-name binary resolution on Windows via the current working directory or on Unix-like systems via relative PATH entries to execute their binary instead of the legitimate Graphviz tool.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-78680</guid>
    </item>
    <item>
      <title>GHSA-6hwm-xvph-95vm — NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6hwm-xvph-95vm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: nltk&lt;/p&gt;
&lt;p&gt;Two NLTK sites executed the Graphviz `dot` program by bare name, so process creation resolved it via the search path — and on Windows via the current working directory — rather than a validated absolute location. An attacker who can place a file named `dot` where resolution looks (the CWD on Windows, or a writable/relative entry such as `.` on `PATH`) has their binary executed in place of Graphviz (arbitrary code execution).&lt;/p&gt;
&lt;p&gt;Affected (&amp;lt;= 3.10.2):
- `nltk.parse.dependencygraph.dot2img` — called `find_binary(&amp;#34;dot&amp;#34;)` but discarded the returned validated path and then ran the bare name `[&amp;#34;dot&amp;#34;, ...]`, so the validation had no effect.
- `nltk.translate.api.AlignedSent._repr_svg_` — ran the bare name with no validation at all (IPython SVG rendering).&lt;/p&gt;
&lt;p&gt;This is the same class already fixed for the senna, weka, boxer, malt, repp and hunpos wrappers. `nltk.internals.find_binary` refuses a CWD-relative match for a bare tool name and returns only a trusted absolute path; the fix runs that path in both sites.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration
Captured output, not illustrative. A `./dot` that writes a `PWNED` marker, planted in the CWD with `.` prepended to `PATH`.&lt;/p&gt;
&lt;p&gt;**The vulnerable behaviour (old bare-name exec):**
```
Control (OLD behavior) — bare [&amp;#39;dot&amp;#39;] in this dir with &amp;#39;.&amp;#39; on PATH:
  bare [&amp;#39;dot&amp;#39;] executed planted binary = True
```&lt;/p&gt;
&lt;p&gt;**The patched functions refuse it:**
```
FIXED code, with ./dot planted and &amp;#39;.&amp;#39; on PATH:
  dependencygraph.dot2img : Exception &amp;#34;Cannot find the dot binary...…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: nltk&lt;/p&gt;
&lt;p&gt;Two NLTK sites executed the Graphviz `dot` program by bare name, so process creation resolved it via the search path — and on Windows via the current working directory — rather than a validated absolute location. An attacker who can place a file named `dot` where resolution looks (the CWD on Windows, or a writable/relative entry such as `.` on `PATH`) has their binary executed in place of Graphviz (arbitrary code execution).&lt;/p&gt;
&lt;p&gt;Affected (&amp;lt;= 3.10.2):
- `nltk.parse.dependencygraph.dot2img` — called `find_binary(&amp;#34;dot&amp;#34;)` but discarded the returned validated path and then ran the bare name `[&amp;#34;dot&amp;#34;, ...]`, so the validation had no effect.
- `nltk.translate.api.AlignedSent._repr_svg_` — ran the bare name with no validation at all (IPython SVG rendering).&lt;/p&gt;
&lt;p&gt;This is the same class already fixed for the senna, weka, boxer, malt, repp and hunpos wrappers. `nltk.internals.find_binary` refuses a CWD-relative match for a bare tool name and returns only a trusted absolute path; the fix runs that path in both sites.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Attack demonstration
Captured output, not illustrative. A `./dot` that writes a `PWNED` marker, planted in the CWD with `.` prepended to `PATH`.&lt;/p&gt;
&lt;p&gt;**The vulnerable behaviour (old bare-name exec):**
```
Control (OLD behavior) — bare [&amp;#39;dot&amp;#39;] in this dir with &amp;#39;.&amp;#39; on PATH:
  bare [&amp;#39;dot&amp;#39;] executed planted binary = True
```&lt;/p&gt;
&lt;p&gt;**The patched functions refuse it:**
```
FIXED code, with ./dot planted and &amp;#39;.&amp;#39; on PATH:
  dependencygraph.dot2img : Exception &amp;#34;Cannot find the dot binary...…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6hwm-xvph-95vm</guid>
    </item>
  </channel>
</rss>
