CVE-2026-100860 in heym
Summary
by MITRE • 09/27/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in Heymon versions prior to 0.0.105 represents a critical logic flaw within the backend service's handling of credential authorization for Redis workflow nodes. The core issue resides in the file path backend/app/services/node_execution/nodes/redis_node.py, where the system fails to properly validate the outcome of its credential lookup process. When an authenticated user attempts to execute a workflow node that requires Redis connectivity, the application invokes the _get_accessible_credential function to verify if the provided credential ID is valid and authorized for use by the current caller. However, instead of treating a null return value from this function as a fatal authorization error, the code incorrectly interprets it as an indication that no specific configuration was provided. This misinterpretation triggers a fallback mechanism designed for cases where users intentionally omit custom settings, causing the application to default to connecting to localhost on port 6379 without any authentication credentials.
This behavior creates a severe security bypass scenario because it allows authenticated workflow authors to access internal infrastructure resources that they should not have permission to reach. If an attacker or malicious insider supplies a credential ID that does not exist, has been deleted, or simply belongs to another user, the system ignores this mismatch and proceeds with the default connection parameters. Consequently, if the backend server is running a Redis instance on its loopback interface, which is common in many development and some production environments for internal service communication, the attacker gains unrestricted read and write access to that database. This effectively circumvents authentication controls intended to isolate data between different users or tenants within the application ecosystem.
The operational impact of this vulnerability is heavily dependent on the specific deployment architecture of the Heymon instance. In standard docker-compose setups provided by the vendor, no Redis server is typically configured for external access, meaning that attempting to exploit this flaw would result in a connection refused error rather than successful data exfiltration. However, in environments where Redis is deployed locally on the backend host and bound to 127.0.0.1 or similar loopback addresses, the consequences are severe. An attacker could potentially read sensitive session tokens, cached user data, queue jobs containing private information, or even inject malicious commands if the application logic permits write operations through this node type. This represents a significant risk of unauthorized data access and potential lateral movement within the internal network segment connected to the backend server.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify identity before granting access to resources. It also relates closely to CWE-915, specifically the Improper Control of Dynamically-Identified Variables, where the application incorrectly handles dynamically loaded configuration data by applying unsafe defaults instead of rejecting invalid inputs. In terms of attack vectors and tactics, this flaw facilitates privilege escalation within the context of the backend service and could be leveraged in conjunction with ATT&CK technique T1078, Valid Accounts, if an attacker first obtains low-level authentication to create workflows containing malicious Redis nodes. The lack of strict validation on credential lookups allows for a straightforward exploitation path that does not require complex bypasses or zero-day exploits against the underlying infrastructure.
To mitigate this vulnerability, immediate updates to version 0.0.105 or later are required, as these versions contain fixes for the logic error in the Redis node execution service. For organizations unable to patch immediately due to operational constraints, several defensive measures can be implemented at the network and application levels. Network segmentation should ensure that any internal Redis instances bound to loopback interfaces do not accept connections from untrusted sources or are isolated within a secure container environment where only authorized backend processes can reach them. Additionally, implementing strict input validation on credential IDs before they enter the workflow execution engine would prevent the triggering of this fallback logic. Security teams should also audit their deployment configurations to ensure that no sensitive data is stored in Redis instances accessible via default localhost connections without robust authentication mechanisms enabled at the database level itself.