CVE-2026-55797

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.

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.

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.

W Argo CD, silniku GitOps używanym przez Red Hat OpenShift GitOps, wykryto lukę umożliwiającą nieuwierzytelnionemu atakującemu z dostępem sieciowym do serwera repozytorium Argo CD zdalne wykonanie kodu. W pewnych warunkach atakujący może manipulować danymi w pamięci podręcznej, aby wdrożyć złośliwe zasoby Kubernetes do zarządzanych klastrów, co może prowadzić do całkowitego przejęcia klastra.

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.

Argo CD, narzędzie do ciągłego dostarczania w modelu GitOps dla Kubernetes, ma błąd w wersjach od 2.6.0, który powoduje, że otwarte sesje terminala webowego nie wygasają. Umożliwia to użytkownikom wysyłanie wiadomości websocket, nawet gdy token już wygasł.