Strona główna / Blog / GHES: topologia zmienia CVE

Blog · case study

GitHub Enterprise Server: unauthenticated SSRF z replayable management tokenem, ale HA nie jest affected. Dlaczego topologia zmienia CVE

GitHub 1 września opublikował poprawki dla GitHub Enterprise Server. CVE-2026-18730 pozwala unauthenticated attackerowi podać spreparowaną konfigurację klastra do Manage API, wymusić outbound request do hosta kontrolowanego przez atakującego i — przy możliwości przechwycenia odpowiedzi — pozyskać replayable management bearer token. Najciekawszy detal: deploymenty high-availability nie są affected z powodu ograniczeń topologii.

CVE-2026-18730: unauthenticated SSRF przez Manage API → outbound request → replayable management token.
Nie affected: deploymenty HA (ograniczenia topologii).
Fixed: GHES 3.17 / 3.18 (release notes, 01.09.2026).

Dlaczego to ważne dla VM?

Dwie instancje GHES z tą samą wersją mogą mieć inny status: standalone może być affected, HA może nie być. Scanner mapujący tylko wersję wygeneruje false positive dla topologii wyłączającej attack path. Dojrzały finding powinien uwzględniać tryb HA, exposure Manage API, outbound network path i możliwość przechwycenia żądania.

Token replay jako drugi etap

SSRF nie jest tu końcem chainu. Wartość ataku wynika z management tokenu, którego HMAC nie wiązał path/body w sposób uniemożliwiający replay przeciwko privileged agent endpoints. Czyli: SSRF → przechwycenie odpowiedzi → replayable token → operacje uprzywilejowane. To sekwencja, nie pojedynczy prymityw — i dopiero drugi etap definiuje realny impact.

Co powinien zrobić Vulnerability Engineer?

  1. Zinwentaryzuj instancje GHES i ustal tryb: standalone czy HA.
  2. Dla standalone traktuj jako affected; dla HA oznacz NOT_AFFECTED: topology z dowodem (nie „False Positive”).
  3. Sprawdź exposure Manage API i outbound path z urządzenia.
  4. Zaktualizuj do 3.17/3.18 wg linii; po aktualizacji potwierdź, że replay tokenu nie jest już możliwy.

Wniosek

CVE-2026-18730 pokazuje, że topologia może być częścią affectedness tak samo jak feature flag, hardware czy runtime config. Bez danych o architekturze scanner może być wersyjnie poprawny, ale operacyjnie błędny. Pytanie brzmi nie „czy mamy podatną wersję GHES?”, tylko: czy w tej konkretnej topologii ścieżka ataku w ogóle istnieje?

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-18730 w GitHub Enterprise Server: unauthenticated SSRF przez Manage API prowadzący do replayable management bearer token; deploymenty HA nie są affected z powodu ograniczeń topologii; poprawki w GHES 3.17/3.18. Artykuł koncentruje się na topology-aware affectedness.

Zapamiętaj jedno

Dwie instancje z tą samą wersją mogą mieć różny status: standalone affected, HA nie. Topologia jest częścią affectedness tak samo jak feature flag czy runtime config — bez danych o architekturze scanner bywa wersyjnie poprawny, ale operacyjnie błędny.