CVE-2026-100860: heym before 0.0.105 Authentication Bypass via Redis Node
heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/nodeexecution/nodes/redisnode.py). When getaccessiblecredential returns None — because the credential ID does not exist or the caller is not authorized to use it — the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redishost value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend's loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
heymto a version that resolves this vulnerability.Fixed in 0.0.105
Event History
Frequently Asked Questions
Which deployments are meaningfully exposed?
Deployments are exposed when a Redis service is listening on the Heym backend's loopback interface at localhost:6379 and accepts unauthenticated connections. The stock docker-compose.yml does not ship Redis, so affected workflow executions there produce a misleading connection error rather than exposing Redis data.
What does an attacker need to exploit this issue?
An attacker needs to be an authenticated workflow author and be able to configure a Redis workflow node. They can provide a credential ID they are not authorized to use, a deleted credential ID, or use an accessible credential with empty configuration or no redis_host value.
What happens when the unauthorized or missing credential is used?
Instead of rejecting the credential lookup failure, the Redis node falls back to an empty configuration. It then connects to localhost:6379 without a password and performs the requested Redis operation, potentially with read and write access.
How can administrators determine whether the issue could have exposed Redis?
Check whether Redis was listening on the backend host's loopback interface at port 6379 without a password during use of the Redis workflow node. Also review workflows using Redis nodes for credential IDs that were unauthorized, deleted, empty, or missing a redis_host value.