CVE-2026-88015

W rclone przed wersją 1.75.1 rdzeń nie odrzuca segmentów katalogu nadrzędnego w wartościach Object.Remote() przed przekazaniem ich do backendów docelowych przez fs/list, fs/walk, fs/sync i fs/operations. Magazyn obiektów z płaską przestrzenią kluczy może zawierać surowy segment "..", a dotknięte backendy używają path.Join(root, remote) przed neutralizacją tego segmentu, co pozwala kopiowaniu lub wysyłaniu opuścić skonfigurowany katalog główny. Luka została naprawiona w wersji 1.75.1.

rclone w wersjach od 1.75.0 do 1.75.1 w ścieżce strumieniowego multipart serwera S3 przekazuje kontrolowany przez atakującego contentLength do multipart.NewRW().Reserve przed odczytaniem treści żądania. Klient sieciowy może wielokrotnie rezerwować pamięć bez wysyłania zadeklarowanego ciała, wyczerpując pamięć procesu lub hosta albo trwale blokując obsługę żądań. Problem naprawiono w wersji 1.75.1.

W rclone od wersji 1.64.0 do 1.75.1 sterownik FTP auth-proxy przechowuje jedno zaciemnione hasło na nazwę użytkownika w globalnej mapie userPass, zamiast wiązać poświadczenia z sesją. Jeśli dwie zaakceptowane poświadczenia mają tę samą nazwę użytkownika, ale różne backendy proxy, późniejsze logowanie nadpisuje hasło i pierwsza sesja jest ponownie autoryzowana z uprawnieniami drugiego backendu, co pozwala na nieautoryzowany dostęp do operacji na plikach.

W rclone przed wersją 1.75.1, gdy backend lokalny działa z opcją --links, źródłowy obiekt .rclonelink może utworzyć dowiązanie symboliczne w miejscu docelowym, a następnie metadane katalogu są stosowane przez tę ścieżkę. Funkcje MkdirMetadata, writeMetadataToFile i setTimes mogą ominąć ograniczenia os.Root i podążyć za dowiązaniem, co pozwala atakującemu kontrolującemu źródło na zastosowanie wybranego właściciela, uprawnień, czasów modyfikacji lub utworzenia do pliku lub katalogu poza miejscem docelowym.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. Od wersji 1.72.0 do 1.75.1 metoda backendu archiwum ZIP (*Fs).readZip w backend/archive/zip/zip.go przyjmuje wartości archive/zip.File.Name z niezaufanego katalogu centralnego i ujawnia oczyszczone nazwy wpisów bez zapewnienia, że pozostają w przestrzeni nazw archiwum. Wpisy takie jak ../../etc/cron.d/evil mogą przetrwać path.Clean i stać się wartościami Object.Remote(), których fs/sync i fs/operations używają jako ścieżek względnych miejsca docelowego, pozwalając rclone copy lub sync zapisywać poza wybranym miejscem docelowym w backendach, które niezależnie nie ograniczają ścieżki. Sprawdzenie niepustego katalogu głównego używało również strings.HasPrefix bez granicy ścieżki, więc katalog główny foo mógł niepoprawnie obejmować wpisy sąsiadujące foobar. Problem naprawiono w wersji 1.75.1.

W rclone od wersji 1.49.0 do 1.75.1 backend HTTP dołącza nagłówki skonfigurowane przez --http-headers lub headers= do żądań, a klient fshttp.NewClient podąża za przekierowaniami bez polityki CheckRedirect. Skonfigurowany remote, który przekierowuje do innego hosta, może spowodować ponowne wysłanie niestandardowych sekretów, takich jak X-Api-Key, do niezaufanego celu, a przekierowanie HTTPS-to-HTTP w tym samym hoście może ujawnić nagłówki Authorization lub Cookie w postaci jawnej. Operacje listowania, stat, pobierania, montowania i serwowania mogą wywołać wyciek podczas normalnego użytkowania. Podatność naprawiono w wersji 1.75.1.

rclone przed wersją 1.74.4 nie maskuje specjalnych bitów uprawnień podczas stosowania metadanych trybu pochodzących ze źródła w lokalnym backendzie. Atakujący mogą ustawić bity setuid/setgid na kontrolowanych plikach, co przy kopiowaniu z niezaufanego zdalnego źródła z zachowaniem metadanych może prowadzić do eskalacji uprawnień do roota, jeśli rclone działa jako root.

W rclone przed wersją v1.75.0 nie są odpowiednio oczyszczane tokeny IBM IAM oraz klucze szyfrowania SSE-C podczas wywołań zwrotnych przekierowań S3, co pozwala na zachowanie poświadczeń przy zmianie schematu lub hosta. Atakujący obserwujący ruch sieciowy z zaufanego punktu końcowego może przechwycić wielokrotnego użytku tokeny IBM IAM podczas degradacji HTTPS do HTTP na tym samym hoście lub klucze SSE-C podczas przekierowań między domenami, aby uzyskać dostęp do chronionych obiektów S3.

W rclone przed wersją v1.75.0 występuje podatność na atak DoS w obsłudze tworzenia WebDAV TUS, która wyłuskuje nil response przed sprawdzeniem błędów transportu. Złośliwy lub skompromitowany skonfigurowany punkt końcowy może resetować połączenia podczas przesyłania TUS, aby wywołać panic, który kończy nieodzyskane gorutyny i zatrzymuje niezwiązane prace w długo działających procesach.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. Od wersji 1.70.0 do 1.75.1 interfejs serve/start RC akceptuje ustawienia proxyOpt.AuthProxy dla poszczególnych serwerów, ale konstruktory FTP i S3 w cmd/serve/ftp/ftp.go oraz cmd/serve/s3/server.go nieprawidłowo sprawdzają globalną wartość proxy.Opt.AuthProxy. Gdy wartość globalna jest pusta, lokalny dla żądania proxy uwierzytelniające jest ignorowane: FTP przechodzi do stałego systemu plików z użytkownikiem anonymous i dowolnym hasłem, a S3 z AuthKey udostępnia stały system plików RC zamiast backendu wybranego przez proxy. Dedykowane serwery wiersza poleceń konfigurujące opcję globalną nie są dotknięte. Problem naprawiono w wersji 1.75.1.