CVE-2026-100863 in Heym
Summary
by MITRE • 09/27/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
Heym versions prior to 0.0.91 are susceptible to two distinct server-side request forgery vulnerabilities that allow attackers to bypass egress filtering controls and access internal network resources or cloud metadata endpoints. These flaws stem from inadequate validation of user-supplied URLs within the application's image processing workflow, specifically in the LLM image-edit input loader component. The first vulnerability arises from a direct implementation error where the _load_image_bytes function utilizes an unguarded httpx.get call to fetch images provided by callers. While this method performs a basic scheme check for HTTP or HTTPS protocols, it completely bypasses the application's dedicated egress-pinning HTTP client designed to restrict outbound connections to approved destinations. This architectural oversight creates a critical gap because the workflow DSL allows users to specify image sources via expressions such as "imageInput": "$userInput.body.imageUrl". Consequently, an attacker controlling webhook inputs or API payloads can dictate arbitrary fetch targets, enabling requests to loopback addresses, private RFC1918 networks, and sensitive cloud metadata services that are normally blocked by standard security policies.
The second vulnerability involves a deficiency in the IP address validation logic implemented within the _is_public_address function. This routine was designed to unwrap IPv4-mapped IPv6 addresses but failed to account for other IPv6 transition mechanisms that can encapsulate private or reserved IPv4 destinations. Specifically, attackers could exploit NAT64 prefixes such as 64:ff9b::/96, deprecated IPv4-compatible ::x.x.x.x formats, and the 6to4 prefix 2002::/16 to smuggle malicious requests past initial URL validation checks. Python versions 3.11.0 through 3.11.9 incorrectly classify certain 6to4 addresses as globally routable, further facilitating this bypass. By leveraging these transition forms, an attacker can route traffic destined for loopback interfaces, link-local networks, or cloud metadata endpoints without triggering the dial-time IP pinning mechanisms intended to enforce network segmentation and egress restrictions.
These vulnerabilities are classified under CWE-918 Server-Side Request Forgery (SSRF) due to the ability of external actors to induce the server-side application to make requests to unintended internal resources. The exploitation path aligns with ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer scenarios where SSRF is used to access internal services that are not directly exposed to the internet. The operational impact of these flaws includes potential unauthorized data exfiltration from internal databases, credential theft via cloud metadata service exploitation, and further lateral movement within the network infrastructure by probing internal services for additional vulnerabilities.
The issue was remediated in version 0.0.91 through a comprehensive overhaul of the URL handling logic. The image loader now routes all requests through the guarded_http_url function and utilizes the secured HTTP client that enforces egress policies, ensuring that only whitelisted destinations are accessible. Furthermore, the IP address validation logic was enhanced to correctly evaluate NAT64 and IPv4-compatible addresses by inspecting their embedded IPv4 components rather than relying solely on superficial format checks. The updated implementation explicitly refuses connections targeting known problematic prefixes including 64:ff9b:1::/48 for NAT64, as well as 6to4 (2002::/16) and Teredo (2001::/32) addresses which are often misclassified by older Python versions. Organizations using Heym should immediately upgrade to version 0.0.91 or later to mitigate these risks. Additionally, it is recommended to review network segmentation strategies and monitor outbound traffic logs for anomalies indicative of SSRF exploitation attempts while ensuring that underlying dependencies like the HTTP client library are kept up to date with security best practices.