CVE-2026-15416

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.

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 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.

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.

Podatność w Argo CD w wersjach 3.2.0 do 3.2.10 oraz 3.3.0 do 3.3.8 umożliwia odczytanie danych tajnych Kubernetes w postaci jawnego tekstu za pomocą funkcji ServerSideDiff.

Argo CD w wersjach 1.2.0 do 1.8.7, 2.0.0-rc1 do 2.14.19, 3.0.0-rc1 do 3.2.0-rc1, 3.1.7 i 3.0.18 jest podatny na złośliwe żądania API, które mogą spowodować awarię serwera API i odmowę usługi dla legalnych klientów. Przy domyślnej konfiguracji, bez ustawionego webhook.gogs.secret, punkt końcowy /api/webhook w Argo CD ulega awarii całego procesu argocd-server, gdy otrzyma zdarzenie push z Gogs, w którym pole JSON commits[].repo nie jest ustawione lub jest null. Problem został naprawiony w wersjach 2.14.20, 3.2.0-rc2, 3.1.8 i 3.0.19.

Argo CD w wersjach 1.2.0 do 1.8.7, 2.0.0-rc1 do 2.14.19, 3.0.0-rc1 do 3.2.0-rc1, 3.1.7 i 3.0.18 jest podatny na złośliwe żądania API, które mogą spowodować awarię serwera API i odmowę usługi. Bez skonfigurowanego webhook.bitbucketserver.secret, punkt końcowy /api/webhook w Argo CD ulega awarii przy otrzymaniu nieprawidłowego ładunku z Bitbucket Server (nie-tablicowe pole repository.links.clone). Pojedyncze nieuwierzytelnione żądanie wyzwala CrashLoopBackOff, a zaatakowanie wszystkich replik powoduje całkowitą awarię API. Problem został naprawiony w wersjach 2.14.20, 3.2.0-rc2, 3.1.8 i 3.0.19.