Heym versions from 0.0.55 up to but not including 0.0.121 contain a privilege escalation vulnerability. Shared collaborators can overwrite a workflow's error_workflow_id because this field is not restricted to owners only. This allows attackers to redirect error workflows to their own workflows containing HTTP nodes, leading to exfiltration of the owner's decrypted credentials when the parent workflow errors.
CVE-2026-55376 is a high-severity OS command injection vulnerability in heymrun's heym product prior to version 0.0.40. Authenticated users with permissions to create or edit workflows using an Agent custom Python tool can bypass sandbox restrictions due to improper validation of imported standard-library modules. This allows execution of arbitrary OS commands and file operations with the backend application user's privileges. The issue is fixed in version 0.0.40.
Heym versions from 0.0.5 up to but not including 0.0.113 have a broken access control vulnerability that allows former collaborators to continue executing JWT-authenticated workflows by reusing scoped workflow:execute tokens after their share has been removed. These tokens can have a time-to-live (TTL) of up to 10 years, cannot be listed or revoked by the owner, and enable repeated execution of workflows using shared credentials.
Heym before v0.0.112 contains a token leakage vulnerability in build_public_base_url() that allows unauthenticated attackers to redirect HITL review links by spoofing Origin or X-Forwarded-Host headers. Attackers can trigger anonymous workflows with forged headers so reviewer notifications point to attacker domains, capturing capability tokens to submit decisions executed with owner credentials.
CVE-2026-101050 is an improper authentication vulnerability in heymrun's heym software versions before 0.0.53. The flaw occurs because the software fails to verify the X-Telegram-Bot-Api-Secret-Token header on Telegram webhook endpoints when credential_id is absent or secret_token is empty. This allows remote unauthenticated attackers to post forged Telegram updates, triggering workflows with the owner's configured credentials and potentially executing actions based on attacker-supplied input.
Heym versions before 0.0.53 contain an improper authentication vulnerability where Slack request signatures are not verified if trigger nodes lack credential IDs or have empty signing secrets. This allows remote unauthenticated attackers to send forged Slack events to known webhook URLs, potentially triggering workflows with the owner's credentials.
CVE-2026-100865 is a high-severity code injection vulnerability in heym versions before 0.0.53. The vulnerability arises because the workflow executor service evaluates workflow condition expressions using Python's eval() function without sufficient sandboxing. Authenticated users can exploit this flaw by editing workflow condition nodes or importing malicious templates, enabling them to execute arbitrary Python and OS commands with the backend process user's privileges.
CVE-2026-100864 is a high-severity vulnerability in heym versions before 0.0.91. It allows authenticated users to escape the sandbox in the expression engine by exploiting the DotList map/filter and fallback resolver. This enables arbitrary Python code execution on the backend process via crafted workflow expressions using dunder attribute access. The vulnerability is due to improper control of code generation, classified as CWE-94.
Heym versions 0.0.90 and earlier contain two server-side request forgery (SSRF) egress gaps, both remediated in app/services/ssrf_guard.py in 0.0.91. First, the LLM image-edit input loader (_load_image_bytes) fetched caller-controlled HTTP/HTTPS URLs with a bare httpx.get, applying only a scheme check and bypassing the egress-pinning HTTP client; because the workflow DSL supports "imageInput": "$userInput.body.imageUrl", a webhook or API caller can choose the fetch target when a workflow author uses that expression, allowing requests to loopback, RFC1918, and cloud metadata endpoints. Second, _is_public_address unwrapped only IPv4-mapped IPv6 addresses, so IPv6 transition forms — the NAT64 well-known prefix 64:ff9b::/96, deprecated IPv4-compatible ::x.x.x.x addresses, and 6to4 (2002::/16, classified as globally routable by Python 3.11.0 through 3.11.9) — could carry loopback, RFC1918, link-local, or cloud-metadata IPv4 destinations past both the initial URL validation and the dial-time IP pin. Version 0.0.91 routes the image loader through guard_http_url and the guarded client, evaluates NAT64 and IPv4-compatible addresses by their embedded IPv4 address, and refuses 64:ff9b:1::/48, 6to4, and Teredo (2001::/32) outright.
heym, a workflow automation platform, stores and returns multiple capability secrets in plaintext in versions prior to 0.0.91. Affected secrets include webhook header-auth values (returned in cleartext by GET /api/workflows/{id} and persisted unsanitized into execution history), MCP API keys (stored as a plaintext column, returned in config/list responses, and accepted via the ?key= query string so they leak into logs, proxies and Referer headers), portal session tokens (stored and validated by plaintext equality with a 168-hour TTL), workflow execution JWTs (stored in full and re-listed by GET .../execution-tokens), Discord interaction tokens (the full interaction body is stored in execution history), and global variables. A user with read access to a workflow, share/team membership, or anyone able to read the database, a backup, or logs can recover these secrets and replay them to execute workflows or act as the secret owner.
CVE-2026-100861 is a Server-Side Request Forgery (SSRF) vulnerability in heymrun's heym product before version 0.0.105. The vulnerability arises because egress guards are not applied to integration services that use credential-supplied base URLs. This allows authenticated users to bypass SSRF protections by configuring credentials to point to internal addresses such as loopback, private networks, or cloud metadata endpoints. The internal service responses can then be read as workflow node output.
heym before 0.0.105 does not act on the result of the credential authorization lookup in the Redis workflow node (backend/app/services/node_execution/nodes/redis_node.py). When _get_accessible_credential returns None — because the credential ID does not exist or the caller is not authorized to use it — the node treats the lookup failure as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation there. The same fallback occurs when an accessible credential has an empty config or no redis_host value. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, therefore obtains a read/write connection to whatever Redis is listening on the backend's loopback interface instead of an error. Impact depends on the deployment: the stock docker-compose.yml ships no Redis, in which case the flaw surfaces as a misleading connection error rather than data exposure.
CVE-2026-100859 is a Server-Side Request Forgery (SSRF) vulnerability in heymrun heym versions before 0.0.106. It affects the POST /api/credentials/test endpoint, allowing collaborators with shared credential access to exfiltrate the credential owner's secret by overriding the destination URL in the config parameter. This causes the server to send decrypted authentication secrets to attacker-controlled endpoints.
heym before 0.0.109 contains a server-side request forgery vulnerability in the Slack, Discord, and Crawler workflow nodes. These nodes issue HTTP requests to URLs taken from user-created credentials (webhook_url / flaresolverr_url) using an unguarded HTTP client, bypassing the SSRF egress guard that already protects the HTTP, WebSocket, and MCP nodes; the credential API validates only that the URL is non-empty. Any registered user can create a credential pointing at an internal address and execute a workflow, causing the backend to reach loopback, private, link-local, or cloud-metadata endpoints and return the full response body in the node output (non-blind SSRF).
Heym before 0.0.98 fails to apply SSRF egress guards to WebSocket Send and WebSocket Trigger nodes, allowing authenticated users to connect to internal services. Attackers can craft workflow nodes with arbitrary URLs and headers to reach internal services and read responses from the WebSocket Trigger node.
Heym before 0.0.21 contains a sandbox escape vulnerability in the custom Python tool executor that allows authenticated workflow authors to bypass sandbox restrictions by using object-graph introspection primitives. Attackers can use Python introspection techniques to recover the unrestricted __import__ function, import blocked modules such as os and subprocess, and access inherited backend environment variables containing database credentials and encryption keys to execute arbitrary host commands as the backend service user.
Heym before 0.0.21 contains an authorization bypass vulnerability in workflow execution that allows authenticated users to execute arbitrary workflows by referencing victim workflow UUIDs without proper access validation. Attackers can create workflows with execute nodes or agent subWorkflowIds pointing to victim workflow UUIDs to load and execute those workflows under attacker-controlled execution paths, exposing victim workflow outputs and triggering workflow nodes with unintended side effects.
Heym before 0.0.21 contains a path traversal vulnerability in the file upload endpoint that allows authenticated users to write attacker-controlled files to arbitrary locations by supplying a crafted filename with traversal sequences. Attackers can exploit the unvalidated filename parameter in the upload_file() handler to bypass path restrictions and write, read, or delete files outside the intended storage directory.