Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-27T02:17:26.410Z",
  "pubdate": "2026-09-27T02:17:26.410Z",
  "executiveSummary": "Heym versions prior to 0.0.53 contain five distinct vulnerabilities, including Remote Code Execution (RCE), authentication bypass, and improper authorization management.\nThe most critical flaws involve an unsafe eval() execution context in workflow conditions, insecure webhook verification for Slack and Telegram integrations, and an OAuth redirect URI validation failure leading to cross-site scripting (XSS) and credential theft.\nAdditionally, sensitive tokens and authorization codes are stored in plaintext, significantly lowering the barrier for privilege escalation following a database breach.\nThese vulnerabilities allow unauthenticated or low-privileged attackers to execute arbitrary code with backend process privileges, hijack user sessions, and perform unauthorized actions on behalf of the workflow owner.\nThe risk is critical, as these flaws enable complete system compromise and data exfiltration from affected instances.",
  "technicalDetails": "The primary RCE vulnerability stems from the use of Python's eval() function within the workflow condition evaluator. Because this implementation lacks an effective sandbox, any actor capable of modifying a workflow condition node or importing a malicious template can force the backend process to execute arbitrary Python code. This grants the attacker the execution privileges of the backend service user, leading to potential full system compromise.\nThe authentication mechanisms for Slack and Telegram webhooks suffer from a fail-open design pattern. When a trigger node lacks a defined credentialId or possesses an empty signing secret, the verification process defaults to a successful state. An attacker aware of the public webhook URL can consequently trigger workflows without providing valid credentials, effectively masquerading as the authenticated user and manipulating workflow execution.\nThe OAuth 2.0 authorization implementation fails to enforce strict validation of the redirect_uri scheme. By registering a public OAuth client with URI schemes such as javascript: or data:, an attacker can lure a victim into visiting a malicious consent screen. Upon authorization, the victim's browser executes attacker-controlled JavaScript within the Heym origin, which bypasses Same-Origin Policy protections to access sensitive HttpOnly authentication cookies.\nFinally, the application suffers from improper sensitive data storage. Internal identifiers including WorkflowExecutionToken, PortalSession, HITLRequest.public_token, and OAuthAuthorizationCode are persisted in plaintext within the database. Because these tokens possess long Time-To-Live (TTL) values—specifically 168 hours for portal and HITL tokens—a database read exposure grants an attacker sufficient time to perform unauthorized workflow executions and administrative operations under the identity of the victim."
}