CVE-2026-71458

W CopyAPIView (awx/awx/api/generics.py:873) ustawiono permission_classes = (IsAuthenticated,), więc get_object() DRF nie wykonuje kontroli RBAC na poziomie obiektu. Handler get() jawnie sprawdza request.user.can_access(obj._class_, 'read', obj), ale post() tego nie robi — sprawdza jedynie can_access(model, 'add', create_kwargs_check) oraz can_access(model, 'copy_related', obj). Dla JobTemplate uprawnienia can_add i can_copy_related nie implikują prawa odczytu źródłowego szablonu zadania.

LaunchConfigurationBaseSerializer.scm_branch nie ma walidacji validate_scm_branch() sprawdzającej wiodący myślnik, w przeciwieństwie do serializatorów Project/JobTemplate/JobLaunch. Schedule i WFJT Node akceptują --upload-pack=/bin/id jako scm_branch. Obecnie blokowane w czasie działania przez sprawdzenie ValueError w jobs.py:1502 (obrona w głąb), ale luka w walidacji API oznacza poleganie wyłącznie na zabezpieczeniu warstwy zadań. Usunięcie tego zabezpieczenia podczas refaktoryzacji przekształciłoby to w RCE.

Biała lista AST Jinja szablonów powiadomień sprawdza tylko statyczne węzły Getattr. Dynamiczne indeksy (job['job'+'_env']) i warunkowe bramkowanie {% if job.id > 100 %} omijają zarówno sprawdzenie AST, jak i test-render (stub ma mały job.id). W czasie działania bramkowana gałąź wykonuje się, a wyjątki zapisują pełne ślady stosu do treści powiadomienia, które jest wysyłane POSTem do kontrolowanego przez atakującego URL webhooka. Ujawnia ścieżki instalacji, wersję Pythona, numery linii źródłowych.

Metoda StringListPathField.to_internal_value() wywołuje os.path.exists() na nieograniczonych ścieżkach podanych przez użytkownika. Różnica w odpowiedziach 200 vs 400 ujawnia istnienie dowolnych ścieżek bezwzględnych w podzie controller-web, w tym plików wrażliwych jak SECRET_KEY czy tokeny konta serwisowego.

Metoda HostList.list() łapie wyjątek Exception i zwraca str(e) bezpośrednio. Poprzez host_filter, każdy uwierzytelniony użytkownik może wywołać Django FieldError (ujawniający pełny graf relacji modelu Host) lub PostgreSQL DataError (ujawniający surowe błędy bazy danych).

Endpoint /api/v2/config/ jest chroniony tylko przez IsAuthenticated, co oznacza, że każdy uwierzytelniony użytkownik otrzymuje license_info, w tym numery kont, ID subskrypcji, pool_id, SKU, poziom wsparcia i liczbę instancji. Brama superuser/auditor obejmuje tylko inne pola, nie license_info.

Widok JobJobEventsChildrenSummary nie ma modelu ani parent_model, co powoduje, że ModelAccessPermission.check_get_permissions() zwraca True dla każdego uwierzytelnionego użytkownika. Widok używa surowego get_object_or_404(Job, pk) bez sprawdzenia uprawnień na poziomie obiektu DRF, co pozwala użytkownikowi bez uprawnień odczytywać strukturę drzewa zdarzeń i enumerować ID zadań.

Wada w AWX: pole pod_spec_override w grupie kontenerów używa niekompletnej listy blokującej, która ogranicza tylko automountServiceAccountToken, umożliwiając wstrzyknięcie initContainers, nadpisań serviceAccountName i projected service account token volumes. Administrator platformy AAP może to wykorzystać do eskalacji uprawnień do dostępu na poziomie przestrzeni nazw OpenShift i eksfiltracji sekretów przestrzeni nazw.

Znaleziono podatność typu Server-Side Request Forgery (SSRF) w wielu backendach powiadomień AWX. Backendy webhook, Mattermost, Rocket.Chat i Grafana używają adresów URL z szablonów powiadomień jako bezpośrednich celów żądań HTTP bez walidacji adresu docelowego pod kątem prywatnych, pętli zwrotnej lub zastrzeżonych zakresów IP. Administrator powiadomień organizacji może tworzyć szablony powiadomień wskazujące na wewnętrzne adresy lub adresy pętli zwrotnej, powodując, że węzeł kontrolny AWX wysyła żądania HTTP do usług, które nie są dostępne z zewnątrz. Dodatkowo backend webhook podąża za przekierowaniami HTTP i ponownie wysyła skonfigurowane poświadczenia Basic Authentication do celów przekierowania niezależnie od zmiany hosta, co pozwala atakującemu na eksfiltrację poświadczeń powiadomień poprzez przekierowanie na kontrolowany przez atakującego host. Backend Grafana wysyła swój klucz API w nagłówku Authorization do skonfigurowanego docelowego adresu URL.

Znaleziono podatność typu path traversal w ekstrakcji archiwów projektów w AWX. Wtyczka akcji project_archive rozpakowuje elementy archiwów zip i tar, łącząc ścieżkę katalogu projektu z nazwą pliku elementu bez normalizacji ścieżki, walidacji granic lub odrzucania sekwencji traversal. Złośliwe archiwum zawierające elementy z sekwencjami traversal może zapisywać pliki w dowolnych lokalizacjach w systemie plików węzła wykonawczego poza zamierzonym katalogiem projektu. Atakujący, który kontroluje zawartość archiwum, czy to poprzez skompromitowane źródło nadrzędne, złośliwy adres URL archiwum, czy atak man-in-the-middle na zwykłym połączeniu HTTP, może osiągnąć dowolny zapis plików jako użytkownik wykonujący ekstrakcję, potencjalnie prowadząc do zdalnego wykonania kodu poprzez mechanizmy takie jak pliki cron, klucze autoryzowane SSH lub wstrzyknięcie treści playbooka.