Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-09-27T02:17:26.117Z",
  "pubdate": "2026-09-27T02:17:26.117Z",
  "executiveSummary": "Heym versions 0.0.90 and earlier are susceptible to two distinct Server-Side Request Forgery (SSRF) vulnerabilities stemming from inadequate egress filtering and incomplete address validation. These flaws allow an attacker to bypass internal security controls and force the application to perform unauthorized requests to arbitrary network destinations, including loopback, RFC1918 internal resources, and cloud metadata services.\nThe vulnerabilities exist within the LLM image-edit functionality and the address validation logic. By leveraging the workflow DSL, an attacker can manipulate input parameters to control the destination URL of outbound HTTP/HTTPS requests. This bypasses established egress-pinning mechanisms, effectively turning the server into a proxy for performing reconnaissance or data exfiltration against internal network segments.\nThe risk implications are significant, as successful exploitation enables attackers to interact with non-public internal APIs, access sensitive cloud provider metadata (which may contain temporary security credentials), or conduct internal port scanning. The attack requires the ability to provide inputs that are processed by the vulnerable image loader component. Remediation involves strictly routing all outbound requests through the application's guarded HTTP client and implementing robust, standards-compliant IP address validation to mitigate complex IPv6 transition mechanisms.",
  "technicalDetails": "The primary vulnerability exists in the LLM image-edit input loader, specifically the _load_image_bytes function. This component improperly utilized a bare httpx.get call to fetch remote resources defined by user-controlled input. Because the workflow DSL permits dynamic references such as 'imageInput': '$userInput.body.imageUrl', an attacker can inject arbitrary URLs. By failing to utilize the centralized egress-pinning HTTP client, the application ignored existing security boundaries, allowing requests to resolve to prohibited destinations including loopback (127.0.0.1), RFC1918 private address space, and cloud metadata endpoints (e.g., 169.254.169.254).\nThe secondary vulnerability resides in the _is_public_address validation logic, which failed to account for various IPv6 transition and encapsulation formats. The implementation only unwrapped IPv4-mapped IPv6 addresses, leaving the system susceptible to obfuscated addressing schemes. Attackers could bypass URL validation and dial-time IP pinning by utilizing NAT64 prefixes (64:ff9b::/96), deprecated IPv4-compatible addresses (::x.x.x.x), and 6to4 transition addresses (2002::/16). Because Python 3.11.0 through 3.11.9 classified 6to4 addresses as globally routable, the guard logic incorrectly permitted these requests to proceed despite them potentially mapping to internal IPv4 targets.\nThe attack flow proceeds as follows: An attacker submits a malicious workflow configuration where the 'imageInput' parameter is populated with a target URI pointing to an internal resource. When the application processes the workflow, the _load_image_bytes function initiates a request to the attacker-supplied URI. Due to the lack of egress pinning, the request is dispatched directly. If the target is protected by IP-based access control, the attacker leverages the IPv6 obfuscation techniques in the _is_public_address module to bypass validation filters. By wrapping an internal IPv4 address inside a 6to4 or NAT64 transition format, the attacker tricks the validator into classifying the request as public. Upon resolution, the server executes the request, granting the attacker access to the response content or enabling unauthorized actions against internal infrastructure. This effectively circumvents network segmentation and exposes sensitive internal services that were previously shielded from the public-facing application."
}