CVE-2026-100858: heym before 0.0.109 Server-Side Request Forgery via Workflow Nodes
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 (webhookurl / flaresolverrurl) 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
heymto a version that resolves this vulnerability.Fixed in 0.0.109
Event History
Frequently Asked Questions
Who can exploit this issue?
Any registered user who can create credentials and execute a workflow can exploit it. The attack does not require user interaction, but it does require low-privileged authenticated access.
Which workflow nodes are affected?
The Slack, Discord, and Crawler workflow nodes are affected when their user-created credentials supply a webhook_url or flaresolverr_url. HTTP, WebSocket, and MCP nodes already use the SSRF egress guard described in the advisory.
What can an attacker access through the vulnerable nodes?
An attacker can direct the backend to loopback, private-network, link-local, or cloud-metadata endpoints. The response body is returned in node output, making this a non-blind SSRF issue.
How can I determine whether my deployment is vulnerable?
Deployments running heym before 0.0.109 are affected. A practical indicator is whether registered users can create Slack, Discord, or Crawler credentials with arbitrary non-empty webhook_url or flaresolverr_url values and run workflows using them.