Luka RCE w GitHubie – CVE-2026-3854 i co musisz zrobić

Wystarczyło darmowe konto na GitHubie, puste repozytorium i jeden push z przygotowaną opcją. Tyle, żeby uruchomić własny kod na backendzie. W ten sposób działała luka RCE w GitHubie oznaczona jako CVE-2026-3854. Badacze firmy Wiz zgłosili ją 4 marca 2026, a publiczne ogłoszenie nastąpiło 28 kwietnia. Dlatego GitHub.com załatano w mniej niż dwie godziny. Skala potencjalnego wycieku była ogromna, w efekcie priorytet był maksymalny. Z kolei firmy z GitHub Enterprise Server miały gorzej. Łatka wyszła wprawdzie 10 marca, jednak w dniu ujawnienia aż 88 procent instancji wciąż jej nie miało. Dlatego jeśli masz GHES u siebie – ten artykuł jest dla Ciebie pilny.

Co dokładnie się stało?

Luka siedziała w komponencie o nazwie babeld. To wewnętrzny serwer pośredniczący Gita, który GitHub wykorzystuje na swoich serwerach do obsługi pushy. Babeld kopiował wartości tak zwanych “push options” (opcjonalnych parametrów, które klient Gita może przesłać razem z pushem) bezpośrednio do nagłówka wewnętrznego o nazwie X-Stat. Bez sanitacji średników. Brzmi technicznie, ale analogia jest prosta. Wyobraź sobie kelnera, który zapisuje zamówienia oddzielając je średnikami – “kawa; herbata; sok”. Jeśli klient zamówi “kawa; usuń wszystkie pozostałe zamówienia kuchni”, a kelner po prostu przepisze to na kartkę dla kucharza, kuchnia wykona obie komendy.

To dokładnie to, co zrobił babeld. Atakujący mógł podstawić w opcjach pusha treść z dodatkowym średnikiem i komendą. W rezultacie ta komenda trafiała do wewnętrznego procesu serwera już jako poprawnie sparsowana instrukcja. W efekcie dochodziło do wykonania zdalnego kodu, czyli RCE (Remote Code Execution).

Push do darmowego, świeżo utworzonego repo wystarczał, żeby uruchomić atak. Próg wejścia praktycznie zero.

CVSS oceniono na 8.7 (kategoria High, nie Critical mimo nagłówków na social mediach). Atak wymagał wprawdzie uwierzytelnienia, jednak każdy może w 30 sekund założyć darmowe konto na GitHub.com. Dlatego ten warunek nikogo nie chronił.

Dlaczego skala robi z tego coś poważnego?

GitHub.com to architektura wielu klientów na wspólnej infrastrukturze. Jeden storage node hostuje repozytoria różnych firm i osób – prywatne, publiczne, źródła zamknięte i otwarte. Dlatego jeśli ktoś dostanie wykonanie kodu na takim wspólnym węźle, może w teorii przeglądać dane sąsiadów. Co więcej, dzieje się to niezależnie od ustawionych uprawnień repo. To trochę jak włam do skrytek w skarbcu banku, gdzie klucze są wprawdzie różne, ale ściana między skrytkami okazuje się być z dykty.

Dlatego GitHub potraktował zgłoszenie priorytetowo. Walidacja proof-of-concept zajęła 40 minut, fix na produkcji wszedł tego samego dnia. To rzadki przykład sytuacji, w której platforma cloud zachowuje się jak należy. Czyli reaguje natychmiast i sama dba o klienta, bez angażowania go w cokolwiek.

Patch – GitHub.com vs Enterprise Server

Sytuacja po stronie cloudu i po stronie on-prem wyglądała diametralnie różnie. Po jednej stronie błyskawiczna reakcja, natomiast po drugiej miesiące oczekiwania na wdrożenie u klientów. W rezultacie poniższa tabela pokazuje skalę różnicy.

Co się dzieje w praktyce? W dniu publicznego ujawnienia luki Wiz oszacował, że 88 procent instancji Enterprise Server wciąż nie ma łatki wydanej 7 tygodni wcześniej. Dlaczego? Bo on-prem to inny rytm. Aktualizacja serwera GHES wymaga okna serwisowego, testów regresji wewnętrznych integracji i podpisu szefa zespołu DevOps. Cloud się aktualizuje sam, on-prem czeka aż człowiek znajdzie czas. To nie pierwszy taki przypadek w popularnym narzędziu dla deweloperów. Połowa świata nie wgrywa łatek miesiącami. Wystarczy spojrzeć na podobną lukę RCE w n8n CVE-2026-33660 – tygodnie po wydaniu poprawki tysiące instancji wisiały bez aktualizacji.

Co zrobić TERAZ jeśli masz GHES?

Cztery konkretne kroki, w tej kolejności. Nie odkładaj na poniedziałek. Działający kod ataku został opublikowany przez Wiz tego samego dnia co ujawnienie luki. Każdy z odrobiną Pythona już wie, jak ją wywołać.

Krok 1 – sprawdź wersję GHES

Zaloguj się na panel admina GHES i sprawdź numer wersji. Jeśli jesteś niżej niż łatany numer dla Twojej gałęzi (zobacz tabelę powyżej) – jesteś podatny. Punkt.

