CVE-2026-113672

W Argo CD od wersji 2.1.0 do 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2, gdy operator włączył --enable-helm dla kustomize build, pole helmGlobals.configHome może wskazywać katalogi konfiguracji i danych Helm na lokalizację kontrolowaną przez repozytorium. Helm automatycznie ładuje wtyczkę downloadera z <configHome>/.data/plugins bez osobnego kroku instalacji i wykonuje jej program w argocd-repo-server, gdy URL repozytorium helmCharts używa protokołu wtyczki. Polecenie działa jako użytkownik repo-server i może odczytać poświadczenia repozytorium oraz inne dane dostępne dla procesu. Atakujący może zatwierdzić Kustomization i wtyczkę w repozytorium Git budowanym przez Application lub przesłać pliki przez POST /api/v1/applications/manifestsWithFiles, również udostępniane przez argocd app diff --local --server-side-generate. Ścieżka przesyłania wymaga jedynie uprawnienia Application get na istniejącym Application, bez uprawnień Application update lub sync ani dostępu do zapisu repozytorium. Obie ścieżki dostarczania wymagają wcześniejszego włączenia --enable-helm przez operatora; wdrożenia, które go nie włączają, nie są dotknięte. Kustomize 4.1.0 po raz pierwszy przekazało helmGlobals.configHome do Helm. Problem naprawiono w wersjach 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2.

W Argo CD od wersji 2.7.0 do 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2 Kustomize przekazuje wartości zapytań ref lub version z adresów URL zdalnych zasobów, baz lub komponentów do git fetch bez separatora końca opcji. Wartość rozpoczynająca się od myślnika może zostać zinterpretowana jako --upload-pack i wykonać polecenie w argocd-repo-server, gdy zdalne źródło używa transportu lokalnego, takiego jak file://. Git nie uruchamia dostarczonego polecenia dla zdalnego źródła https://. Transport lokalny nie opuszcza poda, więc blokowanie ruchu wychodzącego repo-server nie zapobiega wykonaniu. Polecenie działa jako użytkownik repo-server, może odczytać poświadczenia repozytorium i inne dane dostępne dla procesu oraz zwrócić dane wyjściowe przez błędy generowania manifestów. Atakujący może zatwierdzić Kustomization w repozytorium Git budowanym przez Application lub przesłać pliki przez POST /api/v1/applications/manifestsWithFiles, również udostępniane przez argocd app diff --local --server-side-generate. Ścieżka przesyłania wymaga jedynie uprawnienia Application get na istniejącym Application, bez uprawnień Application update lub sync ani dostępu do zapisu repozytorium. Kustomize 5.0.0 wprowadziło akceptację file://, podczas gdy 4.5.7 odrzuca ten transport; sama zamiana dotkniętego Kustomize na nowszą wersję nie naprawia brakującego separatora opcji. Problem naprawiono w wersjach 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2.

Argo CD od wersji 2.10.0 do 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2 tworzy hooki zasobów PostDelete bez stosowania kontroli autoryzacji AppProject dla miejsca docelowego i zasobów używanych podczas zwykłej synchronizacji. Użytkownik mogący zapisywać w repozytorium Git aplikacji może zatwierdzić hook usuwający skierowany do zabronionej przestrzeni nazw, serwera, grupy, rodzaju lub nazwy zasobu, a usunięcie aplikacji powoduje utworzenie tego zasobu z poświadczeniami klastra docelowego. Problem naprawiono w wersjach 3.3.15, 3.4.10, 3.5.4 i 3.6.0-rc2.

W Argo CD w wersjach od 3.2.0 do 3.2.10 oraz od 3.3.0 do 3.3.8 brakuje autoryzacji i maskowania danych w punkcie końcowym ServerSideDiff. Umożliwia to atakującemu z dostępem tylko do odczytu wyodrębnienie danych Secret w postaci jawnego tekstu z etcd za pomocą mechanizmu Server-Side Apply dry-run serwera API Kubernetes.

Argo CD w wersjach 2.9.0-rc1 do 2.14.19, 3.0.0-rc1 do 3.2.0-rc1, 3.1.6 i 3.0.17 ma podatność polegającą na tym, że gdy webhook.azuredevops.username i webhook.azuredevops.password nie są ustawione w domyślnej konfiguracji, endpoint /api/webhook powoduje awarię całego procesu argocd-server po otrzymaniu zdarzenia Azure DevOps Push, którego tablica JSON resource.refUpdates jest pusta. Dostęp do indeksu [0] bez sprawdzenia długości powoduje panikę index-out-of-range. Pojedynczy nieuwierzytelniony żądanie HTTP POST wystarczy, aby zabić proces. Problem rozwiązano w wersjach 2.14.20, 3.2.0-rc2, 3.1.8 i 3.0.19.

Argo CD w wersjach 2.13.0-2.13.8, 2.14.0-2.14.15, 3.0.0-3.0.12 i 3.1.0-rc1-3.1.1 pozwala tokenom API z uprawnieniami na poziomie projektu na pobranie poufnych danych uwierzytelniających repozytorium (nazwy użytkownika, hasła) poprzez punkt końcowy API szczegółów projektu. Podatność dotyczy również tokenów z globalnymi uprawnieniami do odczytu projektów. Naprawiono w wersjach 2.13.9, 2.14.16, 3.0.14 i 3.1.2.

Argo CD repo-server jest podatny na wstrzyknięcie poleceń podczas klonowania, testowania lub pobierania repozytorium Git SSH skonfigurowanego z adresem URL proxy. Host i port proxy są osadzane w SSH ProxyCommand wykonywanym przez powłokę bez neutralizacji znaków specjalnych. Użytkownik mogący tworzyć lub aktualizować repozytorium albo szablon poświadczeń repozytorium może wykonać polecenia w repo-server i uzyskać dostęp do jego poświadczeń Git, Helm i OCI.

W SessionManager w Argo CD w wersji 3.0.6 występuje podatność typu race condition. Pozwala ona atakującemu ominąć ograniczanie liczby prób i przeprowadzić atak brute force poprzez powtarzane, spreparowane żądania.

Podatność w Argo CD pozwala użytkownikom z dostępem do zapisu aplikacji na ustawienie adnotacji link.argocd.argoproj.io/* z wartościami rozdzielonymi pionową kreską, które są renderowane jako atrybuty href w sekcji URL w zakładce Podsumowanie bez walidacji, umożliwiając wykonanie kodu JavaScript w sesji uwierzytelnionego użytkownika o wyższych uprawnieniach. Problem został naprawiony w wersjach 3.2.12, 3.3.10 i 3.4.2.

Argo CD ServerSideDiff w wersjach od 3.2.0 do 3.2.12, 3.3.10 i 3.4.2 nieprawidłowo oczyszcza dane Secretów Kubernetes, co może ujawnić wrażliwe wartości, w tym dane z adnotacji kubectl.kubernetes.io/last-applied-configuration. Podatność pozwala na wyświetlenie tych danych w interfejsie użytkownika lub w różnicach CLI.