An attacker can bypass security controls by providing a malicious public-facing URL that returns a 302 redirect to an internal IP address or sensitive cloud metadata endpoint (e.g., 169.254.169.254). Because the application does not inspect the Location header or re-verify the redirect target against the internal allowlist, the aiohttp client transparently follows the request to the restricted resource. This results in the potential exfiltration of sensitive internal configuration, metadata, or other network-accessible data. This vulnerability affects all deployments using standard module configurations where redirects are permitted by the underlying client.

Attack Chain

1. Attacker identifies a target application utilizing Flyto2 Core for external HTTP requests.
2. Attacker hosts a public, innocuous-looking URL (e.g., http://attacker.tld/r) configured to return an HTTP 302 redirect.
3. Attacker triggers a request to the target application, passing the public URL to a vulnerable function like http.get.
4. The target application's validate_url_with_env_config function evaluates the initial URL (attacker.tld), which is deemed safe, and passes validation.
5. The application invokes session.get(url) via aiohttp, which by default is set to allow_redirects=True.
6. The aiohttp client receives the 302 redirect and automatically initiates a new request to the internal destination (e.g., http://169.254.169.254/...).
7. No per-hop validation occurs, allowing the request to succeed against the internal host.
8. The sensitive data returned from the internal host is relayed back to the attacker as the final response body.

Impact

Successful exploitation allows for unauthorized access to internal services and cloud metadata endpoints that are otherwise unreachable from the public internet. This can lead to the exposure of credentials, environment variables, or other sensitive infrastructure details. The vulnerability affects all users of Flyto2 Core versions 2.26.6 and earlier.

Recommendation

1. Upgrade Flyto2 Core to the latest patched version once available to address CVE-2026-67424.
2. If an immediate upgrade is not feasible, implement manual revalidation of the Location header in the HTTP module codebase by disabling allow_redirects and explicitly checking redirect targets against the allowlist.
3. Deploy egress filtering on servers running Flyto2 Core to restrict access to internal IP ranges (e.g., 169.254.0.0/16, 127.0.0.0/8) from the application process.