heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node…
Source GCVE Database
Not known to be exploited · CVSS 6.8 Medium : upgrade to 0.0.105 when convenient.
Data as of 8 Nov 2026, 23:24 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 13% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.0.105
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:NExploitation evidence
t = 0 is the CVE’s publication on cve.org
Disclosed: evidence found.
CVE published 27 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
CISA SSVC: proof of concept public
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
Timeline
CVE ID reserved
by VulnCheck
, 1 hour before disclosure
CVE published
on cve.org
, t = 0
CISA SSVC assessment
proof of concept public
, 39 hours after disclosure
In Threat Radar
record ingested
, 29 days after disclosure
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), CISA SSVC, the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.
What to do
Upgrade heym to 0.0.105.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| heymrunheym | Affected
| Fixed in
|
AI-suggested
If you cannot patch yet, avoid running Redis on the backend's loopback interface without proper authentication or restrict workflow authors' ability to supply arbitrary credential IDs.
Description
heym versions before 0.0.105 have a vulnerability in the Redis workflow node where the system does not properly handle failed credential authorization lookups. Instead of returning an error when a credential ID is invalid or unauthorized, the node falls back to connecting to Redis on localhost:6379 without authentication. This can allow an authenticated workflow author to gain unintended read/write access to a local Redis instance if one is running. The impact varies depending on deployment; for example, the default docker-compose setup does not include Redis, resulting only in misleading connection errors rather than data exposure.