{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/flyto-core/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["flyto-core"],"_cs_severities":["high"],"_cs_tags":["ssrf","vulnerability","python","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["flytohub"],"content_html":"\u003cp\u003eThe \u003ccode\u003eflyto-core\u003c/code\u003e application, developed by flytohub, contains a critical Server-Side Request Forgery (SSRF) vulnerability, identified as CWE-918, in its \u003ccode\u003evalidate_url_ssrf\u003c/code\u003e function, specifically within the \u003ccode\u003eis_private_ip\u003c/code\u003e helper in \u003ccode\u003esrc/core/utils.py\u003c/code\u003e. This vulnerability, published on 2026-07-06, allows an authenticated workflow author to bypass the intended SSRF protection by utilizing IPv6 transition addresses. The application's guard, designed to block access to private and cloud metadata services, fails to correctly identify private IP addresses embedded within IPv4-mapped, 6to4, or NAT64 IPv6 formats. This oversight enables attackers to craft URLs using these unblocked IPv6 forms to access internal resources like cloud instance metadata services (e.g., \u003ccode\u003e169.254.169.254\u003c/code\u003e) or internal loopback services. The response body from these internal services is then returned to the attacker, resulting in a read SSRF that can lead to the exfiltration of sensitive information, such as IAM credentials. This bypass directly undermines the project's documented security controls.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA workflow author, possessing valid authentication credentials for \u003ccode\u003eflyto-core\u003c/code\u003e's Execution API (\u003ccode\u003ePOST /v1/execute\u003c/code\u003e), prepares to execute a module.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL containing an IPv6 transition-form host, such as \u003ccode\u003ehttp://[::ffff:127.0.0.1]:8080/\u003c/code\u003e for loopback access or \u003ccode\u003ehttp://[64:ff9b::a9fe:a9fe]/latest/meta-data/\u003c/code\u003e for cloud instance metadata.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a \u003ccode\u003ePOST\u003c/code\u003e request to \u003ccode\u003ehttp://127.0.0.1:8333/v1/execute\u003c/code\u003e with a JSON payload including \u003ccode\u003e{\u0026quot;module_id\u0026quot;:\u0026quot;http.get\u0026quot;, \u0026quot;params\u0026quot;:{\u0026quot;url\u0026quot;:\u0026quot;[malicious_url]\u0026quot;}}\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eflyto-core\u003c/code\u003e application invokes \u003ccode\u003evalidate_url_ssrf\u003c/code\u003e, which calls \u003ccode\u003eis_private_ip()\u003c/code\u003e on the IPv6 transition address. Due to the vulnerability, \u003ccode\u003eis_private_ip()\u003c/code\u003e incorrectly returns \u003ccode\u003eFalse\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ehttp.get\u003c/code\u003e atomic module proceeds to initiate an outbound HTTP GET request using \u003ccode\u003eaiohttp\u003c/code\u003e to the internal destination specified by the crafted URL.\u003c/li\u003e\n\u003cli\u003eThe internal service (e.g., cloud metadata service or a local web server) processes the request and returns its sensitive response body.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eflyto-core\u003c/code\u003e receives the internal service's response and, as part of the \u003ccode\u003ehttp.get\u003c/code\u003e module's functionality, returns the full response body to the attacker in the \u003ccode\u003e/v1/execute\u003c/code\u003e API response.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully exfiltrates sensitive data, such as IAM credentials or internal service information, via a read Server-Side Request Forgery.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows an authenticated workflow author to bypass \u003ccode\u003eflyto-core\u003c/code\u003e's security controls and perform read Server-Side Request Forgery (SSRF). This directly enables data exfiltration from internal services that are typically isolated from external access. Specifically, attackers can access cloud instance metadata services (e.g., \u003ccode\u003e169.254.169.254\u003c/code\u003e) to steal highly sensitive IAM credentials and instance identity information. Additionally, the bypass permits access to internal loopback and RFC 1918 services, potentially exposing other sensitive internal applications or data. The success of this attack directly undermines the intended security model of \u003ccode\u003eflyto-core\u003c/code\u003e, which explicitly documents these checks as critical security controls. While the source does not provide victim numbers, any organization using \u003ccode\u003eflyto-core\u003c/code\u003e is susceptible, especially those deployed in cloud environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately apply the patch provided by flytohub, which modifies \u003ccode\u003esrc/core/utils.py\u003c/code\u003e to correctly identify and block private IP addresses embedded within IPv6 transition forms, as demonstrated in the \u0026quot;Suggested fix\u0026quot; section of this brief.\u003c/li\u003e\n\u003cli\u003eReview all \u003ccode\u003eflyto-core\u003c/code\u003e deployments, especially those in cloud environments, to ensure proper network segmentation and defense-in-depth measures limit the impact of potential SSRF vulnerabilities.\u003c/li\u003e\n\u003cli\u003eMonitor network egress logs for connections originating from \u003ccode\u003eflyto-core\u003c/code\u003e instances to unusual or internal-only IPv6 addresses, particularly those resembling the IPv4-mapped \u003ccode\u003e::ffff:169.254.169.254\u003c/code\u003e, NAT64 \u003ccode\u003e64:ff9b::/96\u003c/code\u003e, or 6to4 \u003ccode\u003e2002::/16\u003c/code\u003e prefixes.\u003c/li\u003e\n\u003cli\u003eEnsure that cloud metadata services and other sensitive internal endpoints are configured with least privilege access and minimal exposed information, assuming they might eventually be accessed by an SSRF attack.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-06T17:36:55Z","date_published":"2026-07-06T17:36:55Z","id":"https://feed.craftedsignal.io/briefs/2026-07-flyto-core-ssrf-bypass/","summary":"An authenticated workflow author can bypass `flyto-core`'s Server-Side Request Forgery (SSRF) protection by crafting URLs with IPv6 transition addresses that embed private IPv4s, allowing for data exfiltration from internal services like cloud instance metadata.","title":"flyto-core SSRF Bypass via IPv6 Transition Addresses (CWE-918)","url":"https://feed.craftedsignal.io/briefs/2026-07-flyto-core-ssrf-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Flyto-Core","version":"https://jsonfeed.org/version/1.1"}