CVE-2026-87858

Serwer Temporal Server zdecydował, czy wywołanie zwrotne zakończenia przepływu pracy jest wewnętrzne, poprzez odczytanie nagłówka HTTP dostarczonego przez osobę wywołującą. Uwierzytelniony obiekt wywołujący posiadający tylko uprawnienia do zapisu w pojedynczej przestrzeni nazw może dołączyć wywołanie zwrotne zakończenia, którego host URL jest zgodny ze skonfigurowaną listą dozwolonych adresów wywołania zwrotnego, którego ścieżką URL jest dowolna trasa tymczasowego interfejsu API HTTP i którego mapa nagłówka zawiera niepusty nagłówek o nazwie source. Gdy usługa History dostarczyła to wywołanie zwrotne, niepusty nagłówek źródła spowodował, że ponownie skierowała żądanie do lokalnego klienta frontonu i przepisała tylko schemat i hosta, zachowując ścieżkę, zapytanie i treść żądania wywołującego. W przypadku wdrożenia wewnętrznego frontendu z włączonym interfejsem API HTTP, klient ten zostaje przekierowany do wewnętrznego frontendu, który autoryzuje każde żądanie jako administrator systemu bez konieczności podawania informacji uwierzytelniających. W rezultacie serwer wykonuje wybrany przez atakującego POST HTTP zmieniający stan w stosunku do własnego administracyjnego interfejsu API w imieniu osoby wywołującej, w przestrzeniach nazw, do których osoba wywołująca nie ma uprawnień. Osoba wywołująca nigdy nie potrzebuje dostępu sieciowego do wewnętrznego interfejsu użytkownika, ponieważ usługa Historia wysyła żądanie. Potwierdzone efekty obejmują kończenie przepływów pracy w innych przestrzeniach nazw, rejestrowanie przestrzeni nazw, modyfikowanie konfiguracji innej przestrzeni nazw oraz usuwanie innej przestrzeni nazw i jej przepływów pracy. Logika routingu, której dotyczy problem, występuje zarówno w implementacjach dostarczania wywołania zwrotnego HSM, jak i CHASM. Ten opis i wynik CVSS w tym rekordzie opisują wersje 1.30.0 i nowsze, w których wystarczający jest dowolny niepusty nagłówek źródłowy. W wersjach od 1.25.0 do 1.29.7 występuje węższa forma tego samego defektu, w której nagłówek musi dokładnie odpowiadać skonfigurowanemu identyfikatorowi klastra, czyli identyfikatorowi UUID, którego obiekt wywołujący o zakresie przestrzeni nazw nie może odczytać przez interfejs API. Konsekwencje po takim meczu są takie same, ale atak jest znacznie trudniejszy i ma niższy wynik. Aby określić, czy problem dotyczy wdrożenia, sprawdź jednocześnie dwa ustawienia: statyczną konfigurację serwera dla niezerowego Services.internal-frontend.rpc.httpPort i efektywną wartość konfiguracji dynamicznej dla przestrzeni nazw komponentu.callbacks.allowedAddresses. Wdrożenie jest ujawniane tylko wtedy, gdy wdrożono wewnętrzny frontend z niezerowym portem HTTP, co najmniej jedna reguła listy dozwolonych dopuszcza hosta i włączona jest autoryzacja. Lista dozwolonych jest domyślnie pusta, co odrzuca wszystkie zewnętrzne adresy URL wywołań zwrotnych, a standardowa topologia statyczna nie obejmuje wewnętrznego interfejsu. Należy pamiętać, że nieudane dołączenie powoduje zwrócenie błędu „nieprawidłowy adres URL: adres URL nie pasuje do żadnego skonfigurowanego adresu wywołania zwrotnego”, co dowodzi jedynie, że jeden testowany adres URL nie pasował i nie dowodzi, że efektywna lista dozwolonych jest pusta. Aby wyszukać już dołączone wywołania zwrotne, użyj funkcji DescribeWorkflowExecution, która zwraca informacje o wywołaniach zwrotnych dla zarejestrowanych wywołań zwrotnych zakończenia przepływu pracy. Operatorzy powinni zdawać sobie sprawę z luki podczas wyszukiwania dowodów dostarczenia: serwer API HTTP frontendu rejestruje metodę żądania i adres URL tylko na poziomie debugowania, więc na domyślnych poziomach logów dostarczone żądanie nie jest zapisywane w wewnętrznych logach frontendu, a brak takich wpisów w logu nie jest dowodem na to, że problem nie został wykorzystany.