Dla administratorów GitHub Enterprise Server: zaktualizuj natychmiast do wersji 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 lub nowszej. Sprawdź /var/log/github-audit.log pod kątem operacji push zawierających średnik w opcjach. GitHub.com jest załatany od 4 marca — użytkownicy GitHub.com nie wymagają żadnych działań.
Dlaczego to jest poważniejsze niż CVSS 8.7 sugeruje: podatność dawała cross-tenant dostęp — Wiz potwierdziło że z jednego węzła storage można było dotrzeć do milionów repozytoriów z innych organizacji. Wymagane uprawnienia: push access do dowolnego repozytorium, łącznie z tym które sami tworzymy.
Jeden średnik
4 marca 2026 roku badacze Wiz wysłali do GitHub raport o podatności. W ciągu 40 minut GitHub zwalidował i potwierdził jej wagę. W ciągu 75 minut od walidacji — mniej niż dwie godziny po zgłoszeniu — poprawka była wdrożona na GitHub.com.
Rdzeń błędu jest prosty. Podczas operacji git push użytkownik może przekazać dodatkowe informacje przez tzw. push options — pary klucz-wartość które trafiają do wewnętrznego systemu przetwarzania. GitHub's internal proxy babeldosadza te wartości w nagłówku X-Stat przekazywanym do kolejnych serwisów.
Format nagłówka używa średnika jako separatora pól. Wartości push option były wstawiane do tego nagłówka bez sanityzacji. Jeden średnik w wartości push option wystarczył żeby wstrzyknąć dodatkowe pola metadanych — pola które kolejne serwisy czytały jako zaufane dane systemowe.
Konkretnie: atakujący mógł wstrzyknąć pole env=development do nagłówka który przekonywał serwer że przetwarza żądanie w środowisku deweloperskim. W środowisku deweloperskim dostępny był code path który nie powinien istnieć w produkcji — ale istniał, bo był częścią obrazu kontenera serwera niezależnie od konfiguracji środowiska. Ten code path zawierał możliwość wykonania skryptu hook z systemu plików bez sandboxa.
Efekt: git push z jedną spreparowaną opcją → wykonanie dowolnych poleceń na serwerze GitHub obsługującym żądanie, poza jakimkolwiek sandboxem.
Cross-tenant blast radius
Jest jeden szczegół w raporcie Wiz który wychodzi poza standardowy opis podatności RCE.
Na GitHub.com repozytoria są przechowywane na współdzielonych węzłach storage. Użytkownik serwisu gitowego — tożsamość z jaką działał skompromitowany serwer — miał dostęp do zasobów wielu najemców jednocześnie. Wiz potwierdził że z wykonanej eksploitacji można było dotrzeć do milionów publicznych i prywatnych repozytoriów należących do innych użytkowników i organizacji na tym samym węźle.
To jest różnica między "zdalne wykonanie kodu na serwerze" a "dostęp do wszystkich repozytoriów na tym węźle storage." Pierwsze brzmi poważnie. Drugie jest jakościowo inne.
GitHub forensics dało pewną odpowiedź na pytanie czy ktokolwiek to eksploitował poza badaczami Wiz. Kluczowa właściwość podatności: exploit wymusza przejście przez code path który nigdy nie jest aktywny podczas normalnych operacji. GitHub zalogował ten path i przeszukał telemetrię. Wszystkie przypadki anomalnego zachowania były powiązane wyłącznie z testami badaczy Wiz.
To jest wartościowy szczegół operacyjny: GitHub wiedział dokładnie na co patrzeć, bo exploit był detekowalny przez swój unikalny sygnał.
Trzy założenia które razem tworzyły podatność
Wiz opisuje architektoniczne serce błędu w zdaniu które jest warte zapamiętania dla każdego kto projektuje systemy wielousługowe:
"One service assumed push option values were safe to embed verbatim. Another assumed every field in the X-Stat header was set by a trusted source. The pre-receive hook assumed an environment variable could only be production in production. Each assumption was reasonable in isolation — and dangerous in combination."
Penligent rozszerza tę obserwację: system miał trzy kategorie danych z różnymi poziomami zaufania — fakty tożsamości i autoryzacji, metadane przetwarzania po stronie serwera, wartości dostarczane przez użytkownika. Błąd nastąpił gdy te kategorie współdzieliły reprezentację która nie zachowywała granic między nimi.
To jest klasyczna klasa błędów w architekturze wielousługowej: dane z różnych źródeł zaufania trafiają do wspólnego formatu bez zachowania ich proweniencji. Każdy serwis zakłada że dane w protokole wewnętrznym są zaufane — bo skąd miałyby tam trafić dane niezaufane? Odpowiedź: przez brak sanityzacji na wejściu do protokołu.
Dwie lekcje inżynierskie zamiast jednej
GitHub naprawił nie jeden problem ale dwa, i ta decyzja jest warta osobnego omówienia.
Pierwsza naprawa: sanityzacja wejścia. Push options są teraz oczyszczane ze średnika przed osadzeniem w nagłówku wewnętrznym. To jest oczywista i konieczna naprawa.
Druga naprawa: usunięcie niepotrzebnego code path z produkcyjnych kontenerów. Code path który umożliwiał wykonanie skryptu hook bez sandboxa był częścią obrazu kontenera serwera mimo że był przeznaczony dla innej konfiguracji. Był tam bo "nie szkodzi" — nie był wywoływany przy normalnych operacjach.
Penligent ujmuje lekcję precyzyjnie: "Fix the injection, but also remove the execution path that made the injection valuable."
Samo naprawienie sanityzacji eliminuje tę konkretną podatność. Usunięcie zbędnego code path eliminuje całą klasę przyszłych podatności które mogłyby go wywołać przez inne wektory. To jest różnica między naprawianiem symptomów a naprawianiem architektury.
Odkryte przez AI w zamkniętym kodzie
Jest jeszcze jeden szczegół tej historii który łączy ją bezpośrednio z tym co cyberflux opisywał przez cały kwiecień.
Wiz wprost odnotowuje w swoim raporcie: CVE-2026-3854 jest jedną z pierwszych krytycznych podatności odkrytych w zamkniętym kodzie binarnym przy użyciu AI. GitHub's internal binary to nie jest open source — nie można go przeczytać jak kodu źródłowego Marimo czy LiteLLM. Wiz używał AI do analizy skompilowanych binariów.
Pisaliśmy o trzynastoletnim błędzie w Apache ActiveMQ znalezionym przez badacza który wprost powiedział że "80% Claude, 20% człowieka". CVE-2026-3854 jest następnym krokiem: nie open source z dostępnym kodem, ale zamknięty binarny kod produkcyjnego systemu. Ta kategoria była wcześniej praktycznie nieprzeszukiwalna automatycznie — zbyt skomplikowana dla klasycznych analizatorów statycznych.
Jeśli AI może znajdować krytyczne podatności w zamkniętych binariach — lista systemów które można teraz efektywnie analizować właśnie się dramatycznie poszerzyła.
Kontekst: GitHub w trudnym tygodniu
Medium opisuje tygodniowe okno wokół ujawnienia CVE-2026-3854 z nieoczekiwanym kontekstem.
Pięć dni przed ujawnieniem CVE: merge queue GitHuba po cichu cofnął 2092 pull requestów bez ostrzeżenia — błąd w sercu mechanizmu który organizacje korporacyjne traktują jako gwarancję integralności procesu wydawania. Dwa dni wcześniej: wyszukiwarka GitHuba przestała działać pod obciążeniem opisanym jako prawdopodobny atak botnetem.
Trzy osobne awarie w pięciu dniach na platformie która nie ma CEO od prawie roku. GitHub CTO Vlad Fedorov opublikował komunikat restartujący priorytety inżynierskie: "Availability first, then capacity, then new features."
Medium komentuje sucho: "If that order needed restating, the prior order was something else."
To nie jest centralna część historii o CVE-2026-3854 — błąd bezpieczeństwa i błędy operacyjne to różne kategorie. Ale łącznie opisują platformę pod presją w momencie gdy ujawniono podatność która dawała dostęp do milionów repozytoriów.
Połączenie z tym co opisywaliśmy w maju
Comment and Control opisywał git push jako wektor wstrzyknięcia przez tytuły zgłoszeń i komentarze. Cursor CVE-2026-26268 pokazał git hooks jako wektor gdy agent AI autonomicznie wykonuje operacje Git. Shai-Hulud przez Dependabot używał GitHuba jako infrastruktury C2 przez publiczne commits. TeamPCP deployuje przez GitHub Actions.
CVE-2026-3854 zamyka ten obraz: nie tylko Git jako wektor przez agentów AI i złośliwe pakiety, ale Git push jako wektor do serwera GitHub samego w sobie. Infrastruktura na której wszystko powyższe się dzieje miała przez 54 dni (między poprawką a publicznym ujawnieniem) niezałataną podatność w GitHub Enterprise Server która pozwalała na RCE jednym poleceniem.
Dla organizacji z własnym wdrożeniem GHES: okno między 4 marca a 28 kwietnia to okno które warto zbadać w telemetrii pod kątem anomalnych push operations.
Podsumowanie
CVE-2026-3854 to podatność której exploit jest elegancko prosty — jeden średnik w push option — a architektoniczne przyczyny są głębsze niż pojedynczy brakujący check sanityzacji. Trzy serwisy z trzema różnymi założeniami o zaufaniu danych, przekazujące dane przez wspólny protokół bez zachowania granic proweniencji.
GitHub zareagował szybko i wzorcowo: 75 minut do poprawki na GitHub.com, usunięcie zbędnego code path jako druhga warstwa ochrony, forensics potwierdzające brak eksploitacji. To jest przykład jak powinno wyglądać odpowiedzialne ujawnianie i odpowiedź vendora.
Lekcja strukturalna pozostaje niezależnie od szybkości reakcji: każdy system wielousługowy który łączy dane użytkownika z metadanymi systemowymi w jednym protokole wewnętrznym bez wyraźnej separacji granic zaufania — ma tę samą architektoniczną podatność. Różni się tylko tym gdzie siedzi średnik.
Źródła
Wiz Research — pierwotna analiza techniczna z diagramem łańcucha exploitacji: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
GitHub Blog — oficjalny opis odpowiedzi, forensics i lekcji inżynierskich: https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/
Penligent — analiza architektury trust boundaries i lekcja "remove the execution path": https://www.penligent.ai/hackinglabs/github-cve-2026-3854-the-rce-in-the-git-push-pipeline/
The Hacker News — omówienie z kontekstem GHES patches: https://thehackernews.com/2026/04/researchers-discover-critical-github.html
Medium / monkfromearth — kontekst trzech awarii GitHuba w pięciu dniach: https://medium.com/@monkfromearth/github-let-a-git-push-hijack-its-servers-rce-cve-2026-3854-2f9e3e8be660
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł