CVE-2026-100865: Heym before 0.0.53 Remote Code Execution via eval() Sandbox Escape
Heym before 0.0.53 evaluates workflow condition expressions using Python's eval() with insufficient sandboxing in the workflow executor service. Authenticated users can edit workflow condition nodes or import malicious templates to execute arbitrary Python and OS commands as the backend process user.
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected?
Heym versions before 0.0.53 are affected. The issue includes workflow execution, webhook triggers, OAuth authorization, and plaintext storage of several token types.
What level of access is needed for code execution through workflows?
An attacker needs the ability to edit a workflow branch or condition node, or to import a workflow template containing a malicious condition node. The code executes when the workflow runs, with the permissions of the backend process user.
When can an unauthenticated party trigger Slack or Telegram workflows?
The Slack and Telegram webhook checks fail open when the trigger node has no credentialId or has an empty signing secret. Anyone who knows the public webhook URL can then trigger the workflow using the owner's credentials.
What is required to exploit the OAuth issue?
An attacker must register a public OAuth client using a javascript: or data: redirect_uri and persuade a victim to visit the consent screen. This can expose the authorization code and run attacker-controlled JavaScript in the Heym origin, including access to the victim's HttpOnly authentication cookie.
What sensitive values are at risk if the database is exposed?
WorkflowExecutionToken, PortalSession, HITLRequest.public_token, and OAuthAuthorizationCode values are stored in plaintext. A database read exposure should therefore be treated as exposure of those stored values.