CVE-2026-104615

Kontroler SUSE Rancher Fleet nie ograniczał wystarczająco, które sekrety kubeconfig może przywoływać obiekt Fleet Cluster. W efekcie zwykły użytkownik mógł zdefiniować klaster w swojej przestrzeni nazw i powiązać go z poświadczeniami administracyjnymi klastra zarządzającego, co pozwalało kontrolerowi zarządzać klastrem zarządzającym w imieniu tego użytkownika z podwyższonymi uprawnieniami. Podatność dotyczy wersji 0.16.0–0.16.3, 0.15.0–0.15.8, 0.14.0–0.14.12, 0.13.0–0.13.17 i prawdopodobnie starszych.

Brak walidacji referencji 'valuesFrom' w Helm Deployer SUSE Rancher Fleet umożliwia właścicielom jednego dzierżawcy dostęp do poświadczeń fleet innych dzierżawców. Podatność dotyczy wersji 0.15 przed 0.15.2, 0.14 przed 0.14.6, 0.13 przed 0.13.11 oraz 0.12 przed 0.12.15.

W Rancher Manager zidentyfikowano podatność, w której agent Fleet zapisywał zasoby do klastrów podrzędnych, używając własnych poświadczeń cluster-admin zamiast ServiceAccount przypiętego do wdrożenia. Dotyczy to środowisk wielodostępnych, gdzie różni dzierżawcy współdzielą te same klastry podrzędne, co może prowadzić do nadpisania plików konfiguracyjnych. Problem dotyczy SUSE Rancher Fleet 0.16 przed 0.16.2, 0.15 przed 0.15.7 i 0.14 przed 0.14.11.

Wykryto niezgodność uprawnień w Fleet. Gdy pakiet żąda etykiet lub adnotacji przestrzeni nazw przez opcje namespaceLabels i namespaceAnnotations, aktualizacja metadanych przestrzeni nazw nie podlegała tej samej autoryzacji co reszta wdrożenia pakietu. W rezultacie pakiet mógł zmieniać etykiety i adnotacje w docelowej przestrzeni nazw, nawet jeśli tożsamość, do której był przypięty, nie była autoryzowana do modyfikacji tej przestrzeni.

Wykryto podatność w odbiorniku webhook Git we Fleet (usługa gitjob webhook). Gdy sekret webhook nie jest skonfigurowany, przychodzące żądania webhook są akceptowane bez weryfikacji, a przetworzenie żądania może zmienić pole spec.pollingInterval pasującego zasobu GitRepo w dowolnej przestrzeni nazw. Osoba z dostępem sieciowym do usługi webhook i bez poświadczeń Kubernetes może zmienić konfigurację GitRepo poza przestrzeniami nazw, do których jest autoryzowana.

W SUSE Rancher Fleet odkryto problem autoryzacji między dzierżawcami. Podczas rejestracji klastra inicjowanej przez agenta, etykiety klastra dostarczone przez rejestrującego agenta, w tym etykiety z zastrzeżonej przestrzeni nazw management.cattle.io/, takie jak etykieta nazwy wyświetlanej klastra, były stosowane do wynikowego obiektu Cluster. Ponieważ Fleet rozwiązuje cele GitRepo i Bundle na podstawie tych etykiet, strona mogąca zarejestrować klaster w współdzielonej przestrzeni nazw Fleet workspace może spowodować, że jej klaster spełni reguły targetowania przeznaczone dla innego klastra. Problem dotyczy SUSE Rancher Fleet 0.16 przed 0.16.1, 0.15 przed 0.15.6, 0.14 przed 0.14.10, 0.13 przed 0.13.15, 0.12 przed 0.12.19 i starszych.

Użytkownik, który może dostarczać zawartość pakietu do repozytorium wskazywanego przez zasób GitRepo, na przykład przez dostęp do wypychania zmian w Git lub uprawnienia do tworzenia/modyfikowania GitRepo, może spowodować, że SUSE Rancher Fleet odczyta pliki z systemu plików środowiska przetwarzającego pakiet i dołączy ich zawartość do wygenerowanego zasobu Bundle. Może to ujawnić dane konfiguracyjne lub poświadczenia, do których użytkownik nie ma uprawnień RBAC Kubernetes, w tym poświadczenia rejestru Helm udostępnione zadaniu przetwarzania pakietów, gdy skonfigurowano poświadczenia Helm dla ścieżek.

Podatność w SUSE Rancher Fleet umożliwia fałszowanie nieuwierzytelnionych żądań webhook, co może być wykorzystane przez zdalnego atakującego do przeprowadzenia ataku typu odmowa usługi (DoS) lub ataku polegającego na obniżeniu wersji (downgrade) na innych repozytoriach w systemie. Problem dotyczy wersji 0.15 przed 0.15.2, 0.14 przed 0.14.6, 0.13 przed 0.13.11 oraz 0.12 przed 0.12.5.

W SUSE Rancher Fleet w wersjach 0.15 przed 0.15.2, 0.14 przed 0.14.6, 0.13 przed 0.13.11 i 0.12 przed 0.12.15 brak filtrowania w czytniku pakietów (bundle reader) powoduje, że gdy pole helmRepoURLRegex nie jest ustawione w zasobie GitRepo, poświadczenia uwierzytelniania Helm (BasicAuth) są przekazywane do dowolnego adresu URL określonego w polu helm.repo pliku fleet.yaml. Umożliwia to atakującym mającym dostęp do repozytoriów git monitorowanych przez Fleet przechwycenie poświadczeń dostępu do Helm.