Podatność path traversal w lokalnym backendzie storage platformy Kestra pozwala uwierzytelnionemu użytkownikowi o najniższych uprawnieniach odczytać dowolny plik na serwerze dostępny dla procesu Kestra. Stanowi całkowite naruszenie izolacji storage oraz granic wielodostępności (multi-tenancy).
▸ Pokaż oryginał (EN)
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.23, the local internal-storage backend validates user-supplied paths for .. traversal before it converts Windows-style backslashes to forward slashes. An attacker can therefore smuggle a traversal sequence past the guard using backslashes (..\..\..\); the guard sees a harmless string, and the path is only rewritten to ../../../ after validation, immediately before the file is opened. Any authenticated user who can view an execution (the lowest-privilege role) can call GET /api/v1/{tenant}/executions/{executionId}/file?path=… and read any file on the server filesystem readable by the Kestra process, outside the storage sandbox and across every tenant and namespace. This includes the embedded H2 database (all flows, all users, all stored secrets), internal storage of every other tenant/namespace, mounted secret files, and the process environment (/proc/self/environ) which contains configured database and secret-backend credentials. It is a complete breach of Kestra's storage isolation and multi-tenancy boundary. This vulnerability is fixed in 1.0.45 and 1.3.23.
Backend lokalnego storage waliduje ścieżki dostarczone przez użytkownika pod kątem sekwencji path traversal (np. `../`) zanim dokona konwersji backslashy (`\`) na ukośniki (`/`). Atakujący może przemycić sekwencję traversal używając windowsowego separatora (np. `..\..\..\ `): mechanizm walidacji widzi pozornie bezpieczny ciąg znaków, natomiast dopiero po jej przejściu ścieżka jest przepisywana na `../../../` — tuż przed otwarciem pliku. Wystarczy wywołać endpoint GET `/api/v1/{tenant}/executions/{executionId}/file?path=…` z odpowiednio spreparowaną ścieżką.
Atakujący może odczytać dowolny plik na serwerze dostępny dla procesu Kestra, w tym wbudowaną bazę H2 (wszystkie przepływy, użytkownicy, przechowywane sekrety), storage innych tenantów i namespace'ów, zamontowane pliki sekretów oraz zmienne środowiskowe procesu (`/proc/self/environ`) zawierające dane uwierzytelniające do baz danych i backendów sekretów.
Należy zaktualizować Kestra do wersji 1.0.45 lub 1.3.23 (odpowiednio do używanej gałęzi), w których podatność została naprawiona. Przed aktualizacją warto rozważyć ograniczenie dostępu sieciowego do API Kestra wyłącznie do zaufanych użytkowników.
Kestra w wersjach wcześniejszych niż 1.0.45 oraz wcześniejszych niż 1.3.23, korzystających z lokalnego backendowego storage (local internal-storage backend).
Podatność dotyczy wyłącznie konfiguracji z lokalnym backendem storage. Luka umożliwia cross-tenant odczyt danych, co czyni ją szczególnie groźną w środowiskach wielodostępnych. Szczegóły opublikowane w ramach GitHub Security Advisory GHSA-qw4v-6w32-xx9h.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:NKestra
APPKestra< 1.0.451.1.0 – 1.3.23 (bez)
Powiązane podatności
Kestra: Auth Bypass umożliwiający nieuwierzytelniony RCE jako root
Kestra: Pominięcie uwierzytelnienia REST API prowadzące do RCE jako root
SQL Injection w Kestra — wstrzykiwanie zapytań przez parametr GET
SQL Injection prowadzący do RCE w platformie Kestra (endpoint wyszukiwania flows)
Kestra: słabe hashowanie haseł (SHA-512) umożliwia privilege escalation