CVE-2026-67424 in flyto-core
Summary
by MITRE • 07/29/2026
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the HTTP modules http.get, http.request, and http.batch in src/core/modules/atomic/http/get.py, src/core/modules/atomic/http/request.py, and src/core/modules/atomic/http/batch.py validate only the initial URL, then follow redirects with allow_redirects=True and without per-hop Location revalidation, allowing a public URL to redirect into internal address space and return the internal response body. This issue is fixed in version 2.26.7.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability in Flyto2 Core represents a critical server-side request forgery (SSRF) flaw that enables attackers to bypass initial URL validation and access internal network resources through HTTP redirect mechanisms. This vulnerability affects the core execution kernel's HTTP modules including http.get, http.request, and http.batch functions, which are fundamental components for automation and AI-agent workflows. The issue stems from improper handling of HTTP redirects where the system validates only the initial URL while allowing subsequent redirects to proceed without proper validation of destination addresses.
The technical implementation flaw occurs in the atomic HTTP modules located at src/core/modules/atomic/http/get.py, src/core/modules/atomic/http/request.py, and src/core/modules/atomic/http/batch.py. When these modules process HTTP requests with allow_redirects=True parameter, they fail to perform per-hop Location revalidation during redirect processing. This means that while the initial URL undergoes validation, any redirected URLs are not checked for internal network addresses, allowing public-facing endpoints to be manipulated into making requests to internal systems such as localhost, private IP ranges, or other internal services.
The operational impact of this vulnerability is severe as it creates an attack vector that can potentially expose sensitive internal infrastructure and data. An attacker could craft malicious requests that initially target external domains but then redirect to internal addresses, effectively bypassing network segmentation controls. The vulnerability enables information disclosure through the return of internal response bodies, which could contain sensitive data from internal services, configuration files, or system information. This type of SSRF vulnerability aligns with CWE-918, Server-Side Request Forgery, and maps to ATT&CK technique T1071.004 for application layer protocol usage.
The security implications extend beyond simple information disclosure as this vulnerability could potentially enable further attack vectors including internal network reconnaissance, service enumeration, or even exploitation of vulnerable internal services that may not be protected by external firewalls or access controls. The lack of per-hop validation creates a persistent risk where any publicly accessible endpoint can become a conduit for accessing otherwise protected internal resources.
Organizations using Flyto2 Core versions prior to 2.26.7 should immediately implement mitigations including upgrading to the fixed version, implementing strict URL validation policies that reject redirects to internal addresses, and deploying network-level controls such as firewalls or proxy configurations that prevent access to internal IP ranges from external-facing services. Additional defensive measures include implementing host-based restrictions on HTTP modules, monitoring for unusual redirect patterns, and conducting thorough security testing of all externally exposed endpoints to identify potential redirection attack vectors. The fix in version 2.26.7 addresses the core issue by implementing proper per-hop Location revalidation during HTTP redirect processing, ensuring that all redirected URLs are validated against internal address space restrictions before proceeding with the request.