Summary
Heym before 0.0.53 contains multiple security weaknesses affecting workflow execution, webhook authentication, OAuth redirects, and token storage. Depending on deployment and attacker access, these issues may enable arbitrary Python code execution, unauthenticated workflow triggering, browser-side code execution, or use of exposed bearer tokens.
Affected context
The vulnerabilities occur in Heym deployments that allow users to edit workflow condition nodes, import workflow templates, expose Slack or Telegram webhook triggers, use the OAuth authorization flow, or store workflow and session tokens in a readable database. Risk increases when workflow definitions are treated as executable logic, webhook credentials are optional, redirect targets are not restricted to safe schemes, or database read access is available to an unauthorized party.
Exploit preconditions
- Workflow code execution: The attacker must be able to edit a workflow condition or import a template containing a condition node, and the workflow must subsequently execute.
- Webhook authentication bypass: The attacker needs knowledge of a public Slack or Telegram webhook URL where the corresponding trigger lacks a configured credential identifier or signing secret.
- OAuth redirect abuse: The attacker needs a registered public OAuth client, a redirect URI accepted by the authorization endpoint, and a victim who completes the consent flow.
- Plaintext token abuse: The attacker needs read access to the database or another storage exposure containing workflow, portal, HITL, or OAuth token values.
- Execution context: Successful code execution runs with the permissions of the Heym backend process.
Why this happens
The primary issue is unsafe execution of attacker-influenced workflow expressions through Python eval() without an effective sandbox, which maps to CWE-94: Improper Control of Generation of Code. Additional weaknesses arise from fail-open webhook verification, insufficient OAuth redirect URI scheme validation, and plaintext storage of bearer tokens. Together, these patterns treat workflow content, callback destinations, or stored credentials as trusted without enforcing strong boundaries between user-controlled data and executable code or authentication material.
Potential impact
- An attacker may execute arbitrary Python code with backend process privileges.
- An attacker could trigger workflows using the owner's configured credentials.
- A malicious OAuth redirect may enable attacker-controlled script execution in the Heym origin.
- Exposed tokens may permit unauthorized workflow execution or portal and HITL access.
- Compromised tokens could remain usable during their configured validity periods.
- Attackers may access connected services, modify workflow behavior, or affect sensitive data.
General mitigation guidance
Mitigation generally focuses on removing dynamic code execution and enforcing fail-closed security boundaries.
Common defensive patterns include:
- Replace general-purpose expression evaluation with a narrowly scoped, allowlisted expression language or an explicit operation model.
- Treat imported workflow templates and condition nodes as untrusted input and validate them against a strict schema.
- Require valid webhook credentials and reject requests whenever signing configuration is missing, empty, malformed, or invalid.
- Permit OAuth redirect URIs only when they use approved secure schemes and exactly match pre-registered values.
- Store tokens and authorization codes using strong one-way protection where feasible, with encryption and tightly restricted key access when retrieval is required.
- Apply short lifetimes, rotation, revocation, audience binding, and least-privilege scopes to bearer credentials.
- Run the backend with minimal operating-system and service permissions, isolating workflow execution from sensitive resources.
- Avoid exposing database backups, logs, debugging interfaces, or replicas containing authentication material.
How teams detect issues like this
High-level detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis rules to flag
eval(), dynamic compilation, unrestricted expression interpreters, and unsafe execution of workflow-controlled strings. - Review webhook handlers for missing-credential paths, empty-secret acceptance, and branches that allow requests without positive signature verification.
- Test OAuth authorization logic for exact redirect URI matching and rejection of non-HTTP(S) schemes.
- Scan schemas, database models, logs, and backups for plaintext secrets, bearer tokens, authorization codes, or long-lived session values.
- Monitor workflow runs, webhook invocations, OAuth redirects, token use, and administrative actions for unusual sources or frequency.
- Enforce CI and security policies that prohibit general-purpose code evaluation and require fail-closed authentication behavior.
- Automated code and dependency review tools may help identify dangerous execution APIs and credential-handling patterns.