Krok 2 – upgrade do załatanej wersji

GitHub publikuje pełne instrukcje aktualizacji dla każdej gałęzi GHES. Najpierw środowisko testowe, potem produkcyjne. Tak, wiem, że w piątek to się nie chce robić. Ale poniedziałek z bazą danych zhakowaną w weekend wygląda gorzej.

Krok 3 – audyt logów

Otwórz /var/log/github-audit.log na serwerze GHES. Przeszukaj historię od marca 2026 pod kątem operacji push, w których opcje pusha zawierały nietypowe znaki. Analiza GitHuba potwierdziła, że jedyne odnotowane “anomalne” wywołania należały do badaczy Wiz. Ale to dotyczy tylko cloudu. Twój on-prem mogli odwiedzić inni.

Krok 4 – rotacja sekretów (jeśli paranoja)

Jeżeli logi pokazują podejrzane wzorce w okresie marzec-kwiecień, potraktuj instancję jako potencjalnie skompromitowaną. Regeneruj klucze SSH wdrożone na serwerze, tokeny PAT z dostępem admin i sekrety w GitHub Actions. Niewygodne, ale tańsze niż ujawnienie kodu produkcyjnego.

Kurs n8n 2.0 · Kodożercy

Automatyzacja to dziś jedna z najbardziej poszukiwanych umiejętności

Firmy szukają ludzi, którzy łączą procesy z narzędziami. Kurs n8n 2.0 na Kodożercach da Ci praktyczne umiejętności – webhooki, API, automatyczne przepływy danych – które możesz pokazać już jutro.

Zobacz program kursu →

Lekcja na przyszłość – command injection przez delimiter to całe rodziny luk

Najbardziej znana klasa luk to klasyczne shell injection. Atakujący umieszcza w polu tekstowym średnik lub znak potoku, a aplikacja przekazuje to dalej do powłoki systemu. Każdy junior słyszał o tym przy nauce sanitacji wejścia. Ale luka RCE w GitHubie to inny przypadek. Tu nie chodziło o shella, tylko o wewnętrzny protokół komunikacji między komponentami GitHuba, który średnik traktował jako separator pól. Programista pisząc kod nie patrzył na średniki, bo “to nie shell, nie ma się czym przejmować”. A jednak.

Tam, gdzie różne warstwy systemu używają różnych delimiterów, atakujący znajdzie dziurę. To prawdopodobnie najczęściej niedoceniana klasa luk w 2026.

To samo widzieliśmy w innych głośnych incydentach z ostatnich miesięcy. Świeży atak na bibliotekę Bitwarden CLI w npm wykorzystywał coś podobnego. Inny rodzaj zaufania między komponentami, inne skutki, ten sam mechanizm psychologiczny dewelopera. “To bezpieczne, nikt tego nie używa do ataku”. Wniosek dla zespołu? Każdy moment przekazania danych między komponentami z różnymi konwencjami parsowania wymaga jawnego escapowania. Nie “powinno być ok” – tylko jawnego escape.

FAQ – najczęstsze pytania o lukę RCE w GitHubie

Czy mój kod na GitHub.com mógł zostać wykradziony?

Mało prawdopodobne. Analiza GitHuba potwierdziła, że wszystkie odnotowane wywołania z marca i kwietnia 2026 mapowały się na działania badaczy Wiz. Nie było realnych ataków. Cloud załatano w niecałe dwie godziny od zgłoszenia, więc okno potencjalnej eksploitacji było wąskie.

Jak sprawdzić, czy nasza instancja GHES jest podatna?

Wejdź na panel administracyjny GHES, sprawdź numer wersji i porównaj z tabelą łatek powyżej. Jeśli jesteś niżej niż minimalny załatany numer dla Twojej gałęzi, instancja jest podatna. Wiz oszacował 88 procent niezałatanych instancji w dniu disclosure – statystycznie najpewniej jesteś w tej grupie.

Czy są dowody, że ktoś wykorzystał lukę w dziczy?

Według GitHuba i Wiz – nie. Brak odnotowanych przypadków eksploitacji poza testami badaczy. Ale to dotyczy okresu sprzed publicznego ujawnienia. Po 28 kwietnia publiczny działający kod ataku jest dostępny. Każdy może spróbować na niezałatanym GHES.

Podsumowanie

Luka RCE w GitHubie oznaczona jako CVE-2026-3854 to kolejny przypadek, w którym cloud zachował się wzorowo. Łatka w mniej niż dwie godziny. Z kolei on-prem został z 88 procentami niezałatanych instancji w dniu publicznego ogłoszenia. Mechanizm był prosty: babeld kopiował wartości opcji push do wewnętrznego nagłówka bez escapingu średników. Pozwalało to atakującemu wstrzyknąć komendę do innej warstwy systemu. Każdy mógł zrobić darmowe konto i spróbować. Jeśli masz GitHub Enterprise Server, sprawdź wersję i zaktualizuj do co najmniej 3.19.3. Następnie przejrzyj logi audit pod kątem podejrzanych pushy z marca i kwietnia. Jeśli masz tylko GitHub.com – możesz spać spokojnie. Ten incydent przypomina jednak, że niesanitowany separator między komponentami systemu to klasa luk równie groźna jak SQL injection sprzed dwudziestu lat.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.