CVE-2026-3854 to ten rodzaj błędu, którego nie chcesz widzieć w ścieżce git push. GitHub w opisie incydentu nazywa go krytycznym zdalnym wykonaniem kodu. Wpis nie podaje wyniku CVSS. Najgorsze w tym opisie jest to, że nie brzmi egzotycznie: zwykły workflow programisty zrobił się groźny, bo parser potraktował cudzy tekst jak służbową przepustkę.
Zgłoszenie przyszło przez Bug Bounty 4 marca 2026 od badaczy Wiz. GitHub pisze, że zespół odtworzył problem w 40 minut i wdrożył poprawkę na github.com o 19:00 UTC, mniej niż dwie godziny po ustaleniu przyczyny o 17:45 UTC. Tempo robi wrażenie. Rozmiar miotły też: jeśli w dwie godziny trzeba łatać RCE w git push, problem nie był drobnym paprochem pod dywanem.
Atak używał spreparowanej opcji git push. Push options są normalną funkcją Git, pozwalającą klientowi wysłać ciągi klucz-wartość podczas push. Brzmi jak księgowość protokołu, więc łatwo zasnąć. Nie warto.
Według GitHuba dane użytkownika trafiły do wewnętrznych metadanych bez wystarczającej sanitizacji. Ponieważ format metadanych używał separatora, który mógł pojawić się też w wejściu użytkownika, atakujący mógł wstrzyknąć pola wyglądające jak zaufane, zmienić środowisko przetwarzania, ominąć sandbox i wykonać polecenia na serwerze obsługującym push. Vabank miał bardziej elegancki skok. Tu wystarczyły separator, dane wejściowe i zaufanie położone na złej półce.
Użytkownicy chmury nie muszą nic robić: github.com i warianty GitHub Enterprise Cloud zostały załatane 4 marca. Klienci GitHub Enterprise Server mają zwykłą administracyjną dniówkę, bez konfetti. GitHub wymienia poprawione wydania 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 i 3.20.0 lub nowsze. Zaleca też sprawdzenie /var/log/github-audit.log pod kątem operacji push ze średnikiem w opcjach push.
Akapit o wykorzystaniu trzeba czytać ostrożnie. GitHub twierdzi, że telemetria przypisała każde wejście w nietypową ścieżkę kodu testom Wiz i że dane klientów nie zostały odczytane, zmienione ani wyprowadzone. Ja czytam to jako raport operatora, a nie pieczątkę z nieba. Mimo to punkt techniczny jest konkretny: exploit wymuszał ścieżkę kodu nieużywaną normalnie na github.com.
Najbardziej praktyczna lekcja dotyczy obrony warstwowej. GitHub pisze, że exploit zadziałał częściowo dlatego, że niepotrzebna ścieżka kodu nadal leżała na dysku w obrazie kontenera po zmianie modelu wdrożenia. Starsza metoda ją wycinała. Nowsza nie przeniosła tego wykluczenia. Zauważyłem tę linijkę, bo jest boleśnie zwyczajna: nowy model wdrożenia wygląda nowocześnie, a w środku nadal ktoś zostawił stary klucz pod wycieraczką.
Dla administratora wniosek jest mało poetycki: zainstaluj poprawione GHES, przeszukaj /var/log/github-audit.log i potraktuj martwy kod w Twoich obrazach jak łom zostawiony przy drzwiach serwerowni. GitHub zasłużył na pochwałę za tempo. Martwy kod na dysku nie zasłużył na kolejną szansę.