Krytyczna luka w GitHub umożliwiała dostęp do milionów prywatnych repozytoriów

GitHub załatał w marcu 2026 roku krytyczną lukę bezpieczeństwa oznaczoną jako CVE-2026-3854, która umożliwiała atakującym zdalne wykonanie kodu i dostęp do milionów prywatnych repozytoriów. Podatność zgłosili 4 marca badacze z firmy Wiz przez program bug bounty platformy.

Szybka reakcja zespołu bezpieczeństwa

Alexis Wales, dyrektor ds. bezpieczeństwa informacji w GitHub, poinformował, że zespół bezpieczeństwa odtworzył i potwierdził podatność w ciągu 40 minut od otrzymania zgłoszenia. Poprawka została wdrożona na GitHub.com niecałe dwie godziny po raporcie.

CVE-2026-3854 dotyka GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud z Data Residency, GitHub Enterprise Cloud z Enterprise Managed Users oraz GitHub Enterprise Server. Skuteczne wykorzystanie wymaga jedynie pojedynczej, złośliwie spreparowanej komendy git push i może przyznać pełny dostęp do odczytu i zapisu prywatnych repozytoriów atakującym posiadającym uprawnienia push.

Mechanizm działania podatności

Luka tkwi w sposobie, w jaki GitHub obsługuje opcje dostarczane przez użytkowników podczas operacji git push. Wartości przekazywane przez użytkowników są włączane do wewnętrznych metadanych serwera bez wystarczającej walidacji, co pozwala atakującym na wstrzyknięcie dodatkowych pól zaufanych przez usługę downstream.

Jak wyjaśnił Wales, atakujący mógł ominąć zabezpieczenia sandboxingu i wykonać dowolny kod na serwerze obsługującym operację push, łącząc w łańcuch wiele wstrzykniętych wartości. Badacz bezpieczeństwa z Wiz, Sagi Tzadik, podkreślił wagę odkrycia: „Wykorzystanie mogło ujawnić kod niemal wszystkich największych przedsiębiorstw na świecie, czyniąc to jedną z najpoważniejszych podatności SaaS, jakie kiedykolwiek znaleziono”.

Skala potencjalnego zagrożenia

Na GitHub.com podatność umożliwiała zdalne wykonanie kodu na współdzielonych węzłach przechowywania danych. Tzadik potwierdził, że miliony publicznych i prywatnych repozytoriów należących do innych użytkowników i organizacji były dostępne na dotkniętych węzłach. W przypadku GitHub Enterprise Server ta sama luka dawała pełną kompromitację serwera, włączając dostęp do wszystkich hostowanych repozytoriów i wewnętrznych sekretów.

Brak dowodów na wcześniejsze wykorzystanie

Mimo powagi problemu, śledztwo kryminalistyczne nie wykazało żadnych dowodów na wykorzystanie luki przed zgłoszeniem przez Wiz. GitHub poinformował, że dane telemetryczne potwierdziły, iż każde wystąpienie anomalnej ścieżki kodu wyzwalanej przez podatność można przypisać wyłącznie testom przeprowadzonym przez badaczy z Wiz.

Wales dodał, że żaden inny użytkownik ani konto nie wywołało ścieżki kodu wykorzystywanej do eksploatacji tej podatności, a żadne dane klientów nie zostały udostępnione, zmodyfikowane ani wykradzione w wyniku wykorzystania CVE-2026-3854 przed wdrożeniem poprawek na GitHub.com.

Pilna aktualizacja dla GitHub Enterprise Server

Podczas gdy GitHub załatał problem na GitHub.com w ciągu 6 godzin, administratorzy GitHub Enterprise Server powinni zaktualizować systemy natychmiast. Tzadik ostrzegł, że około 88% dostępnych instancji GHES pozostaje podatnych na atak.

GitHub przygotował poprawki dla wszystkich wspieranych wydań: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 lub nowsze. Wales stanowczo zalecił wszystkim klientom GHES natychmiastową aktualizację.

Wnioski dla organizacji

Incydent pokazuje wagę programów bug bounty i szybkiej reakcji zespołów bezpieczeństwa. Organizacje korzystające z GitHub Enterprise Server powinny traktować tę aktualizację priorytetowo, szczególnie że publiczne ujawnienie podatności zwiększa ryzyko prób jej wykorzystania przez złośliwych aktorów.

Warto również monitorować logi dostępu do repozytoriów i nietypową aktywność związaną z operacjami git push. Choć nie ma dowodów na wcześniejsze wykorzystanie, organizacje przechowujące wrażliwy kod źródłowy powinny przeprowadzić audyt bezpieczeństwa swoich instancji GHES.