Flyto2 Core: SSRF guard bypass via IPv6 transition addresses (IPv4-mapped / 6to4 / NAT64) in validate_url_ssrf
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.3, validate_url_ssrf and is_private_ip in src/core/utils.py compare resolved addresses only against native private IPv4 and IPv6 ranges and do not unwrap IPv4-mapped, IPv4-compatible, 6to4, or NAT64 transition addresses. An authenticated workflow author can provide a transition-form literal URL through the Execution API POST /v1/execute route, http.get, or sibling guarded outbound-request modules, causing the guard to accept an address whose embedded IPv4 points to loopback, RFC 1918, or cloud metadata services. On a host that routes the selected transition form, the outbound request reaches the internal destination and returns the response body to the workflow caller, enabling read SSRF and disclosure of internal-service data or cloud credentials. This issue is fixed in version 2.26.3.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-55787
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 7 Nov 2026, 07:05 UTC · Revision 1
Source evidence
Flyto2 Core: SSRF guard bypass via IPv6 transition addresses (IPv4-mapped / 6to4 / NAT64) in validate_url_ssrf
core-osv · Original sourcePublished 14 Oct 2026, 18:13 UTC
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.3, validate_url_ssrf and is_private_ip in src/core/utils.py compare resolved addresses only against native private IPv4 and IPv6 ranges and do not unwrap IPv4-mapped, IPv4-compatible, 6to4, or NAT64 transition addresses. An authenticated workflow author can provide a transition-form literal URL through the Execution API POST /v1/execute route, http.get, or sibling guarded outbound-request modules, causing the guard to accept an address whose embedded IPv4 points to loopback, RFC 1918, or cloud metadata services. On a host that routes the selected transition form, the outbound request reaches the internal destination and returns the response body to the workflow caller, enabling read SSRF and disclosure of internal-service data or cloud credentials. This issue is fixed in version 2.26.3.
osv:CVE-2026-55787
Complete source record
{
"id": "b943bd3f08bb3cdaba7dd173cb30a9a715bc05eceb0deb0f26708bade651cf4c",
"url": "https://osv.dev/vulnerability/CVE-2026-55787",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Flyto2 Core: SSRF guard bypass via IPv6 transition addresses (IPv4-mapped / 6to4 / NAT64) in validate_url_ssrf",
"summary": "Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.3, validate_url_ssrf and is_private_ip in src/core/utils.py compare resolved addresses only against native private IPv4 and IPv6 ranges and do not unwrap IPv4-mapped, IPv4-compatible, 6to4, or NAT64 transition addresses. An authenticated workflow author can provide a transition-form literal URL through the Execution API POST /v1/execute route, http.get, or sibling guarded outbound-request modules, causing the guard to accept an address whose embedded IPv4 points to loopback, RFC 1918, or cloud metadata services. On a host that routes the selected transition form, the outbound request reaches the internal destination and returns the response body to the workflow caller, enabling read SSRF and disclosure of internal-service data or cloud credentials. This issue is fixed in version 2.26.3.",
"evidence": "osv:CVE-2026-55787",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-55787",
"aliases": [
"CVE-2026-55787",
"GHSA-794r-5rp2-fpg8",
"PYSEC-2026-2481"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/flytohub/flyto-core",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "e8c6fd9902ff93389cd2e3ecaa472b7d91aec67e"
},
{
"fixed": "519e040384a74984848c4e84a6600e5f1020a6d2"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "2.26.3"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"fixed": "519e040384a74984848c4e84a6600e5f1020a6d2"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "e8c6fd9902ff93389cd2e3ecaa472b7d91aec67e"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v2.26.3"
}
]
}
}
],
"versions": [
"v2.26.0",
"v2.25.27",
"v2.17.6",
"v2.16.3",
"v2.5.0",
"v2.2.2"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-55787.json"
}
}
],
"modified": "2026-10-28T02:30:50.064657120Z",
"provider": "osv",
"references": [
"https://github.com/flytohub/flyto-core/releases/tag/v2.26.3",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55787.json",
"https://github.com/flytohub/flyto-core/security/advisories/GHSA-794r-5rp2-fpg8",
"https://nvd.nist.gov/vuln/detail/CVE-2026-55787",
"https://github.com/flytohub/flyto-core/commit/519e040384a74984848c4e84a6600e5f1020a6d2",
"https://github.com/flytohub/flyto-core/pull/20"
],
"provider_metadata": {
"cwe_ids": [
"CWE-918"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55787.json"
}
},
"related_cves": [
{
"value": "CVE-2026-55787",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 518588,
"published_at": "2026-10-14T18:13:52.454+00:00"
}