CVE-2026-49980

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.

rclone to program wiersza poleceń do synchronizacji plików i katalogów z różnymi dostawcami chmury. Przed wersją 1.75.1 rclone serve s3 skonfigurowany z --auth-proxy, ale bez --auth-key, pozwala authPairMiddleware zarejestrować dowolny wybrany przez klienta accessKeyID z pustym ws.s3Secret. gofakes3 następnie weryfikuje sygnaturę SigV4 żądania względem tego samego pustego sekretu, podczas gdy Server.auth przekazuje identyfikator klucza dostępu jako zarówno użytkownika, jak i wartość uwierzytelniającą do proxy bez niezależnego sekretu dla tożsamości. Nieuwierzytelniony atakujący sieciowy może zatem wybrać dowolny klucz dostępu, podpisać pustym sekretem i dotrzeć do dowolnego backendu, który skrypt auth-proxy rozwiąże dla tej tożsamości. Problem naprawiono w wersji 1.75.1.

W Rclone od wersji 1.48.0 do 1.73.4 punkt końcowy RC `operations/fsinfo` jest dostępny bez wymaganego uwierzytelnienia i akceptuje kontrolowane przez atakującego dane wejściowe `fs`. Nieuwierzytelniony atakujący może wykorzystać tę podatność do wykonania dowolnego polecenia lokalnego na serwerze poprzez backend WebDAV, który uruchamia `bearer_token_command` podczas inicjalizacji.

W Rclone, punkcie końcowym RC `options/set`, brakuje wymaganego uwierzytelnienia (`AuthRequired: true`), co pozwala na modyfikację globalnej konfiguracji środowiska wykonawczego. Nieuwierzytelniony atakujący może ustawić `rc.NoAuth=true`, wyłączając w ten sposób bramę autoryzacji dla wielu metod RC, które normalnie wymagają uwierzytelnienia, co prowadzi do nieautoryzowanego dostępu do wrażliwych funkcji administracyjnych.

rclone w wersjach od 1.56.0 do 1.75.0 zawiera podatność path traversal w wtyczce wolumenów `rclone serve docker`. Funkcja newVolume() w cmd/serve/docker/volume.go oblicza punkt montowania jako filepath.Join(drv.root, name) na podstawie pola `name` z żądania Docker VolumeDriver.Create, nie sprawdzając, czy wynik pozostaje w drv.root (domyślnie /var/lib/docker-volumes/rclone), a następnie checkMountpoint() tworzy ten katalog przez file.MkdirAll przed montowaniem. Nazwa wolumenu zawierająca odpowiednio dużo komponentów `..` (np. "../../../../../../etc") pozwala wyjść poza katalog bazowy, umożliwiając osobie mogącej wysłać żądanie VolumeDriver.Create do gniazda wtyczki utworzenie katalogu i zamontowanie zdalnego systemu plików w dowolnej ścieżce hosta. Volume.restoreState() miało tę samą lukę przy wczytywaniu zapisanego stanu wolumenów. Naprawiono w 1.75.1.

rclone w wersjach przed 1.75.1 nie ogranicza nazw z odpowiedzi serwera i zewnętrznych listingów do listowanego katalogu, co pozwala na sekwencje path traversal w nazwach obiektów. Atakujący może tworzyć specjalne nazwy zawierające ukośniki i odwołania do katalogu nadrzędnego, aby potencjalnie zapisywać poza katalogiem docelowym, choć obecne zabezpieczenia w backendzie lokalnym blokują faktyczne wyjście poza pliki.

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.