Nie każdy poważny incydent zaczyna się od exploita. Czasem wystarczy, że przy wdrożeniu strony na serwer trafi razem z plikami także ukryty katalog .git — i nikt tego nie zauważy. Opublikowane 26 sierpnia 2026 roku badanie firmy Intruder pokazuje, jak powszechny jest ten błąd: po przeskanowaniu 3,5 miliona aktywnych hostów badacze znaleźli 28 tysięcy repozytoriów Git dostępnych publicznie przez przeglądarkę. W środku były klucze do chmury, tokeny płatnicze i dokumenty kadrowe.
Jak wygląda ten błąd w praktyce
Mechanizm jest banalny. Deweloper wdraża projekt na produkcję przez git clone albo git pull prosto w katalogu publicznym serwera, albo kopiuje folder projektu przez FTP wraz z całą zawartością. Katalog .git zostaje w public_html, a serwer WWW nie ma reguły, która blokowałaby do niego dostęp. Wystarczy wtedy pobrać pliki HEAD, packed-refs i objects/info/packs, żeby zautomatyzowany skaner odtworzył całą historię repozytorium — łącznie z plikami, których dawno nie ma w bieżącej wersji kodu.
I tu jest sedno problemu. Usunięcie hasła z pliku konfiguracyjnego i wypchnięcie poprawki nie kasuje starego commita. Klucz sprzed dwóch lat, wpisany „tymczasowo na testy”, nadal siedzi w historii i jest odczytywalny dla każdego, kto pobierze repozytorium. Badacze napisali w tym celu własne narzędzie o nazwie gitreaper, które przegląda historię w pamięci, bez pobierania całych projektów — czyli robi dokładnie to, co robi napastnik, tylko szybciej.
Co udało się znaleźć
Skala znalezisk robi wrażenie. W przeanalizowanych repozytoriach było ponad 400 kluczy dostępowych AWS, 107 kluczy API Stripe, 123 klucze OpenAI, 80 tokenów Telegrama i 17 osobistych tokenów GitHuba. Część z nich w momencie testu wciąż działała, co oznacza, że dawała realny dostęp do powiązanych środowisk.
Dwa przypadki opisane w raporcie pokazują, dokąd to prowadzi. Jeden zaszyty w kodzie klucz AWS otwierał kubełek z wewnętrznymi dokumentami kadrowymi — listami obecności i aktami dyscyplinarnymi pracowników. Taki materiał to gotowa amunicja pod ukierunkowany phishing albo szantaż konkretnej osoby. Drugi klucz, zapisany w pliku konfiguracyjnym, dawał wgląd w historię płatności i wypłat: przychody, harmonogramy przelewów i fragmenty numerów kont. Przy odpowiednich uprawnieniach takim kluczem można wystawiać zwroty albo przekierować wypłaty.
Warto dodać kontekst, bo to nie jest odosobnione zjawisko. Osobne badania z tego roku wskazują, że blisko 5 milionów serwerów WWW udostępnia metadane repozytoriów Git, a ponad ćwierć miliona wystawia plik .git/config z danymi wdrożeniowymi. Boty polujące na klucze AWS potrafią znaleźć świeżo ujawniony sekret w kilka minut.
Co z tym zrobić
Jeśli utrzymujesz choćby jedną stronę na własnym hostingu, warto to sprawdzić dzisiaj — zajmuje to minutę.
- Wejdź na
https://twojadomena.pl/.git/HEAD. Jeśli zobaczysz linijkę zaczynającą się odref: refs/heads/, masz problem i trzeba działać natychmiast. - Zablokuj dostęp do katalogu na poziomie serwera. W Apache wystarczy w
.htaccessregułaRedirectMatch 404 /\.git, w nginx bloklocation ~ /\.git { deny all; return 404; }. - Nie wdrażaj przez
git clonedo katalogu publicznego. Buduj projekt pozapublic_htmli kopiuj na produkcję tylko pliki wynikowe, na przykład przez rsync z wykluczeniem.git. - Załóż, że każdy sekret, który kiedykolwiek był w repozytorium, jest już skopiowany. Rotuj go, nie licz na to, że skoro nikt się nie włamał, to nikt go nie ma.
- Przejrzij logi chmury i systemu płatności pod kątem nietypowej aktywności — nieznanych adresów IP, wywołań API o dziwnych porach, operacji spoza zwykłego zakresu.
- Przenieś sekrety poza kod. Zmienne środowiskowe, plik
.envpoza katalogiem publicznym i wpisany do.gitignore, a docelowo menedżer sekretów. - Włącz skanowanie commitów pod kątem sekretów. Prosty hook
pre-commitz gitleaks kosztuje kwadrans konfiguracji i wyłapuje większość wpadek zanim trafią do historii.
Podsumowanie
To badanie dobrze pokazuje, że najczęstszą drogą do firmowej chmury nie jest wyrafinowany exploit, tylko zapomniany plik. Wystawiony katalog .git należy traktować jak pełnoprawny incydent bezpieczeństwa, a nie jak drobną nieprawidłowość konfiguracji serwera — bo jest w praktyce przeszukiwalnym archiwum dostępów do całej organizacji. Intruder poinformował właścicieli tych repozytoriów, które udało się zidentyfikować, i część z nich zniknęła z sieci. Reszta wciąż tam jest. Sprawdzenie własnych domen zajmuje mniej czasu niż przeczytanie tego tekstu.
źródło: https://cybersecuritynews.com/28000-exposed-git-repositories/ https://www.intruder.io/research/api-keys-bank-details-disciplinary-files-what-28-000-exposed-git-repos-gave-up