SeaweedFS 4.40: cztery luki w izolacji tenantów przez S3, SFTP i TUS

Cztery opublikowane rekordy podatności w SeaweedFS składają się na jedną ważną historię architektoniczną. CVE-2026-77298 dotyczy pominięcia polityki zaufania roli w bezpośrednim logowaniu OIDC do interfejsu S3, CVE-2026-77317 — błędnego porównywania prefiksów ścieżek w SFTP, CVE-2026-77368 — braku ponownego sprawdzenia zakresu tokenu JWT przy operacjach na sesji TUS, a CVE-2026-77611 — zapisania ACL do innego obiektu niż ten, dla którego wykonano autoryzację.

To nie są cztery warianty tej samej funkcji. Błędy leżą w różnych protokołach i mają inne warunki wykorzystania, ale każdy łamie ten sam niezmiennik: podmiot powinien móc zmienić lub odczytać wyłącznie zasób, który został sprawdzony przez tę samą politykę. W wydaniu 4.40 znalazły się odpowiednie poprawki. Ponieważ dostępna jest już nowsza linia, zespoły powinny wdrożyć najnowszą wspieraną wersję, a jeśli organizacyjne okno zmian na to nie pozwala — co najmniej 4.40 po przeprowadzeniu testów regresji.

Rekordy CVE zostały zindeksowane 27 sierpnia. Powiązane biuletyny GitHub i poprawki powstawały wcześniej, a wydanie 4.40 opublikowano 20 lipca. Data bieżącego katalogu nie oznacza zatem, że producent dopiero dziś napisał poprawkę. Oznacza, że dziś administratorzy otrzymali spójny zestaw identyfikatorów, zakresów wersji i ocen ryzyka, które można powiązać z inwentarzem.

CVE-2026-77298: poprawny token OIDC bez pełnej decyzji zaufania

SeaweedFS udostępnia między innymi API zgodne z S3. W podatnej ścieżce bezpośredni token OIDC był weryfikowany kryptograficznie i mapowany na rolę, ale kod nie wykonywał sprawdzenia polityki zaufania tej roli. Ten sam token przesłany przez przepływ STS zostałby odrzucony. Problem nie polegał więc na braku walidacji podpisu, lecz na niespójności dwóch wejść do tego samego modelu uprawnień.

To kluczowe rozróżnienie. Podpis odpowiada na pytanie, czy token pochodzi od oczekiwanego wystawcy i czy nie został zmieniony. Nie rozstrzyga samodzielnie, czy konkretny wystawca, klient, podmiot i zestaw warunków mogą przyjąć daną rolę. Polityka zaufania jest drugą decyzją. Jej pominięcie może przyznać użytkownikowi uprawnienia roli, której nie powinien uzyskać.

Według rekordu CVE podatne są wersje do 4.39 włącznie, poprawiona jest 4.40, a wynik CVSS 4.0 wynosi 8,7 (High). Realny skutek zależy od konfiguracji OIDC i polityk ról. Instalacja bez bezpośredniego uwierzytelniania OIDC do S3 nie udostępnia tej ścieżki. Instalacja z jedną bardzo ograniczoną rolą może mieć mniejszy wpływ niż platforma, w której tokeny mapują się na role administracyjne lub szerokie przestrzenie bucketów.

CVE-2026-77317: prefiks tekstowy nie jest granicą katalogu

W SFTP kontrola ACL porównywała ścieżki jako dosłowne prefiksy. Jeżeli tenant miał dostęp do /tenants/alice, zwykłe sprawdzenie początku tekstu mogło uznać za zgodne także /tenants/alice2. Z punktu widzenia łańcucha znaków wynik jest prawdziwy. Z punktu widzenia drzewa katalogów są to równorzędne, różne przestrzenie.

To klasyczna pomyłka między nazwą a strukturą. Poprawna kontrola powinna najpierw kanonikalizować ścieżkę, a następnie wymagać równości z dozwolonym katalogiem albo obecności separatora bezpośrednio po dozwolonym prefiksie. Musi też zachować ostrożność wobec .., powtarzających się separatorów, kodowania i dowiązań, jeśli występują w danej warstwie.

CVE obejmuje wersje od 3.88 do 4.39 i ma wynik CVSS 3.1 równy 8,1 (High). Skutek opisany w advisory to możliwość odczytu lub nadpisania plików innego tenanta o kolidującym początku nazwy ścieżki. Nie wystarczy więc sprawdzić, czy użytkownicy „mają osobne foldery”. Trzeba sprawdzić sposób, w jaki aplikacja interpretuje granicę folderu przy każdej operacji.

