CVE-2026-100865 in Heym
Summary
by MITRE • 09/27/2026
Heym before 0.0.53 contains multiple independent vulnerabilities. (1) The workflow condition evaluator uses Python eval() without an effective sandbox, allowing any user who can edit a workflow branch/condition node — or who can import a workflow template containing a malicious condition node — to execute arbitrary Python code as the backend process user when the workflow runs. (2) Slack webhook signature verification and (3) Telegram webhook secret-token verification fail open when the trigger node has no credentialId or an empty signing secret, allowing anyone who knows the public webhook URL to trigger workflows with the owner's credentials without authentication. (4) The OAuth authorization endpoint does not validate the redirect_uri scheme, so an attacker who registers a public OAuth client with a javascript: or data: redirect_uri and lures a victim to the consent screen receives the authorization code and executes attacker-controlled JavaScript in the Heym origin, including access to the victim's HttpOnly auth cookie. (5) WorkflowExecutionToken, PortalSession, HITLRequest.public_token, and OAuthAuthorizationCode values are stored in plaintext, so any database read exposure yields valid scoped bearer tokens, including portal and HITL tokens with a 168-hour TTL that permit workflow execution on behalf of the owner.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/27/2026
The Heym application prior to version 0.0.53 suffers from multiple critical security vulnerabilities stemming from inadequate input validation, weak authentication mechanisms, and improper data handling practices. These flaws collectively undermine the integrity, confidentiality, and availability of the platform by allowing unauthorized code execution, unauthenticated workflow triggers, cross-site scripting via OAuth flows, and credential theft through database exposure. The severity of these issues is compounded by their independence; an attacker does not need to chain multiple vulnerabilities to achieve significant impact, as each flaw represents a distinct attack vector that can be exploited separately depending on the threat model and access level available to the adversary.
The most severe vulnerability involves improper neutralization of special elements used in an OS command or Python code injection within the workflow condition evaluator. Specifically, the system utilizes Python's eval function without implementing an effective sandboxing mechanism. This architectural flaw allows any user with permission to edit a workflow branch or condition node, as well as users who can import malicious workflow templates containing harmful condition nodes, to execute arbitrary Python code under the context of the backend process user when the workflow is triggered. This represents a classic case of insecure deserialization and command injection where untrusted input is directly evaluated by the interpreter. The impact is catastrophic, granting attackers full control over the server hosting the Heym instance, potentially leading to complete system compromise, data exfiltration, or lateral movement within the internal network. This vulnerability aligns with CWE-94 Improper Control of Generation of Code and CWE-78 OS Command Injection in its broader implications for backend integrity.
In addition to code execution risks, the platform exhibits significant failures in authentication verification for webhook integrations. The Slack webhook signature verification process and the Telegram webhook secret-token verification mechanism fail open when specific configuration conditions are met. Specifically, if a trigger node lacks a credentialId or contains an empty signing secret, the system accepts requests without validating their authenticity. This allows any individual who discovers the public webhook URL to forge valid-looking requests and trigger workflows using the owner's credentials. This behavior violates fundamental principles of secure authentication design where default configurations should never bypass security checks. It corresponds directly to CWE-287 Improper Authentication, as the system fails to reliably verify the identity of users or services attempting to access resources. The operational impact includes unauthorized automation execution, potential data leakage through automated workflows, and abuse of integrated service accounts for malicious purposes such as spamming or resource exhaustion.
Further compromising user security is a flaw in the OAuth authorization endpoint that permits cross-site scripting attacks via redirect URI manipulation. The application does not validate the scheme of the redirect_uri parameter during the OAuth flow. An attacker can register a public OAuth client configured with a javascript: or data: URL as the redirect target. By luring a victim to consent screen, where they authorize the malicious application, the authorization code is returned via the crafted URI rather than a legitimate web address. This results in the execution of attacker-controlled JavaScript within the Heym origin context. Because this script runs with the same privileges and domain permissions as the main application, it can access sensitive data including HttpOnly authentication cookies if not properly isolated or if session management policies are insufficiently strict regarding cookie attributes like SameSite. This vulnerability is a variant of CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-Site Scripting (XSS), specifically leveraging OAuth misconfiguration to bypass same-origin policy protections and steal session tokens.
The final major issue involves the insecure storage of sensitive authentication artifacts, including WorkflowExecutionToken, PortalSession identifiers, HITLRequest.public_token values, and OAuthAuthorizationCode strings. These critical security credentials are stored in plaintext within the database rather than being hashed or encrypted using strong cryptographic standards. Consequently, any vulnerability that allows for unauthorized read access to the underlying database—such as SQL injection, misconfigured file permissions, or insider threats with direct DB access—results in immediate compromise of these tokens. The WorkflowExecutionToken and PortalSession possess a time-to-live (TTL) of 168 hours, meaning stolen credentials remain valid for over seven days. This allows attackers to execute workflows on behalf of the victim or access portal functionalities without needing to re-authenticate. This failure aligns with CWE-319 Cleartext Transmission of Sensitive Information and CWE-522 Insufficiently Protected Credentials, highlighting a fundamental lack of defense-in-depth regarding data at rest security protocols.
To mitigate these risks, immediate updates to version 0.0.53 or later are required as they address the identified flaws. For environments where upgrading is not immediately feasible, several compensating controls should be implemented. First, avoid using Python eval for dynamic condition evaluation; instead, implement a restricted expression language or parser that limits available operations and prevents arbitrary code execution. Second, enforce strict validation of webhook signatures and ensure that default configurations require explicit credential setup rather than failing open when credentials are missing. Third, validate the redirect_uri parameter in OAuth flows to restrict allowed schemes strictly to https: and verify against an allowlist of registered domains to prevent XSS attacks via malicious redirects. Finally, encrypt all sensitive tokens stored in the database using strong encryption algorithms with proper key management practices, ensuring that even if the database is compromised, the stolen data remains unintelligible without access to the decryption keys. Regular security audits and penetration testing should be conducted to identify similar patterns of insecure configuration or input handling across other modules of the application.