CVE-2026-100858 in heym
Summary
by MITRE • 09/27/2026
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).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The identified vulnerability represents a critical server-side request forgery flaw within versions of the application prior to 0.0.109, specifically affecting the Slack, Discord, and Crawler workflow nodes. This security defect stems from an inconsistent implementation of network egress controls across different node types within the platform's architecture. While other components such as HTTP, WebSocket, and MCP nodes are protected by a robust SSRF egress guard that restricts outbound connections to safe or authorized destinations, these specific integration nodes utilize an unguarded HTTP client for processing requests. This architectural inconsistency creates a significant security gap where the protective mechanisms applied elsewhere in the system are entirely bypassed when workflows interact with Slack webhooks, Discord integrations, or external crawlers configured by users.
The root cause of this vulnerability lies in how user-supplied credentials are validated and utilized during workflow execution. The credential API performs only minimal validation, checking solely that the provided URL string is non-empty. It fails to enforce any restrictions on the target address space, such as blocking private IP ranges, loopback addresses, or cloud metadata endpoints. Consequently, an authenticated attacker can register a malicious credential containing a webhook_url or flaresolverr_url pointing to internal infrastructure services. When this credential is referenced in a workflow node, the backend system issues HTTP requests directly to these restricted destinations without triggering any security alerts or blocking mechanisms.
The operational impact of this vulnerability is severe due to its non-blind nature and broad scope. Because the full response body from the forged request is returned in the node output, an attacker can actively interact with internal services rather than merely probing for their existence. This capability allows for data exfiltration from sensitive internal APIs, database interfaces, or configuration endpoints that are not exposed to the public internet. Furthermore, attackers can leverage this access to map internal network topologies and identify additional attack vectors within the organization's infrastructure. The ability to reach cloud-metadata endpoints poses an even greater risk, as it may facilitate the theft of instance credentials, IAM roles, or other sensitive metadata essential for maintaining control over cloud environments.
This vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically illustrating a failure in server-side input validation and network egress filtering. In terms of offensive security frameworks, this exploit maps to the ATT&CK technique T1557, known as Adversary-in-the-Middle or Lateral Tool Transfer via SSRF, where attackers use compromised systems to pivot laterally across internal networks. The lack of strict URL validation and the absence of an allowlist for outbound connections are classic indicators of this class of vulnerability.
To mitigate this risk, immediate action is required by upgrading the software to version 0.0.109 or later, where these specific nodes have been patched with appropriate egress controls. For organizations unable to upgrade immediately, a temporary mitigation involves implementing strict network-level firewall rules at the perimeter and internal segmentation layers to block outbound connections from application servers to private IP ranges and cloud metadata endpoints. Additionally, input validation should be enforced on all credential fields to reject URLs containing reserved address spaces such as 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, and link-local addresses. Implementing a centralized proxy for all outbound HTTP requests from workflow nodes would also ensure consistent security policy application across the entire platform.