CVE-2026-77633

Cloudreve przed wersją 4.16.1 nieprawidłowo sanityzuje ścieżki plików zwracane przez zdalne downloadery, co pozwala uwierzytelnionym użytkownikom tworzyć pliki poza wybranym katalogiem docelowym. Atakujący mogą wykorzystać sekwencje path traversal w metadanych downloadera do zapisu plików w nieoczekiwanych lokalizacjach.

Cloudreve przed wersją 4.16.1 nie ponownie weryfikuje dostępu do udostępnionych zasobów podczas przywracania zapisanego stanu nawigacji z UUID context_hint. Atakujący, którzy wcześniej mieli ważny dostęp do udostępnienia, mogą odtworzyć zapisany hint i generować podpisane adresy URL plików przez maksymalnie 300 sekund po usunięciu udostępnienia, wygaśnięciu lub osiągnięciu limitu pobrań.

Cloudreve przed wersją 4.17.0 rejestruje punkty testowe węzłów administracyjnych (POST /api/v4/admin/node/test i POST /api/v4/admin/node/test/downloader) bez wymagania zakresu OAuth Admin.Write, w przeciwieństwie do tras tworzenia/aktualizacji/usuwania węzłów. Klient OAuth autoryzowany przez administratora tylko z zakresem Admin.Read może przesyłać definicje węzłów kontrolowane przez atakującego i powodować wysyłanie przez serwer Cloudreve żądań wychodzących do dowolnych adresów URL, umożliwiając ślepe SSRF, sondowanie wewnętrznych usług i dostarczanie podpisanych żądań typu slave do wybranych przez atakującego punktów końcowych.

W Cloudreve przed wersją 4.18.0 zabezpieczenie przed server-side request forgery (SSRF) ValidateExternalURL w pkg/request/ssrf.go przekazuje rozwiązane adresy do checkIP bez dekodowania form przejściowych IPv4-w-IPv6 NAT64, IPv4-compatible i 6to4. Uwierzytelniony użytkownik z dostępem do zdalnego pobierania może podać SrcUri poprzez RemoteDownloadTask.createDownloadTask, aby wrapper osadzający adres IPv4 loopback, prywatny, link-local lub cloud metadata został sklasyfikowany jako publiczny i pobrany, ujawniając odpowiedzi wewnętrznych usług i poświadczenia instancji chmury. Adresy IPv4-mapped IPv6 pozostają zablokowane, ponieważ Go konwertuje tę formę za pomocą net.IP.To4.

Cloudreve przed wersją 4.18.0 ma brak middleware RequiredScopes(types.ScopeAdminWrite) na trasach narzędzi administracyjnych tool.GET("wopi") i tool.POST("mail"), które dziedziczą ScopeAdminRead. Aplikacja OAuth lub klucz API z uprawnieniami Admin.Read może sondować skonfigurowane usługi WOPI i wysyłać dowolne testowe e-maile przez konfigurację SMTP, przekraczając granice uprawnień tylko do odczytu.

W Cloudreve przed wersją 4.17.0, walidacja sesji WOPI używa tylko prefiksu session-id tokena dostępu i nie wymusza żądanej akcji, co pozwala złośliwemu przeglądającemu na sfałszowanie sufiksu tokena i wywołanie zapisu pliku.

Podatność w Cloudreve przed wersją 4.17.0, gdzie endpoint POST /api/v4/admin/policy/oauth/signin wymaga tylko uprawnienia Admin.Read, ale umożliwia modyfikację poświadczeń polityki przechowywania OneDrive bez uprawnienia Admin.Write, co pozwala na zmianę sekretu i app_id.

W Cloudreve przed wersją 4.17.0, subskrypcja zdarzeń dla pojedynczego udostępnionego pliku rozpoznaje katalog nadrzędny właściciela i subskrybuje go, co pozwala uwierzytelnionemu odbiorcy na otrzymywanie informacji o nieudostępnionych plikach i folderach.

Cloudreve przed wersją 4.17.0 zawiera podatność w dekoderach miniatur i awatarów, które ograniczają rozmiar skompresowanego pliku, ale nie ograniczają wymiarów pikseli po dekompresji. Uwierzytelniony użytkownik może przesłać mały plik PNG, JPEG lub GIF, który powoduje nieograniczoną alokację pamięci i zatrzymanie procesu Cloudreve z powodu krytycznego błędu braku pamięci.

Cloudreve przed wersją 4.17.0 zawiera podatność w punkcie końcowym GET /api/v4/user/search, który wywołuje SearchActive bez dodawania predykatu StatusActive i serializuje wyniki na poziomie RedactLevelUser. Pozwala to każdemu zalogowanemu użytkownikowi na wyliczenie adresów e-mail i metadanych profili dla nieaktywnych lub zablokowanych kont.