CVE-2026-100864

A vulnerability in Heym before version 0.0.40 allows an authenticated user who can create or edit a workflow with a custom Python tool to bypass the blacklist-based sandbox. Standard Python libraries expose system functions that pass validation, and the tool is executed via exec(), enabling command execution and file operations as the backend application user. The issue is fixed in version 0.0.40.

Heym versions v0.0.5 through v0.0.112 have a broken access control vulnerability that allows former collaborators to keep executing JWT-auth workflows by reusing scoped workflow:execute tokens after share removal. Attackers can mint a token with a TTL up to 10 years, which the owner cannot list or revoke, and repeatedly run the workflow consuming 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.

Heym before 0.0.53 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. Remote unauthenticated attackers can post forged Telegram updates to trigger workflows with the owner's configured credentials and execute actions on attacker-supplied input.

Heym before 0.0.53 fails to verify Slack request signatures when trigger nodes lack credential IDs or have empty signing secrets. Remote unauthenticated attackers can send forged Slack events to known webhook URLs to trigger workflows with the owner's credentials.

Vulnerability in Heym before 0.0.53 where workflow condition expressions are evaluated using Python's eval() with insufficient sandboxing in the workflow executor service.

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. 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) — could carry loopback, RFC1918, link-local, or cloud-metadata IPv4 destinations past both the initial URL validation and the dial-time IP pin.

The workflow automation platform heym before version 0.0.91 stores and returns multiple secrets in plaintext, including webhook header-auth values, MCP API keys, portal session tokens, workflow execution JWTs, Discord interaction tokens, 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.

heym before 0.0.105 fails to apply egress guards to integration services that use credential-supplied base URLs, allowing authenticated users to bypass SSRF protections. Attackers can configure credentials pointing to loopback, private, or cloud-metadata addresses and read internal service responses returned 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. When _get_accessible_credential returns None, the node treats it as an empty configuration and falls back to defaults, connecting to localhost:6379 with no password and executing the requested operation. An authenticated workflow author who supplies a credential ID they do not own, or one that was deleted, obtains a read/write connection to whatever Redis is listening on the backend's loopback interface.