CVE-2026-58371

Podatność w SeaweedFS w wersjach 4.08–4.33 umożliwia uwierzytelnionemu użytkownikowi S3 z niskimi uprawnieniami wyliczenie nazw i ARN-ów kubełków tabel należących do administratora. Problem wynika z błędnego routowania żądań SigV4 do API zarządzania S3Tables, gdzie autoryzacja scala tożsamości S3 bez konta z kontem administratora.

SeaweedFS przed wersją 4.24 zawiera podatność w RPC FetchAndWriteNeedle, która nie wymaga uwierzytelnienia ani walidacji celu. Atakujący może wysyłać żądania do dowolnych hostów, w tym do metadanych chmury (169.254.169.254), i odczytywać odpowiedzi.

SeaweedFS przed wersją 4.24 rejestruje usługę gRPC SeaweedIdentityAccessManagement bez obowiązkowego uwierzytelnienia, gdy klucz jwt.filer_signing.key nie jest ustawiony. Pozwala to każdemu klientowi z dostępem do portu gRPC na tworzenie użytkowników i kluczy dostępu, co daje kontrolę administracyjną nad S3.

SeaweedFS przed wersją 4.30 zawiera podatność polegającą na nieprawidłowym czyszczeniu ścieżek w routerach S3 i Iceberg REST catalog. Atakujący może użyć sekwencji '..' w żądaniu, aby ominąć kontrolę dostępu i odczytać lub zapisać dane w dowolnym zasobniku (bucket).

SeaweedFS to rozproszony system przechowywania plików i blobów. Od wersji 4.0.388 do 4.41 wykres SFTP Helm osadzał niezaszyfrowany prywatny klucz hosta Ed25519 w pliku k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml jako stringData.seaweedfs_sftp_ssh_private_key. Wdrożenie standalone prezentowało ten klucz publiczny, gdy sftp.enabled i sftp.enableAuth były prawdziwe, nie dostarczono sftp.existingConfigSecret, wybrano ścieżkę sftp.sshPrivateKey, ważny Secret config-ssh pozwalał na start, a hostKeysFolder nie zapewniał późniejszego podpisywania Ed25519. Atakujący mogący przekierować lub przechwycić ruch klienta mógł podszyć się pod ten punkt końcowy SFTP dla klientów ufających opublikowanej tożsamości hosta, ujawniając poświadczenia hasła lub dane wysyłane do fałszywego punktu końcowego. Domyślne ścieżki all-in-one i nieuwierzytelnione standalone nie ładowały klucza. Problem naprawiono w wersji 4.41.

SeaweedFS w wersjach przed 4.40 ma podatność, w której uwierzytelniony podmiot S3 z uprawnieniami ograniczonymi do zagnieżdżonego klucza obiektu może nadpisać inny obiekt poza tym zakresem, wywołując PutObjectAcl na kluczu, do którego ma dostęp. Obsługa autoryzuje żądanie względem żądanego klucza, ale zapisuje zaktualizowany wpis do katalogu głównego zasobnika, co prowadzi do nadpisania obiektu docelowego.

SeaweedFS w wersji 4.39 ma podatność w obsłudze TUS resumable-upload, gdzie sprawdzanie zakresu allowed_prefixes JWT odbywa się tylko przy tworzeniu sesji. To pozwala niskouprzywilejowanemu dzierżawcy przejąć sesję przesyłania innego dzierżawcy i zapisać treść w ścieżkach, których jego token nie powinien zezwalać. Podatność dotyczy tylko wdrożeń z włączonym podpisywaniem JWT filera i włączonymi przesyłaniami TUS.

SeaweedFS w wersjach od 3.88 do 4.39 ma podatność w serwerze SFTP, gdzie uprawnienia do ścieżek są sprawdzane przez porównanie prefiksu ciągu znaków, bez wymogu granicy komponentu ścieżki. Użytkownik z dostępem do /tenants/alice uzyskuje również dostęp do /tenants/alice-archive, /tenants/alice2 itp. Niskouprzywilejowany użytkownik SFTP może przekroczyć granice ACL i czytać lub nadpisywać pliki innych tenantów.

SeaweedFS w wersjach do 4.39 włącznie akceptuje zewnętrzny OIDC JWT w nagłówku Authorization i mapuje go na rolę IAM bez egzekwowania polityki zaufania roli. Użytkownik federacyjny może przyjąć rolę, do której nie ma uprawnień, uzyskując dostęp S3 do obiektów (odczyt, zapis, usuwanie) przez bezpośrednie przedstawienie tokena do API S3.

SeaweedFS przed wersją 4.24 używa strings.HasPrefix do sprawdzania autoryzacji, co pozwala tokenowi JWT ograniczonemu do /tenant1 na dostęp do ścieżek takich jak /tenant1234, /tenant1-old i /tenant1backup.