Description

heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential 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 redis_host 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-09-27T02:17:25.663Z",
  "pubdate": "2026-09-27T02:17:25.663Z",
  "executiveSummary": "The vulnerability in heym (versions before 0.0.105) involves an improper authorization check within the Redis workflow node execution service.\nThe application fails to handle cases where credential authorization lookups return a null or invalid result, defaulting to a hardcoded connection configuration.\nThis flaw allows an authenticated workflow author to bypass access controls and establish a read/write connection to a Redis instance listening on the local loopback interface (localhost:6379).\nThe primary impact is unauthorized access to local Redis services, potentially leading to data exposure, command execution, or system manipulation depending on the service configuration.\nExploitation requires the attacker to be an authenticated workflow author who provides an unauthorized or non-existent credential ID.\nThe risk level is contingent upon the deployment environment; deployments utilizing a local Redis service are at the highest risk, while those without one may only encounter connection errors.\nNo external network access is required for exploitation as it leverages the server's internal loopback interface.",
  "technicalDetails": "The vulnerability originates in 'backend/app/services/node_execution/nodes/redis_node.py'. The logic within this file fails to validate the outcome of the '_get_accessible_credential' function call.\nWhen '_get_accessible_credential' returns 'None' due to missing credentials, unauthorized access requests, or empty configuration profiles, the application logic incorrectly treats this outcome as an implicit instruction to utilize default connection settings rather than terminating the request or raising an authorization error.\nThe hardcoded fallback configuration defaults to connecting to 'localhost:6379' without authentication credentials. This occurs because the connection logic fails to implement a 'fail-safe' or 'deny-by-default' mechanism when credential retrieval fails.\nThe attack flow follows a specific sequence: First, an authenticated attacker initiates a workflow request supplying a manipulated, non-existent, or unauthorized credential ID. Second, the backend logic executes the Redis node code, triggering the '_get_accessible_credential' function which subsequently returns 'None'. Third, instead of processing an error condition, the application proceeds to initialize a Redis client using the default local connection parameters.\nOnce the connection is established to the local Redis instance, the attacker can execute arbitrary Redis commands. If the Redis service is running with administrative privileges or lacks access controls on the loopback interface, the attacker can read, modify, or delete sensitive data stored in Redis. Furthermore, depending on the Redis configuration (such as the availability of specific modules or persistence mechanisms), this access may facilitate lateral movement or remote code execution within the container or host environment.\nThe issue is exacerbated by the fact that the application does not differentiate between a legitimate 'default' configuration and a 'failure to authenticate' state. This ambiguity allows the Redis node to establish a persistent socket connection to the local interface, granting the attacker the same authority as the application service itself when communicating with the local Redis daemon.\nAffected versions include all heym installations prior to 0.0.105. The vulnerability requires the attacker to possess authenticated access to the workflow authoring interface, as the exploitation is triggered via workflow node configuration and execution."
}