CVE-2026-77368: autoryzacja sesji TUS tylko podczas jej utworzenia

TUS jest protokołem wznawialnego przesyłania plików. W SeaweedFS 4.39 tworzenie sesji sprawdzało allowed_prefixes z tokenu JWT wobec docelowej ścieżki. Kolejne operacje HEAD, PATCH i DELETE odwoływały się jednak do identyfikatora sesji, nie odtwarzając i nie sprawdzając zakresu zapisanej ścieżki. Użytkownik znający identyfikator cudzej sesji mógł w rezultacie oddziaływać na upload poza własnym zakresem.

Ta luka pokazuje różnicę między autoryzacją utworzenia uchwytu a autoryzacją użycia uchwytu. Identyfikator sesji jest tylko referencją do stanu. Nie powinien zastępować decyzji dostępowej. Bezpieczna implementacja przy każdym żądaniu wiąże bieżącą tożsamość i jej aktualny zakres z docelowym zasobem zapisanym w sesji.

Problem dotyczy wersji 4.39 i wdrożeń, które jednocześnie korzystają z JWT filera oraz TUS. Wynik to CVSS 3.1 równy 7,6 (High). Nie należy przenosić tej oceny automatycznie na instalacje bez TUS. Zespół powinien najpierw ustalić, czy endpoint jest aktywny, dostępny z niezaufanej sieci i czy identyfikatory sesji mogły trafić do logów, przeglądarki, telemetrii albo komunikatów błędów.

CVE-2026-77611: sprawdzono klucz zagnieżdżony, zapisano obiekt w korzeniu

Czwarty błąd dotyczy operacji PutObjectAcl w interfejsie S3. Kod autoryzował żądanie wobec zagnieżdżonego klucza, do którego podmiot miał uprawnienia, ale modyfikację wpisu wykonywał na poziomie korzenia bucketa. Jeżeli poza dozwolonym zakresem istniał obiekt o tej samej nazwie bazowej, jego metadane mogły zostać nadpisane.

To przypadek rozdzielenia obiektu autoryzacji od obiektu mutacji. W recenzji kodu oba parametry mogą wyglądać poprawnie: żądanie zawiera bucket i klucz, a funkcja zapisu otrzymuje nazwę. Błąd ujawnia się dopiero po sprawdzeniu, czy ścieżka wykorzystana przez mechanizm uprawnień jest dokładnie tym samym znormalizowanym identyfikatorem, który trafia do warstwy przechowywania.

Podatne są wydania wcześniejsze niż 4.40, a wynik wynosi CVSS 3.1: 7,1 (High). Skutek nie jest ogólnym zapisem dowolnego pliku. Dotyczy szczególnego połączenia uprawnienia do zmiany ACL z kolizją nazwy bazowej. W środowisku wielotenantowym wystarczy jednak możliwość naruszenia kontroli dostępu obiektu poza zakresem, aby potraktować sprawę jako istotny incydent integralności.

Cztery różne błędy, jeden test bezpieczeństwa

Wszystkie przypadki można ująć jednym pytaniem: czy zasób wykorzystany do decyzji autoryzacyjnej jest identyczny z zasobem, na którym wykonujemy operację?

W OIDC zabrakło części decyzji — polityki zaufania roli. W SFTP tekstowy prefiks udawał granicę strukturalną. W TUS raz sprawdzona ścieżka zniknęła za identyfikatorem sesji. W PutObjectAcl sprawdzono pełny klucz, lecz zapis trafił do jego nazwy w innym katalogu. Te wzorce warto dodać do przeglądów architektury także poza SeaweedFS.

Macierz testów powinna obejmować nie tylko „dozwolone” i „zabronione”. Potrzebne są sąsiednie nazwy (alice i alice2), ten sam basename w różnych katalogach, uchwyty utworzone przez różne podmioty, odnowienie tokenu w połowie sesji, wygaśnięcie roli oraz dwa alternatywne przepływy prowadzące do tej samej roli. Każdy protokół powinien kończyć w jednej, wspólnej warstwie polityki albo udowadniać równoważność decyzji.

Co administrator powinien zrobić teraz

