CVE-2026-67425

Podatność w Flyto2 Core przed wersją 2.26.6 pozwala atakującemu na zapis plików w dowolnej lokalizacji systemu plików poprzez kontrolowanie parametru output_dir w module image.download. Brak walidacji ścieżki względem konfiguracji FLYTO_SANDBOX_DIR umożliwia zapis danych odpowiedzi w dowolnym miejscu.

Podatność w Flyto2 Core przed wersją 2.26.7 w usłudze flyto-verification umożliwia nieuwierzytelnionym atakującym wykonanie SSRF i kradzież sekretu runnera. Serwer nasłuchuje na 0.0.0.0:8344 i używa callback_url podanego przez klienta do wysłania żądania POST z nagłówkiem X-Internal-Key, pomijając walidację target_allowed.

Flyto2 Core, jądro wykonawcze dla automatyzacji i przepływów pracy agentów AI, przed wersją 2.26.3 w funkcjach validate_url_ssrf i is_private_ip w src/core/utils.py porównuje rozwiązane adresy tylko z natywnymi prywatnymi zakresami IPv4 i IPv6 i nie odwija adresów przejściowych IPv4-mapped, IPv4-compatible, 6to4 ani NAT64. Uwierzytelniony autor przepływu pracy może podać URL w formie przejściowej przez Execution API POST /v1/execute, http.get lub pokrewne moduły wychodzących żądań, powodując, że guard akceptuje adres, którego osadzony IPv4 wskazuje na loopback, RFC 1918 lub usługi metadanych chmury. Na hoście, który routuje wybraną formę przejściową, żądanie wychodzące dociera do wewnętrznego celu i zwraca treść odpowiedzi do wywołującego przepływ, umożliwiając odczyt SSRF i ujawnienie danych usług wewnętrznych lub poświadczeń chmury.

Flyto2 Core, jądro wykonawcze dla automatyzacji i przepływów pracy agentów AI, od wersji 2.26.2 do 2.26.4 w trasie HTTP MCP POST /mcp akceptuje nieuwierzytelnione żądania JSON-RPC tools/call i przekazuje argumenty execute_module do rejestru modułów bez zależności require_auth używanej przez trasy REST. Nieuwierzytelniony wywołujący może wybrać sandbox.execute_shell i podać parametr command, który trafia do asyncio.create_subprocess_shell z uprawnieniami procesu serwera flyto-core. Punkt końcowy jest osiągalny lokalnie przy domyślnym bindowaniu loopback i staje się osiągalny sieciowo, gdy operator zbinduje serwer na interfejsie innym niż loopback, umożliwiając wykonanie dowolnych poleceń systemowych i potencjalną pełną kompromitację hosta.

Flyto2 Core przed wersją 2.28.0 zawiera podatność polegającą na obejściu zabezpieczeń SSRF, która pozwala atakującym na dostęp do wewnętrznych usług poprzez użycie nieblokowanego adresu IPv6 `::`, który jądro kieruje do loopbacku tak samo jak `0.0.0.0`. Atakujący mogą wysyłać żądania lub wywoływać przekierowania 302, aby ominąć sprawdzanie prywatnych zakresów IP i zablokowanych nazw hostów w funkcji is_private_ip(), docierając do usług nasłuchujących na IPv6 loopback w modułach http.get, http.request i http.batch.

Podatność w Flyto2 Core przed wersją 2.26.7 umożliwia atakującemu wykonanie żądań SSRF do wewnętrznych lub metadanych endpointów poprzez moduły HTTP, które pobierają URL-e kontrolowane przez atakującego bez walidacji.

Podatność w Flyto2 Core przed wersją 2.26.6 umożliwia rozwijanie zmiennych środowiskowych ${env.VAR} bez listy dozwolonych, co pozwala na ominięcie polityki blokowania i wyciek sekretów przez dozwolone moduły.

W Flyto2 Core przed wersją 2.26.7 moduły HTTP walidują tylko początkowy URL, a następnie podążają za przekierowaniami bez ponownej walidacji lokalizacji. Pozwala to publicznemu URL-owi przekierować do wewnętrznej przestrzeni adresowej i zwrócić odpowiedź z wewnętrznego serwera.