CVE-2026-110873 in heym
Summary
by MITRE • 10/15/2026
Heym from 0.0.55 before 0.0.121 contains a privilege escalation vulnerability that allows shared collaborators to overwrite a workflow's error_workflow_id because the field is missing from OWNER_ONLY_EXECUTION_FIELDS. Attackers can point the error workflow to their own workflow with an HTTP node, and when the parent workflow errors the owner's decrypted credentials are injected and exfiltrated.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Heym versions prior to 0.0.121 represents a critical privilege escalation flaw rooted in insufficient access control mechanisms within the application's workflow management logic. Specifically, the defect lies in the handling of shared collaborative workflows where permissions are not strictly enforced for all mutable fields. The core technical issue is that the field error_workflow_id was omitted from the OWNER_ONLY_EXECUTION_FIELDS configuration list. This omission creates a logical gap wherein users with collaborator-level access can modify attributes intended to be restricted exclusively to workflow owners. By leveraging this misconfiguration, an attacker who has been granted shared collaboration rights on a target workflow gains the ability to alter critical execution parameters that should remain immutable under normal collaborative operations.
The operational impact of this vulnerability is severe and directly leads to credential exfiltration through a chain of exploitation steps. An attacker with collaborator privileges can modify the error_workflow_id field to point toward a maliciously controlled workflow hosted by the attacker. When the original parent workflow encounters an execution failure, it triggers the specified error handling mechanism, which in turn executes the attacker's designated workflow. This secondary workflow is crafted specifically to intercept and capture sensitive data generated during the parent workflow's operation. Because the parent workflow operates under the context of its owner, any actions performed within this triggered chain inherit those elevated privileges.
The exploitation technique relies on the injection of decrypted credentials into the execution environment of the attacker-controlled workflow. As the error handling routine runs, it processes variables and secrets associated with the original workflow's configuration. The attacker’s workflow is designed to access these injected values, effectively bypassing standard security boundaries that would otherwise protect such sensitive information from lower-privileged users. This results in the unauthorized disclosure of credentials that were intended to be accessible only by the workflow owner, compromising the confidentiality and integrity of downstream systems connected via HTTP nodes or other integrations defined within the workflow structure.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as it involves an actor obtaining privileges they are not authorized to possess through a configuration error. Furthermore, the technique maps directly to MITRE ATT&CK tactic T1078 Valid Accounts and sub-technique T1534 Internal Spearphishing or lateral movement via trusted relationships, although in this context, it is more accurately described as privilege escalation within an application environment leading to data exfiltration. The attack vector exploits the trust relationship between workflows and their execution contexts rather than traditional network-based intrusion methods.
To mitigate this vulnerability, organizations must immediately upgrade Heym to version 0.0.121 or later where the error_workflow_id field has been correctly added to the OWNER_ONLY_EXECUTION_FIELDS list. This ensures that only users with owner-level permissions can modify critical execution parameters related to error handling workflows. Additionally, implementing strict input validation and access control checks for all workflow modification endpoints is essential. Security teams should also audit existing shared workflows to identify any instances where collaborators may have already exploited this flaw by pointing error handlers to external or malicious destinations. Regular security assessments focusing on role-based access controls in automation platforms can help prevent similar misconfigurations that lead to privilege escalation and credential theft.