Skip to main content
VulnerabilityPublished Updated

CVE-2026-78680: NLTK · Uncontrolled search path when invoking the Graphviz 'dot' binary

Affects acronymSource GCVE Database

0
Compare

Not known to be exploited · CVSS 7.8 High : upgrade to 2.0.0_5 soon.

Data as of 30 Oct 2026, 07:30 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 2.0.0_5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 2 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade acronym to 2.0.0_5.

Affected software

ProductAffectedFixed in
Homebrewacronympkg:brew/acronymOther threatsAffected
  • >=2.0.0 <2.0.0_5
Fixed in
  • 2.0.0_5

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

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). Affected (<= 3.10.2): - `nltk.parse.dependencygraph.dot2img` — called `find_binary("dot")` but discarded the returned validated path and then ran the bare name `["dot", ...]`, so the validation had no effect. - `nltk.translate.api.AlignedSent._repr_svg_` — ran the bare name with no validation at all (IPython SVG rendering). 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. --- ## Attack demonstration Captured output, not illustrative. A `./dot` that writes a `PWNED` marker, planted in the CWD with `.` prepended to `PATH`. **The vulnerable behaviour (old bare-name exec):** ``` Control (OLD behavior) — bare ['dot'] in this dir with '.' on PATH: bare ['dot'] executed planted binary = True ``` **The patched functions refuse it:** ``` FIXED code, with ./dot planted and '.' on PATH: dependencygraph.dot2img : Exception "Cannot find the dot binary..." | planted-binary-executed=False safe AlignedSent._repr_svg_ : Exception "Cannot find the dot binary..." | planted-binary-executed=False safe ``` **And `find_binary` itself was attacked directly** (the fix trusts nothing else): ``` Attack 1: ./dot in CWD, no dot on PATH -> LookupError (refused) safe Attack 2: ./dot/dot (dir 'dot' holding 'dot') -> LookupError (refused) safe Attack 3: '.' on PATH + ./dot -> LookupError (refused) safe Attack 4: attacker-writable ABSOLUTE dir on PATH -> returned /…/evilbin/dot (absolute) ``` Attack 4 is out of scope: trusting an absolute directory that is already on `PATH` is the operating system's own trust model — an attacker who can write to a `PATH` directory owns the account regardless of NLTK. `find_binary` defends specifically against the CWD/relative injection that bare-name exec is vulnerable to (attacks 1–3), which is exactly what this fix inherits. Environment: python 3.13.7. `dot` is not required to reproduce — the planted binary is the payload.

References

Community reviews

Loading reviews…