Najpierw zinwentaryzuj wersje serwerów, obrazów kontenerowych i narzędzi wdrożeniowych. Numer w deklaracji Helm nie zawsze odpowiada działającemu digestowi obrazu. Sprawdź procesy i endpointy rzeczywiście obsługujące S3, SFTP, filer JWT i TUS. Następnie ustal, które z czterech warunków są osiągalne w twojej konfiguracji.

Wdróż najnowsze wspierane wydanie SeaweedFS — dziś jest ono nowsze niż 4.40 — albo co najmniej 4.40, jeżeli to zatwierdzony cel naprawczy. Przed zmianą wykonaj kopię metadanych zgodnie z procedurą producenta i przetestuj kompatybilność klientów, szczególnie mapowanie ról OIDC, operacje ACL, wznawianie uploadu oraz restrykcje katalogów SFTP.

Nie traktuj wyłączenia publicznego routingu jako kompletnej mitygacji w środowisku wielotenantowym. Podmiot mający legalne konto, token albo ścieżkę w jednym tenancie nadal może być stroną zagrożenia. Segmentacja ogranicza osiągalność, lecz nie przywraca brakującej kontroli obiektowej.

Do czasu aktualizacji można wyłączyć nieużywane protokoły, usunąć bezpośredni przepływ OIDC do S3 na rzecz poprawnie kontrolowanej ścieżki, ograniczyć TUS i SFTP do zaufanych sieci oraz zmniejszyć zakres ról. Są to środki tymczasowe. Każdy zmienia funkcjonalność i powinien zostać zweryfikowany na kopii konfiguracji.

Jak szukać śladów naruszenia

Dla OIDC porównaj żądania bezpośredniego logowania S3 z decyzjami STS: ta sama tożsamość nie powinna uzyskiwać roli w jednej ścieżce i otrzymywać odmowy w drugiej. Zapisuj wystawcę, klienta, podmiot, rolę oraz wynik polityki, ale nie całe tokeny. Wyszukaj role o szerokim zakresie używane przez podmioty, które nie spełniają polityki zaufania.

Dla SFTP przejrzyj operacje, w których przyznany katalog i faktyczna ścieżka mają wspólny prefiks tekstowy, lecz różny pierwszy segment po tej granicy. Dla TUS koreluj właściciela sesji, hash lub znormalizowaną ścieżkę docelową oraz podmiot wykonujący kolejne metody. Zmiana właściciela pomiędzy utworzeniem a modyfikacją wymaga wyjaśnienia.

Dla S3 ACL porównaj autoryzowany pełny klucz z wpisem faktycznie zmodyfikowanym w metadanych. Szukaj kolizji nazw bazowych i zmian ACL w korzeniu bucketa wykonanych w czasie żądań dotyczących zagnieżdżonych obiektów. Zachowaj logi, konfigurację ról, metadane obiektów i identyfikatory obrazów przed ich rotacją.

Sama obecność podatnej wersji nie dowodzi wykorzystania. Z kolei brak błędu HTTP nie dowodzi bezpieczeństwa, ponieważ opisane operacje mogły zakończyć się sukcesem z punktu widzenia klienta. Ocena incydentu powinna połączyć osiągalność, uprawnienia podmiotu i zmianę konkretnego zasobu.

Fakty źródłowe a wnioski Breachroad

Źródła producenta i rekordy CVE opisują zakres wersji, wymagane konfiguracje, klasy błędów oraz poprawki w 4.40. Oceny CVSS pochodzą z tych rekordów. Rekomendacje dotyczące wspólnej warstwy polityki, macierzy testów, korelacji logów i wyboru najnowszego wspieranego wydania są wnioskami obronnymi Breachroad opartymi na opisanych mechanizmach.

Widoki GitHub Advisory mogą przez pewien czas pokazywać niepełne pole „patched version”, mimo że rekordy CVE, poprawki i informacje o wydaniu wskazują 4.40. W procesie zarządzania podatnościami warto zachować tę różnicę jako informację o jakości danych, a nie usuwać zgłoszenie tylko dlatego, że jeden agregator nie wypełnił pola.

Źródła pierwotne

Granice dostępu najczęściej zawodzą na styku protokołów, a nie w jednej oczywistej funkcji. Na szkoleniu z cyberbezpieczeństwa dla zespołów technicznych pokazujemy, jak projektować i testować takie niezmienniki w chmurze, API i systemach AI. Jeżeli potrzebujesz niezależnej weryfikacji działającego wdrożenia, testy penetracyjne aplikacji webowych i API mogą objąć autoryzację obiektową i izolację tenantów w kontrolowanym zakresie.