CVE-2025-5988

W bramie Ansible Automation Platform (AAP) wykryto obejście autoryzacji. Uwierzytelniony administrator może utworzyć nowy klucz usługi dla klastra usługi Controller, a ponieważ tworzenie klucza nie jest ograniczone do ścieżki instalatora, klucz ten jest kryptograficznie nieodróżnialny od prawdziwego i pozwala sfałszować token uwierzytelniania usługi podszywający się pod usługę Controller. W połączeniu z punktem końcowym OIDC workload-identity (włączanym przez FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED) atakujący może zmusić bramę do podpisania Workload Identity Tokens (WIT) dla dowolnych obciążeń Controller, a zaufany serwer zasobów (np. HashiCorp Vault) zaakceptuje sfałszowany WIT i zwróci poświadczenia AAP przypisane do tego obciążenia, ujawniając sekrety poza granicami autoryzacji atakującego.

Wada w automation-controller platformy Ansible Automation Platform: podczas kopiowania WorkflowJobTemplate walidator uprawnień deep-copy sprawdza tylko inventory, unified_job_template i credentials, ale nie sprawdza instance_groups (oraz execution_environment i labels) zachowanych z oryginału. Użytkownik z uprawnieniami workflow-admin w organizacji, ale bez roli na odwołanych instance groups, może skopiować workflow, zostać jego administratorem i uruchamiać zadania przypięte do nieautoryzowanych instance groups, w tym do grupy control-plane, omijając granicę InstanceGroup use_role i powodując uruchomienie automatyzacji w kontekście control-plane.

Wada w automation-controller platformy Red Hat Ansible Automation Platform: pole scm_url w Projekcie nie jest walidowane pod kątem wartości zaczynających się od myślnika i jest przechowywane oraz przekazywane dosłownie do modułu git SCM. Ponieważ moduł uruchamia git ls-remote z URL jako argumentem pozycyjnym i bez separatora "--", URL projektu git taki jak "--upload-pack=<command>:x" jest interpretowany przez git jako opcja --upload-pack i wykonywany przez powłokę. Użytkownik z uprawnieniami do tworzenia lub modyfikacji projektu w jednej organizacji może wykonać dowolne polecenia na podzie control-plane, a dane wyjściowe są odzwierciedlane przez endpoint stdout aktualizacji projektu, co prowadzi do kompromitacji między dzierżawcami i ruchu bocznego w klastrze.

Wada w automation-controller platformy Red Hat Ansible Automation Platform: sekret provisioning-callback (host_config_key) jest ujawniany użytkownikom posiadającym tylko uprawnienie odczytu view_jobtemplate — zarówno w reprezentacji API szablonu zadania, jak i w strumieniu aktywności — a endpoint provisioning callback ufa nagłówkowi X-Forwarded-For dostarczonemu przez klienta do określenia wywołującego hosta, gdy kontroler jest wdrożony za bramą AAP z pustą listą dozwolonych proxy. Poprzez odczytanie sekretu i sfałszowanie X-Forwarded-For, aby pasował do dowolnego hosta w inventory szablonu zadania, minimalnie uprzywilejowany lub nieuwierzytelniony zdalny atakujący może uruchomić szablon zadania przeciwko dowolnym zarządzanym hostom, używając poświadczeń szablonu zadania, co prowadzi do eskalacji uprawnień i zdalnego wykonania kodu na zarządzanych hostach.

W interfejsie Ansible Automation Platform (moduł Hub, plik DocumentationParsers.tsx) linki w dokumentacji kolekcji są renderowane bez ograniczenia protokołu URL. Kolekcja z linkiem używającym schematu wykonującego skrypty może spowodować uruchomienie skryptu w kontekście przeglądarki innego uwierzytelnionego użytkownika, który kliknie taki link — jest to stored XSS.

W Ansible Automation Platform (AWX) w API Bulk Job Launch (POST /api/v2/bulk/job_launch/) sprawdzane są tylko uprawnienia do odczytu dla instance_groups, podczas gdy standardowa ścieżka uruchamiania pojedynczego zadania wymaga uprawnień na poziomie 'use'. Osoba z uprawnieniami tylko do odczytu (np. rola System Auditor) oraz z uprawnieniami do wykonywania na szablonie zadania może uruchamiać zadania zbiorcze na grupach instancji, do których nie ma autoryzacji, omijając izolację rozmieszczenia.

W obrazach Ansible Automation Platform stwierdzono podatność na eskalację uprawnień w kontenerze. Plik /etc/passwd został utworzony z uprawnieniami zapisu dla grupy podczas budowania obrazu. Atakujący, który może wykonywać polecenia w kontenerze (nawet jako nie-root), może wykorzystać członkostwo w grupie root do modyfikacji /etc/passwd i dodać użytkownika z dowolnym UID, w tym 0, uzyskując pełne uprawnienia root w kontenerze.