CVE-2026-44911

W Apache NiFi przed wersją 0.7.2 oraz 1.x przed wersją 1.1.2, w środowisku klastrowym, jeśli żądanie anonimowego użytkownika jest replikowane do innego węzła, to tożsamość węzła źródłowego jest używana zamiast tożsamości 'anonimowego' użytkownika.

Apache NiFi w wersjach przed 0.7.4 oraz 1.x przed 1.3.0 nie ustawia nagłówka odpowiedzi, który informuje przeglądarki, aby zezwalały na osadzanie tylko z tego samego źródła.

Apache NiFi w wersjach 2.0.0 do 2.10.0 umożliwia tworzenie, odczytywanie i usuwanie Assetów powiązanych z kontekstami parametrów przez REST API. Framework autoryzuje usuwanie Assetów na podstawie identyfikatora kontekstu parametru, ale nie weryfikuje, czy Asset faktycznie należy do tego kontekstu. Instalacje bez zróżnicowanych poziomów autoryzacji między kontekstami nie są podatne. Aktualizacja do wersji 2.11.0 rozwiązuje problem.

Apache NiFi w wersjach od 1.10.0 do 2.10.0 udostępnia metodę REST API do aktualizacji kontekstu parametrów, która nie wymusza sprawdzania autoryzacji na komponentach odwołujących się do wartości parametrów. Uwierzytelniony użytkownik upoważniony do modyfikacji kontekstu parametrów, ale nieupoważniony do komponentów odwołujących się, może zmienić wartości parametrów wpływające na te komponenty. W przypadku, gdy wartość parametru zawiera skryptowalną treść, aktualizacja parametru może prowadzić do wykonania kodu podczas automatycznej walidacji komponentu. Problem dotyczy tylko wdrożeń z politykami autoryzacji na poziomie komponentów. Zalecana jest aktualizacja do Apache NiFi 2.11.0.

W Apache NiFi przed wersją 0.7.2 oraz 1.x przed wersją 1.1.2 w środowisku klastrowym, proces serializacji/deserializacji łańcucha proxy jest podatny na atak typu injection, który pozwala na podszycie się pod innego użytkownika za pomocą starannie skonstruowanej nazwy użytkownika.

Apache NiFi 2.11.0 udostępnia metody REST API do migracji zawartości wersjonowanej grupy procesów do Connectora, które autoryzują żądania wyłącznie względem docelowego Connectora, bez sprawdzania uprawnień do zaangażowanych grup procesów. Uwierzytelniony użytkownik z prawem odczytu Connectora może wyliczyć identyfikatory, nazwy i szczegóły rejestru przepływów grup procesów poza zakresem jego uprawnień, a użytkownik z prawem zapisu może zmigrować grupę procesów bez uprawnień do niej.

Apache NiFi w wersjach od 1.5.0 do 2.11.0 udostępnia metody REST API zastępujące całą zawartość Process Group na podstawie definicji przepływu dostarczonej przez klienta. Autoryzacja frameworku dla tych metod ograniczała się do uprawnień odczytu i zapisu na samej Process Group, w przeciwieństwie do asynchronicznych metod aktualizacji, które autoryzują również komponenty wewnątrz grupy oraz powiązane Controller Services, Parameter Contexts i Parameter Providers. W efekcie uwierzytelniony użytkownik z prawem zapisu mógł modyfikować lub usuwać komponenty w podrzędnych Process Groups objętych bardziej restrykcyjnymi politykami.

Apache NiFi w wersjach od 2.9.0 do 2.11.0 udostępnia metody REST API aktualizacji i weryfikacji konfiguracji Connectora, które nie wymuszają sprawdzania autoryzacji dla Assets i Secrets wskazanych w proponowanej konfiguracji. Uwierzytelniony użytkownik uprawniony do modyfikacji Connectora, ale nie do odczytu powiązanego Parameter Providera, może zastosować wartości Secret z tego Parameter Providera; metody akceptują też identyfikatory Assetów bez weryfikacji przynależności do konfigurowanego Connectora.

Apache NiFi 2.11.0 wyłączył obsługę żądań HTTP z kodowaniem gzip dla REST API i odrzucał żądania zawierające standardowy nagłówek Content-Encoding wskazujący gzip. Filtr egzekwujący w frameworku nie sprawdzał jednak wielu wystąpień nagłówka Content-Encoding ani niestandardowych identyfikatorów kodowania gzip, co pozwalało złośliwemu klientowi wysyłać spreparowane żądania powodujące nadmierne zużycie pamięci.

Apache NiFi od wersji 1.5.0 do 2.10.0 obsługuje zakodowane gzip żądania HTTP dla REST API przy użyciu filtra kodowania Jersey. Framework egzekwował konfigurowalny maksymalny rozmiar żądania na skompresowanym ładunku, a nie na zdekompresowanym wyjściu, co pozwalało złośliwemu klientowi na wysyłanie spreparowanych żądań, które mogły zużywać nadmierne ilości pamięci.