Heym
Monthly
Authenticated users with workflow create/edit rights on self-hosted Heym deployments prior to 0.0.40 can escape the application's blacklist-based Python sandbox and execute arbitrary commands and file operations as the backend service account. The flaw lives in backend/app/services/python_tool_executor.py, where the allowlisted standard-library modules still expose OS, process, and filesystem primitives through public attributes, so tool source that passes _safe_import() and _validate_code_safety() is ultimately run through exec() with full application privileges (CVSS 8.8, CWE-78). Exploitation requires a low-privilege authenticated account (PR:L) with permission to create or edit a workflow containing an Agent custom Python tool; enabling self-registration makes that account trivially obtainable, though merely triggering a workflow from the portal does not grant code control. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), but the fix in 0.0.40 is available and the assessed risk is high for any multi-user deployment.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a workflow branch or condition node - or a victim who imports a workflow template containing a malicious condition node - run arbitrary Python as the backend process user whenever the workflow executes. The same release bundles four further flaws: fail-open Slack and Telegram webhook verification that allows unauthenticated workflow triggering with the owner's credentials when a trigger node has no credentialId or an empty signing secret, an OAuth redirect_uri scheme-validation gap that permits javascript:/data: URIs and script execution in the Heym origin, and plaintext storage of WorkflowExecutionToken, PortalSession, HITLRequest.public_token and OAuthAuthorizationCode values. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the 0.0.x pre-release product has a very small deployment base.
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow expressions to execute arbitrary Python and run operating-system commands as the backend process. The flaw lives in the expression engine's DotList map/filter item expressions and its fallback resolver, which fail to block dunder attribute traversal, letting an attacker chain attributes to reach functions such as os.system. Exploitation requires a valid account with workflow-authoring rights (PR:L) but no user interaction, making this a network-reachable, low-complexity compromise of confidentiality, integrity, and availability; no public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation.
Credential exfiltration in Heym before version 0.0.106 allows an authenticated collaborator who has been granted shared access to a credential to cause the server to transmit the credential owner's decrypted secret to an attacker-controlled endpoint. The flaw lives in the POST /api/credentials/test endpoint, where the destination URL supplied in the config parameter is not validated, so a low-privileged collaborator can redirect a credential-verification request (CWE-918 server-side request forgery) and harvest plaintext secrets they were never entitled to read. The vendor CVSS 4.0 assessment (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) confirms high confidentiality impact with no integrity or availability effect, and no public exploit code or confirmed in-the-wild exploitation has been identified at time of analysis; risk is concentrated in multi-user, self-hosted deployments that rely on collaborator sharing, while single-user instances are not meaningfully exposed.
Non-blind server-side request forgery in heym (heymrun) before 0.0.109 lets any registered user redirect backend HTTP requests to loopback, private, link-local, or cloud-metadata addresses and read the full response body in the workflow node output. The flaw is confined to the Slack, Discord, and Crawler workflow nodes, which build requests from user-supplied credential URLs (webhook_url / flaresolverr_url) with an unguarded HTTP client that bypasses the SSRF egress guard already enforced on the HTTP, WebSocket, and MCP nodes. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation requires only a valid account (PR:L) on an affected instance and no user interaction; the fixed release is 0.0.109.
Sandbox escape in Heym's custom Python tool executor (versions before 0.0.21) allows authenticated workflow authors to break out of the restricted execution environment using Python object-graph introspection, recover the unrestricted __import__ function, and load blocked modules such as os and subprocess. Once free of the sandbox, an attacker executes arbitrary host commands as the backend service user and reads inherited environment variables holding database credentials and encryption keys. Publicly available exploit code exists (SSVC 'poc'), though the EPSS probability is very low at 0.04% and it is not listed in CISA KEV.
Authorization bypass in Heym's workflow execution engine (versions before 0.0.21) allows any authenticated user to run workflows belonging to other users by referencing the victim's workflow UUIDs, exposing their outputs and triggering side-effecting nodes. The root cause is missing access validation on subworkflow and execute-node references (CWE-863), fixed upstream in pull request #93. No public exploit has been identified at time of analysis, and EPSS scores it at just 0.05% with CISA SSVC marking exploitation as 'none' - but SSVC rates the technical impact as total.
Arbitrary file write (and read/delete) in Heym before 0.0.21 lets an authenticated user escape the intended upload storage directory by embedding directory-traversal sequences in the filename parameter of the upload_file() handler. Because the filename is never validated, an attacker with valid credentials can plant, overwrite, or remove files anywhere the service account can reach, potentially leading to code execution or data tampering. Publicly available exploit code exists per SSVC (POC), but EPSS is very low (0.04%, 11th percentile) and it is not on CISA KEV, indicating no confirmed widespread exploitation.
Former collaborators of a Heym workspace can keep running JWT-authenticated workflows after their share is removed, because scoped 'workflow:execute' tokens minted while they still had access remain valid and cannot be listed or revoked by the workspace owner. Heym versions from v0.0.5 up to (but not including) v0.0.113 are affected, matching CPE cpe:2.3:a:heymrun:heym; the issue is an insufficient session expiration flaw (CWE-613) rated CVSS 5.3 with an authenticated-remote vector (CVSS:4.0 PR:L, corroborated by the assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), so only someone who legitimately held collaborator privileges can abuse it. The token's configurable TTL can extend to roughly ten years, letting the removed collaborator repeatedly trigger the workflow and consume the shared credentials it uses; there is no public exploit identified at time of analysis and no evidence of active exploitation, and no EPSS score was supplied.
HeYm (heymrun/heym) deployments prior to v0.0.112 can be tricked into emailing human-in-the-loop (HITL) review links that point to an attacker-controlled domain, leaking the capability tokens embedded in those links. An unauthenticated attacker who can trigger anonymous workflows and who supplies a forged Origin or X-Forwarded-Host header causes build_public_base_url() to derive the notification base URL from attacker input; if a legitimate reviewer then clicks the link, the token is captured and can be replayed to submit review decisions that the platform executes with the workflow owner's credentials. Rated medium severity (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:R with low confidentiality and integrity impact), the flaw is conditional - it requires an anonymously triggerable workflow, the HITL feature, and reviewer interaction - and no public exploit code or confirmed active exploitation was identified at time of analysis. The vendor-released fix is Heym v0.0.112.
Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.
Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all versions prior to 0.0.91 and allows anyone with read access to a workflow, share/team membership, or read access to the database, a backup, or logs to recover and replay those secrets to execute workflows or act as the secret owner. Exposed values include webhook header-auth credentials returned in cleartext by GET /api/workflows/{id} and persisted into execution history, MCP API keys stored as a plaintext column and accepted via a ?key= query string that leaks into logs, proxies, and Referer headers, portal session tokens validated by plaintext equality with a 168-hour TTL, workflow execution JWTs re-listed by GET .../execution-tokens, Discord interaction tokens, and global variables. The vendor CVSS 4.0 score is 6.9 (medium) with a high-privilege prerequisite (PR:H), our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, exploitation is bounded by the need for prior authorized read access rather than a special configuration, a vendor patch is available in 0.0.91, and no public exploit was identified at time of analysis.
SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.
heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workflow author cause the node to fall back to unauthenticated defaults on the backend's loopback interface. When the credential lookup returns no accessible credential - because the ID does not exist, was deleted, or belongs to another user - the node treats the failure as empty configuration and connects to localhost:6379 with no password, executing the requested Redis operation there. The impact is deployment-gated: the stock docker-compose.yml ships no Redis, so default installs only surface a misleading connection error, while operators who have placed a passwordless Redis on loopback face unauthorized read/write access; no public exploit has been identified at time of analysis and no EPSS or KEV signal is available.
Authenticated SSRF in the Heym workflow engine before v0.0.98 allows any workflow author to reach internal network services by crafting WebSocket Send or WebSocket Trigger nodes with arbitrary target URLs - bypassing the egress guard that was implemented only for HTTP nodes. Attackers can exfiltrate responses from internal services (including cloud-metadata at 169.254.169.254) and transmit crafted payloads to internal WebSocket-capable services. No public exploit has been identified and this vulnerability is not listed in CISA KEV; a vendor-released patch is available as v0.0.98.
Authenticated users with workflow create/edit rights on self-hosted Heym deployments prior to 0.0.40 can escape the application's blacklist-based Python sandbox and execute arbitrary commands and file operations as the backend service account. The flaw lives in backend/app/services/python_tool_executor.py, where the allowlisted standard-library modules still expose OS, process, and filesystem primitives through public attributes, so tool source that passes _safe_import() and _validate_code_safety() is ultimately run through exec() with full application privileges (CVSS 8.8, CWE-78). Exploitation requires a low-privilege authenticated account (PR:L) with permission to create or edit a workflow containing an Agent custom Python tool; enabling self-registration makes that account trivially obtainable, though merely triggering a workflow from the portal does not grant code control. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), but the fix in 0.0.40 is available and the assessed risk is high for any multi-user deployment.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a workflow branch or condition node - or a victim who imports a workflow template containing a malicious condition node - run arbitrary Python as the backend process user whenever the workflow executes. The same release bundles four further flaws: fail-open Slack and Telegram webhook verification that allows unauthenticated workflow triggering with the owner's credentials when a trigger node has no credentialId or an empty signing secret, an OAuth redirect_uri scheme-validation gap that permits javascript:/data: URIs and script execution in the Heym origin, and plaintext storage of WorkflowExecutionToken, PortalSession, HITLRequest.public_token and OAuthAuthorizationCode values. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the 0.0.x pre-release product has a very small deployment base.
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow expressions to execute arbitrary Python and run operating-system commands as the backend process. The flaw lives in the expression engine's DotList map/filter item expressions and its fallback resolver, which fail to block dunder attribute traversal, letting an attacker chain attributes to reach functions such as os.system. Exploitation requires a valid account with workflow-authoring rights (PR:L) but no user interaction, making this a network-reachable, low-complexity compromise of confidentiality, integrity, and availability; no public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation.
Credential exfiltration in Heym before version 0.0.106 allows an authenticated collaborator who has been granted shared access to a credential to cause the server to transmit the credential owner's decrypted secret to an attacker-controlled endpoint. The flaw lives in the POST /api/credentials/test endpoint, where the destination URL supplied in the config parameter is not validated, so a low-privileged collaborator can redirect a credential-verification request (CWE-918 server-side request forgery) and harvest plaintext secrets they were never entitled to read. The vendor CVSS 4.0 assessment (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) confirms high confidentiality impact with no integrity or availability effect, and no public exploit code or confirmed in-the-wild exploitation has been identified at time of analysis; risk is concentrated in multi-user, self-hosted deployments that rely on collaborator sharing, while single-user instances are not meaningfully exposed.
Non-blind server-side request forgery in heym (heymrun) before 0.0.109 lets any registered user redirect backend HTTP requests to loopback, private, link-local, or cloud-metadata addresses and read the full response body in the workflow node output. The flaw is confined to the Slack, Discord, and Crawler workflow nodes, which build requests from user-supplied credential URLs (webhook_url / flaresolverr_url) with an unguarded HTTP client that bypasses the SSRF egress guard already enforced on the HTTP, WebSocket, and MCP nodes. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation requires only a valid account (PR:L) on an affected instance and no user interaction; the fixed release is 0.0.109.
Sandbox escape in Heym's custom Python tool executor (versions before 0.0.21) allows authenticated workflow authors to break out of the restricted execution environment using Python object-graph introspection, recover the unrestricted __import__ function, and load blocked modules such as os and subprocess. Once free of the sandbox, an attacker executes arbitrary host commands as the backend service user and reads inherited environment variables holding database credentials and encryption keys. Publicly available exploit code exists (SSVC 'poc'), though the EPSS probability is very low at 0.04% and it is not listed in CISA KEV.
Authorization bypass in Heym's workflow execution engine (versions before 0.0.21) allows any authenticated user to run workflows belonging to other users by referencing the victim's workflow UUIDs, exposing their outputs and triggering side-effecting nodes. The root cause is missing access validation on subworkflow and execute-node references (CWE-863), fixed upstream in pull request #93. No public exploit has been identified at time of analysis, and EPSS scores it at just 0.05% with CISA SSVC marking exploitation as 'none' - but SSVC rates the technical impact as total.
Arbitrary file write (and read/delete) in Heym before 0.0.21 lets an authenticated user escape the intended upload storage directory by embedding directory-traversal sequences in the filename parameter of the upload_file() handler. Because the filename is never validated, an attacker with valid credentials can plant, overwrite, or remove files anywhere the service account can reach, potentially leading to code execution or data tampering. Publicly available exploit code exists per SSVC (POC), but EPSS is very low (0.04%, 11th percentile) and it is not on CISA KEV, indicating no confirmed widespread exploitation.
Former collaborators of a Heym workspace can keep running JWT-authenticated workflows after their share is removed, because scoped 'workflow:execute' tokens minted while they still had access remain valid and cannot be listed or revoked by the workspace owner. Heym versions from v0.0.5 up to (but not including) v0.0.113 are affected, matching CPE cpe:2.3:a:heymrun:heym; the issue is an insufficient session expiration flaw (CWE-613) rated CVSS 5.3 with an authenticated-remote vector (CVSS:4.0 PR:L, corroborated by the assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), so only someone who legitimately held collaborator privileges can abuse it. The token's configurable TTL can extend to roughly ten years, letting the removed collaborator repeatedly trigger the workflow and consume the shared credentials it uses; there is no public exploit identified at time of analysis and no evidence of active exploitation, and no EPSS score was supplied.
HeYm (heymrun/heym) deployments prior to v0.0.112 can be tricked into emailing human-in-the-loop (HITL) review links that point to an attacker-controlled domain, leaking the capability tokens embedded in those links. An unauthenticated attacker who can trigger anonymous workflows and who supplies a forged Origin or X-Forwarded-Host header causes build_public_base_url() to derive the notification base URL from attacker input; if a legitimate reviewer then clicks the link, the token is captured and can be replayed to submit review decisions that the platform executes with the workflow owner's credentials. Rated medium severity (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:R with low confidentiality and integrity impact), the flaw is conditional - it requires an anonymously triggerable workflow, the HITL feature, and reviewer interaction - and no public exploit code or confirmed active exploitation was identified at time of analysis. The vendor-released fix is Heym v0.0.112.
Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.
Cleartext storage and over-exposure of multiple capability secrets in Heym, a workflow automation platform, affects all versions prior to 0.0.91 and allows anyone with read access to a workflow, share/team membership, or read access to the database, a backup, or logs to recover and replay those secrets to execute workflows or act as the secret owner. Exposed values include webhook header-auth credentials returned in cleartext by GET /api/workflows/{id} and persisted into execution history, MCP API keys stored as a plaintext column and accepted via a ?key= query string that leaks into logs, proxies, and Referer headers, portal session tokens validated by plaintext equality with a 168-hour TTL, workflow execution JWTs re-listed by GET .../execution-tokens, Discord interaction tokens, and global variables. The vendor CVSS 4.0 score is 6.9 (medium) with a high-privilege prerequisite (PR:H), our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, exploitation is bounded by the need for prior authorized read access rather than a special configuration, a vendor patch is available in 0.0.91, and no public exploit was identified at time of analysis.
SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.
heym before 0.0.105 fails to enforce credential authorization in its Redis workflow node, letting an authenticated workflow author cause the node to fall back to unauthenticated defaults on the backend's loopback interface. When the credential lookup returns no accessible credential - because the ID does not exist, was deleted, or belongs to another user - the node treats the failure as empty configuration and connects to localhost:6379 with no password, executing the requested Redis operation there. The impact is deployment-gated: the stock docker-compose.yml ships no Redis, so default installs only surface a misleading connection error, while operators who have placed a passwordless Redis on loopback face unauthorized read/write access; no public exploit has been identified at time of analysis and no EPSS or KEV signal is available.
Authenticated SSRF in the Heym workflow engine before v0.0.98 allows any workflow author to reach internal network services by crafting WebSocket Send or WebSocket Trigger nodes with arbitrary target URLs - bypassing the egress guard that was implemented only for HTTP nodes. Attackers can exfiltrate responses from internal services (including cloud-metadata at 169.254.169.254) and transmit crafted payloads to internal WebSocket-capable services. No public exploit has been identified and this vulnerability is not listed in CISA KEV; a vendor-released patch is available as v0.0.98.