AWX: dwa różne SSRF-y wyprowadzają dwa różne sekrety — Git PAT przez forged webhook callback i Basic Auth/API key przez notification redirects

Red Hat opublikował dwa osobne CVE dotyczące SSRF w AWX / Automation Controller: CVE-2026-71365 (webhook status callback SSRF) i CVE-2026-71366 (notification backend SSRF). Oba to outbound HTTP request z control node, oba mogą wyciekać sekret. Łatwo uznać „to ten sam finding, zdeduplikujmy” — a Red Hat wprost śledzi je osobno, bo dotyczą innej ścieżki kodu, wymagają innych uprawnień i ujawniają inne credentials.

CVE-2026-71365: admin webhook-enabled job template odczytuje signing key, tworzy forged webhook z attacker-controlled statuses_url → AWX wysyła status callback z Git PAT na kontrolowany host.

CVE-2026-71366: notification admin ustawia URL (loopback/RFC1918/link-local) → SSRF; redirect resenduje Basic Auth po zmianie hosta, backend Grafana wysyła API key.

SSRF jako credential decryption oracle

Git PAT jest przechowywany szyfrowany i normalnie nie jest odczytywalny przez API. Template admin ma uprawnienia operacyjne do szablonu, ale nie powinien dostać plaintext Git credential. SSRF zamienia to w oracle: nie mogę odczytać sekretu, ale mogę zmusić zaufaną usługę, by wysłała go tam, gdzie chcę. To privilege boundary violation, nie zwykły „authenticated” finding.

Dlaczego to nie jest jedno CVE

CVE-71365 CVE-71366 entry webhook status callback notification templates rola job template admin notification admin input statuses_url notification URL / redirect sekret Git PAT Basic Auth / Grafana API key trigger status update notification send

Root property jest wspólna („untrusted actor nie decyduje, dokąd trusted control node wysyła authenticated request”), ale remediation, detection i testy są różne. Właściwy model to parent problem („AWX outbound-request trust boundary”) z dwoma child findings.

Egress filtering — dobry control, ale nie banalny

Blokada RFC1918 + localhost + 169.254.169.254 redukuje SSRF do internal, ale nie zatrzymuje AWX → attacker.com + Authorization: Git PAT, jeśli statuses_url może wskazać publiczny host. Control musi zależeć od attack path: dla webhook — host allowlist == expected Git provider; dla notification — allowed destinations == approved integrations. I redirect safety: walidacja na każdym hopie, credentials stripped na cross-origin redirect.

Brak pełnej mitygacji; patch ≠ rotacja

Red Hat: brak kompletnej mitygacji poza update (na moment publikacji nie wymyślaj fixed version; są controls redukujące ryzyko — role restriction, egress, monitoring, least-privilege, review templates). A jeśli sekret mógł wyciec: rotate it — patch nie unieważnia skradzionego PAT/API key. Pełna remediacja po evidence: patch + credential rotation + log review + downstream access review.

Wniosek

Na powierzchni: „AWX + SSRF + credential leak”. Pod spodem: inne role, endpointy, sekrety, triggery i testy. Dojrzały VE widzi wspólną klasę błędu, nie gubi różnic operacyjnych, buduje jedną campaignę i zachowuje dwa findings. Zasada: deduplikuj rekordy, nie security properties.

Powiązane na blogu

SQL Chat: unauthenticated pivot do baz — SSRF jako pivot/oracle
Cisco: jedno CVE, wiele luk — granularność findingu

Źródła

Red Hat — CVE-2026-71365 — access.redhat.com
Red Hat — CVE-2026-71366 — access.redhat.com

Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-71365/71366 (AWX / Ansible Automation Platform): dwa osobne SSRF wyprowadzające różne sekrety (Git PAT vs Basic Auth/Grafana API key). Artykuł koncentruje się na tym, że deduplikacja po product+CWE niszczy informację, oraz na egress filtering per attack path i rotacji sekretów.