CVE-2026-73530 is a server-side request forgery guard bypass (CWE-918) in Flyto2 Core. The check that blocks private addresses does not cover the IPv6 address ::, which the operating system routes to loopback. The record rates it High at 7.7. Version 2.28.0 fixes it, so upgrade.
What's affected
The record says Flyto2 Core before 2.28.0 is affected, and the GitHub advisory (GHSA-gc4h-hj7x-gp5p) lists 2.28.0 as the patched version. The reporter tested 2.27.0. The advisory and record say the bypass applies to the http.get, http.request and http.batch modules.
Severity, as two sources state it. The record gives 7.7 (High) under CVSS 3.1 with a changed scope, because the request reaches a different component than the one that was attacked. VulnCheck lists it as medium at 6.3 under CVSS 4.0, and counts the confidentiality impact as subsequent rather than direct. The difference reflects scoring method, not a dispute about the facts. Whether it is high or medium for you depends on what listens on loopback on your hosts.
How to check if you're exposed
Check the installed version of the Python package.
pip show flyto-core
pip list | grep -i flyto
If it is below 2.28.0, you are affected. Then ask what is listening on IPv6 loopback on the machines that run Flyto workflows: admin panels, databases, metrics endpoints and local agents often bind to localhost with no authentication, because the assumption is that only local processes can reach them. A forged request from the application turns that assumption into a hole.
Also check who can define workflows. The requests come from workflow definitions, so the people able to author them are the people able to trigger the issue.
What to do now
- Upgrade with
python -m pip install --upgrade flyto-core==2.28.0, as the release notes suggest, or any later version. - Review which services bind to localhost on the hosts that run Flyto, and add authentication to any that have none.
- Restrict workflow authoring to trusted users until the upgrade is done.
- If you have your own address allowlist or blocklist code, test the IPv6 forms such as
::and mapped addresses as well as the IPv4 ones. - Put egress filtering around the workflow host, so that it can only reach destinations it needs.
Why it matters
The class is server-side request forgery, CWE-918. The application fetches a URL on behalf of a user and tries to refuse private destinations. The advisory explains that the check relies on a hand-maintained list of private ranges which includes the IPv6 loopback address but not the all-zeros address. The kernel treats a connection to :: as a connection to loopback, in the same way it treats 0.0.0.0 on IPv4. The IPv4 form was blocked in two places, the IPv6 form in none.
Lists of bad addresses tend to miss one. A safer pattern is to resolve the name, then test the resulting address with a library that classifies loopback, link-local, private and unspecified ranges for you, and to connect to that exact address. The advisory also describes redirects as a route to the same bypass, so every hop needs the same check. KEV status is false.
Quick check
Why does the address :: reach loopback?
The advisory says the kernel routes a connect to :: to loopback, just as it does for 0.0.0.0 on IPv4. A validator that only knows the loopback address ::1 therefore misses it.
Is this the same as a cloud metadata attack?
Cloud metadata services are a common SSRF target, but this advisory is about IPv6 loopback services. Egress filtering helps against both.
Sources
Last reviewed: 18 October 2026.
