Podatności Argo Workflows

Podatność w Argo Workflows przed wersjami 3.7.15 i 4.0.6 umożliwia ominięcie mechanizmu allow-list dla CVE-2026-31892. Poprzez pole ArtifactGC w WorkflowSpec użytkownik może wstrzyknąć dowolną łatkę strategicznego scalania do podu artifact-GC, w tym niebezpieczne ustawienia jak hostPath, uprzywilejowany tryb czy hostNetwork.

Argo Workflows przed wersjami 4.0.2 i 3.7.11 zawiera podatność, która umożliwia nieautoryzowanym klientom pobieranie szablonów przepływów pracy (WorkflowTemplates i ClusterWorkflowTemplates) poprzez wysłanie żądania z dowolnym tokenem w nagłówku Authorization. Może to prowadzić do ujawnienia poufnych danych, w tym osadzonych manifestów Secret.

Argo Workflows w wersjach od 4.1.0 do 4.1.3 zawiera podatność polegającą na obejściu autoryzacji w funkcji ListArchivedWorkflows, która nie stosuje przeglądu dostępu na poziomie klastra, gdy selektor pola metadata.namespace używa operatora NotEquals. Atakujący z uprawnieniami do listowania w zakresie przestrzeni nazw mogą użyć zanegowanego selektora pola przestrzeni nazw, aby uzyskać dostęp do zarchiwizowanych przepływów pracy ze wszystkich innych przestrzeni nazw, ujawniając argumenty specyfikacji, wartości parametrów i adnotacje.

Argo Workflows w wersjach od 4.0.0 do przed 4.0.5 zawiera podatność w Sync Service, gdzie dostawca oparty na ConfigMap (server/sync/sync_cm.go) nie przeprowadza żadnych kontroli autoryzacji dla operacji CRUD. Każdy uwierzytelniony użytkownik, w tym używający fałszywych tokenów Bearer, może tworzyć, odczytywać, aktualizować i usuwać ConfigMapy Kubernetes zawierające limity synchronizacji.

Argo Workflows przed wersjami 3.7.14 i 4.0.5 umożliwia użytkownikowi z uprawnieniami do tworzenia Workflow ominięcie trybu Strict templateReferencing. Pozwala to na uzyskanie dostępu do sieci hosta, zmianę konta serwisowego, nadpisanie kontekstu bezpieczeństwa poda, dodanie toleracji do planowania na węzłach kontrolnych lub włączenie montowania tokena SA.

Argo Workflows w wersjach od 4.0.0 do przed 4.0.5 rejestruje w postaci jawnego tekstu wszystkie poświadczenia repozytoriów artefaktów (klucze dostępu S3, klucze tajne, klucze konta usługi GCS, klucze konta Azure, hasła Git itp.) podczas operacji na artefaktach. Każdy użytkownik mający dostęp do odczytu logów podów workflow może wyodrębnić te poświadczenia. Problem został naprawiony w wersji 4.0.5.

Argo Workflows przed wersjami 3.7.14 i 4.0.5 ładuje całe ciało żądania do pamięci przed uwierzytelnieniem lub weryfikacją podpisu na publicznie dostępnym endpointcie /api/v1/events/. Atakujący może wysłać bardzo duże żądanie, powodując nadmierne zużycie pamięci i awarię OOM.

Argo Workflows w wersjach od 4.0.0 do 4.0.5 ma podatność na dereferencję wskaźnika null w funkcji rbacAuthorization() w pliku server/auth/gatekeeper.go. Powoduje to panikę (odmowę usługi) dla użytkowników SSO, których dane pasują do reguły RBAC na poziomie przestrzeni nazw, ale nie do reguły SSO-namespace, gdy włączona jest opcja SSO_DELEGATE_RBAC_TO_NAMESPACE=true.

Podatność w Argo Workflows od wersji 3.6.5 do 4.0.4 powoduje panikę kontrolera z powodu niesprawdzonego indeksu tablicy w funkcji podGCFromPod() informera podów. Złośliwa adnotacja workflows.argoproj.io/pod-gc-strategy w zasobniku workflow prowadzi do awarii całego procesu kontrolera, a po restarcie podtrzymuje pętlę awarii, blokując przetwarzanie wszystkich workflowów.

Podatność w Argo Workflows pozwala użytkownikowi z uprawnieniami do przesyłania zadań (Workflows) na całkowite ominięcie zabezpieczeń zdefiniowanych w szablonie WorkflowTemplate. Poprzez dodanie pola podSpecPatch w przesyłanym zadaniu, użytkownik może nadpisać ustawienia szablonu, nawet gdy kontroler jest skonfigurowany w trybie ścisłego odwoływania (templateReferencing: Strict).

Podatność XSS w Argo Workflows umożliwia wykonanie dowolnego kodu JavaScript w przeglądarce innego użytkownika poprzez listowanie katalogów artefaktów. Problem występuje przed wersjami 3.6.17 i 3.7.8.