CVE-2026-104355

Temporal Server nie wiąże wewnętrznych wywołań zwrotnych z przestrzenią nazw, która je dołączyła, co pozwala uwierzytelnionemu wywołującemu z uprawnieniami zapisu w jednej przestrzeni nazw na zmianę stanu harmonogramu Scheduler V2 w innej przestrzeni nazw. Adres wywołania zwrotnego temporal://internal jest zarezerwowany dla wywołań, które Scheduler V2 dołącza do uruchamianych przez siebie Workflows. W dotkniętych wersjach każdy uwierzytelniony wywołujący mógł dołączyć wywołanie zwrotne z tym adresem do żądania uruchomienia Workflow, adres był wyłączony z listy dozwolonych component.callbacks.allowedAddresses, a usługa History dostarczała wywołanie do komponentu wskazanego przez token, w dowolnej przestrzeni nazw, bez autoryzacji oryginalnego wywołującego. Gdy sfałszowane zakończenie pasuje do działania uruchomionego przez docelowy harmonogram, harmonogram rejestruje działanie jako ukończone, podczas gdy jego Workflow nadal działa, co może ominąć politykę nakładania się, taką jak SKIP, i przekazuje dane kontrolowane przez wywołującego do następnego zaplanowanego Workflow jako wynik ostatniego zakończenia. Sfałszowana awaria może również wstrzymać harmonogram skonfigurowany do wstrzymywania przy awarii. Sfałszowanie wymaga identyfikatora docelowej przestrzeni nazw, identyfikatora harmonogramu oraz tożsamości i czasu trwania uruchomionego działania. Nie zidentyfikowano ujawnienia ładunków Workflow ani historii. Tylko przestrzenie nazw zawierające harmonogramy Scheduler V2 mogą być celem; Scheduler V2 jest domyślnie wyłączony, a istniejące harmonogramy Scheduler V2 pozostają celami po wyłączeniu ustawień, które je tworzą.

Podatność w Temporal Server umożliwia uwierzytelnionemu użytkownikowi z uprawnieniami zapisu w pojedynczej przestrzeni nazw (namespace) wykonanie dowolnego polecenia na hoście, na którym działa Worker Service. Polecenie jest wykonywane natychmiast, a proces Worker Service posiada dostęp do danych uwierzytelniających i kluczy TLS całego klastra, co eskaluje wpływ do całego klastra. Luka dotyczy wersji od 1.31.0 do 1.31.2 (przed 1.31.3) i jest obecna w domyślnych binariach i obrazach kontenerowych.

Temporal Server w wersjach 1.30.0 i nowszych decydował o tym, czy callback zakończenia Workflow jest wewnętrzny, na podstawie nagłówka HTTP dostarczonego przez wywołującego. Uwierzytelniony użytkownik z uprawnieniami zapisu w jednej przestrzeni nazw mógł dołączyć callback, którego nagłówek 'source' powodował przekierowanie żądania do wewnętrznego frontendu i wykonanie dowolnego żądania POST na administracyjnym API jako administrator systemu. W wersjach 1.25.0–1.29.7 występuje węższa wersja tej samej wady, wymagająca zgodności nagłówka z identyfikatorem klastra.

Temporal Server nie ograniczał pracy wykonywanej podczas wyszukiwania następnego czasu akcji harmonogramu. Uwierzytelniony użytkownik z uprawnieniami zapisu w namespace mógł utworzyć harmonogram łączący drobnoziarnisty interwał z kalendarzem wykluczeń odrzucającym każdy kandydat, co powodowało nadmierne zużycie CPU w komponentach Frontend i Schedule worker.

W serwerze gRPC frontendu Temporal brakowało interceptora autoryzacji w łańcuchu przetwarzania strumieniowego. Skonfigurowane ClaimMapper i Authorizer były pomijane dla endpointu AdminService/StreamWorkflowReplicationMessages, co pozwalało na dostęp bez uwierzytelnienia.

Domyślne ustawienia w otwartym serwerze Temporal przed wersją 1.20 na wszystkich platformach umożliwiają atakującemu stworzenie tokena zadania z dostępem do innej przestrzeni nazw niż ta określona w żądaniu. Wymaga to UUID przestrzeni nazw oraz informacji z historii przepływu pracy dla docelowej przestrzeni nazw.