CVE-2026-53577

W Kestra przed wersjami 1.0.45 i 1.3.21 filtr uwierzytelniania REST API pomija sprawdzanie poświadczeń dla żądań kończących się na '/configs'. Niezalogowany atakujący może wykorzystać to do tworzenia przepływów z zadaniami Shell lub Process, które wykonują się jako root w kontenerze, a przez zamontowany /var/run/docker.sock uzyskują dostęp do demona Dockera na hoście.

W Kestra OSS przed wersjami 1.0.45 i 1.3.21, filtr AuthenticationFilter używa metody endsWith("/configs") do sprawdzenia, czy żądanie dotyczy publicznego endpointu konfiguracji. Ponieważ jest to dopasowanie sufiksu, a nie dokładnej ścieżki, każdy interfejs API, którego ostatni segment to "configs", omija uwierzytelnianie. Niezautoryzowany atakujący może wykorzystać tę lukę do tworzenia i wykonywania dowolnych przepływów pracy bez poświadczeń.

Kestra w wersji 1.3.3 i wcześniejszych jest podatna na wstrzykiwanie SQL. Podatność wynika z bezpośredniego konkatenowania danych wejściowych użytkownika z parametru GET do zapytania SQL bez odpowiedniego oczyszczania lub parametryzacji.

Kestra przed wersją 1.3.7 zawiera podatność na iniekcję SQL w endpointzie GET /api/v1/main/flows/search, która umożliwia uwierzytelnionemu atakującemu zdalne wykonanie kodu poprzez PostgreSQL COPY ... TO PROGRAM.

Kestra przed wersją 1.3.24 zawiera podatność na przechowywany XSS w niestandardowym parserze Markdown. Użytkownik z uprawnieniami do tworzenia lub aktualizacji opisu Flow może wstrzyknąć atrybuty obsługi zdarzeń JavaScript przez składnię [[link]], co powoduje wykonanie skryptu, gdy inny użytkownik otworzy opis lub panel informacyjny.

Kestra przed wersją 2.0.0 przekazuje kontrolowany przez użytkownika argument uri funkcji http() do URI.create() i serwerowego klienta HTTP bez ograniczania miejsc docelowych prywatnych, pętli zwrotnej lub link-local, co pozwala nieuwierzytelnionemu atakującemu zaimportować i wykonać przepływ, który uzyskuje dostęp do wewnętrznych usług lub metadanych chmury.

Kestra przed wersją 2.0.0-rc6 udostępnia punkt końcowy GET /worker bez uwierzytelnienia i serializuje kompletny obiekt Task, co może ujawnić polecenia, zmienne środowiskowe, nagłówki HTTP, dane połączeń, poświadczenia w postaci jawnego tekstu oraz identyfikatory wykonania, podczas gdy główne API na porcie 8080 pozostaje chronione. Problem został naprawiony w wersji 2.0.0-rc6.

Podatność w Kestra przed wersją 2.0.0-rc6 polega na tym, że endpointy zarządzania Micronaut na porcie 8081 są dostępne bez uwierzytelnienia, nawet gdy Basic Auth chroni /api/v1/** na porcie 8080. Umożliwia to nieuwierzytelniony odczyt zmiennych środowiskowych i zmianę poziomów logowania.

Podatność w komponencie BasicAuth platformy Kestra OSS przed wersją 1.3.24 umożliwia atakującemu z dostępem do bazy PostgreSQL odzyskanie hasła administratora offline dzięki szybkości obliczeniowej SHA-512. W środowiskach Kubernetes pozwala to na eskalację uprawnień do odczytu tokena ServiceAccount i wszystkich sekretów klastra.

W Kestra przed wersjami 1.0.45 i 1.3.23 lokalny backend przechowywania wewnętrznego nieprawidłowo waliduje ścieżki użytkownika, umożliwiając atakującemu przemycenie sekwencji przejścia do katalogu nadrzędnego za pomocą ukośników odwrotnych (..\..\..\) przed konwersją na ukośniki zwykłe. Uwierzytelniony użytkownik z najniższymi uprawnieniami może odczytać dowolny plik w systemie plików serwera, w tym bazę H2, przechowywane sekrety i dane uwierzytelniające.