CVE-2026-64847: Gptme · AnyIO process-pool workers can block indefinitely on undrained stderr
Affects gptmeSource GCVE Database
Not known to be exploited · CVSS 6.8 Medium : upgrade to 0.32.1 when convenient.
Data as of 4 Nov 2026, 21:27 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 4% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.32.1
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 18 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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 4 Nov 2026.
What to do
Upgrade gptme to 0.32.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewgptmepkg:brew/gptmeOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A patch is available in gptme version 0.32.1 that fixes this issue. Users should upgrade to this version to remediate the vulnerability. As a workaround, closing sys.stderr in the target function can prevent the deadlock until the patch is applied.
Description
The gptme product has a vulnerability in its use of AnyIO process-pool workers where stderr is connected to a pipe but not drained. This can cause the pipe to fill and block indefinitely if the worker writes enough data to stderr, leading to a deadlock. The issue affects versions from 0.19.1 up to but not including 0.32.1. A fix is available in version 0.32.1. Users running untrusted or faulty code that writes heavily to stderr are at risk. A workaround is to close sys.stderr in the target function to prevent deadlock.
References
- github.com/agronholm/anyio/security/advisories/GHSA-5p39-cfhj-2xmp (opens in a new tab)
- github.com/agronholm/anyio/pull/1207 (opens in a new tab)
- github.com/agronholm/anyio/commit/f1b7301c8264b0d2e8d24a5788fd29e93dea4040 (opens in a new tab)
- github.com/agronholm/anyio (opens in a new tab)
- github.com/agronholm/anyio/releases/tag/4.14.2 (opens in a new tab)