Heym versions 0.0.90 and earlier allow a server‑side request forgery when a user supplies an image URL through the workflow DSL field "imageInput": "$userInput.body.imageUrl". The application fetches the URL using a bare httpx.get, ignoring egress‑pinning and performing only a scheme check; this permits an attacker to direct the server to reach any HTTP/HTTPS endpoint, including localhost, private networks, and cloud metadata services. In addition, the code incorrectly treats IPv6 transition forms such as NAT64, IPv4‑compatible, and 6to4 addresses as publicly routable, meaning the same flaw also applies to requests resolved via embedded IPv4 destinations. The impact is that an attacker can read or manipulate data on internal systems or leak information through metadata endpoints, compromising confidentiality, integrity, and potentially aiding further exploitation.

The vulnerability is present in Heym, a product of heymrun, on all releases 0.0.90 and earlier. Version 0.0.91 and later contain a guard module that routes image loading through a vetted HTTP client, evaluates IPv6 addresses correctly, and denies requests to NAT64, IPv4‑compatible, 6to4, and Teredo addresses. No other products are mentioned in the advisory.

The CVSS score of 5.3 indicates a moderate severity of the vulnerability. The EPSS score is not provided, and the vulnerability is not listed in the CISA KEV catalog, suggesting no publicly confirmed exploits yet. However, the flaw can be triggered via normal API or webhook calls, making it potentially exploitable by any actor who can influence the image URL supplied by a workflow author. The lack of additional controls such as egress‑pinning or IP whitelisting increases the risk of unwanted internal requests.