Atak na łańcuch dostaw Laravel-Lang: złośliwe pakiety Composer po zatruciu tagów Git - Security Bez Tabu

Atak na łańcuch dostaw Laravel-Lang: złośliwe pakiety Composer po zatruciu tagów Git

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem open source od lat pozostaje jednym z głównych celów ataków na łańcuch dostaw oprogramowania. Incydent dotyczący pakietów Laravel-Lang pokazuje, że zagrożenie nie musi wynikać wyłącznie z modyfikacji kodu w głównym repozytorium. W tym przypadku napastnicy wykorzystali mechanizm tagowania wersji w Git, aby skierować zaufane identyfikatory wydań do złośliwych commitów i rozprowadzić malware za pośrednictwem Composera.

W skrócie

W maju 2026 roku ujawniono kompromitację kilku popularnych pakietów społecznościowego projektu Laravel-Lang używanych do lokalizacji aplikacji Laravel. Atak objął pakiety laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes oraz laravel-lang/actions. Napastnicy przepisali setki historycznych tagów Git, wskazując je na złośliwe commity powiązane z forkiem, a nie z oficjalnym kodem źródłowym.

  • atak objął wiele pakietów jednocześnie,
  • zmieniono powiązania tagów wersji z commitami,
  • złośliwy kod był dostarczany podczas standardowej instalacji zależności,
  • celem malware była kradzież poświadczeń i sekretów środowiskowych.

Kontekst / historia

Laravel-Lang to rozwijany przez społeczność projekt dostarczający pliki tłumaczeń i komponenty lokalizacyjne dla aplikacji opartych o framework Laravel. Choć pakiety te nie są częścią oficjalnego rdzenia Laravel, są szeroko stosowane w środowiskach developerskich i produkcyjnych.

Podejrzaną aktywność zaobserwowano 22 i 23 maja 2026 roku, kiedy w krótkim czasie opublikowano dużą liczbę tagów w wielu repozytoriach tej samej organizacji. Taki wzorzec sugerował kompromitację procesu wydawniczego lub uprawnień do publikacji, a nie incydent ograniczony do pojedynczego pakietu. To istotne, ponieważ problem dotyczył samego zaufania do metadanych wersji i mechanizmów release management.

Analiza techniczna

Techniczny rdzeń ataku polegał na zatruciu tagów Git. Zamiast wprowadzać zmiany w sposób łatwy do wykrycia podczas standardowego przeglądu kodu, napastnicy przypisali tagi wersji do commitów znajdujących się w forku repozytorium. W praktyce oznaczało to, że użytkownik pobierający określoną wersję pakietu mógł otrzymać artefakt zawierający złośliwy kod, mimo że główna gałąź projektu nie wykazywała oczywistych oznak kompromitacji.

Według opublikowanych analiz przepisano ponad 700 tagów odnoszących się do historycznych wersji kilku pakietów. Taki model działania podważa częste założenie, że pinning do numeru wersji zapewnia stabilność i bezpieczeństwo. Jeżeli sam tag zostanie przestawiony na inny commit, organizacja może pobrać inny kod niż zakładano, nawet przy pozornie niezmienionej wersji semantycznej.

Złośliwy komponent był uruchamiany w toku normalnej pracy mechanizmu autoload Composer. Malware działał wieloetapowo: inicjował kontakt z serwerem zdalnym, pobierał drugi etap ładunku, zapisywał go w ukrytej lokalizacji tymczasowej i uruchamiał na systemie ofiary. Analizy wskazują również na mechanizmy utrudniające detekcję, takie jak ukrywanie infrastruktury C2 oraz wyłączanie weryfikacji TLS w celu zwiększenia skuteczności pobierania kolejnych elementów infekcji.

Złośliwy kod miał charakter cross-platformowy i był napisany w PHP, dzięki czemu mógł działać w środowiskach Linux, Windows i macOS. Jego funkcjonalność obejmowała kradzież danych z wielu źródeł:

  • poświadczeń chmurowych AWS, Azure i GCP,
  • sekretów Kubernetes,
  • tokenów i danych z pipeline’ów CI/CD,
  • danych z przeglądarek i menedżerów haseł,
  • konfiguracji klientów VPN i poczty,
  • plików konfiguracyjnych, zmiennych środowiskowych oraz kluczy aplikacyjnych.

Dodatkowo malware zawierał mechanizmy ograniczające wielokrotne wykonanie na tej samej maszynie, co zmniejszało ryzyko wzbudzenia podejrzeń i utrudniało analizę incydentu.

Konsekwencje / ryzyko

Ryzyko związane z tym incydentem jest wysokie, ponieważ atak dotyczy zaufanego elementu procesu budowania i wdrażania oprogramowania. Najbardziej niebezpieczny scenariusz obejmuje środowiska, w których wykonano composer update, świeżą instalację zależności albo automatyczne odtworzenie środowiska po 22 maja 2026 roku.

  • przejęcie sekretów środowiskowych i kont chmurowych,
  • kompromitacja runnerów CI/CD,
  • wyciek kluczy API, tokenów Git i danych dostępowych do baz danych,
  • dalszy ruch boczny w infrastrukturze organizacji,
  • kompromitacja kontenerów, serwerów buildowych i stacji developerskich,
  • utrata integralności procesu dostarczania oprogramowania.

Kluczowe jest to, że użycie zainfekowanej wersji należy traktować jako potencjalne naruszenie bezpieczeństwa, a nie wyłącznie ekspozycję na podatność. W tym przypadku mamy do czynienia z aktywnym malware nastawionym na kradzież danych uwierzytelniających.

Rekomendacje

Organizacje korzystające z pakietów Laravel-Lang powinny przeprowadzić pilną weryfikację wszystkich projektów i środowisk, w których występowały wskazane zależności. Reakcja nie powinna ograniczać się wyłącznie do aktualizacji pakietów, lecz obejmować pełną obsługę incydentu.

  • sprawdzić pliki composer.lock, logi buildów i historię instalacji zależności,
  • ustalić, czy po 22 maja 2026 roku wykonywano aktualizacje lub świeże buildy,
  • zablokować instalację kompromitowanych wersji i korzystać wyłącznie ze zweryfikowanych wydań,
  • traktować wszystkie sekrety dostępne z poziomu dotkniętych hostów jako potencjalnie przejęte,
  • przeprowadzić rotację kluczy chmurowych, tokenów CI/CD, haseł do baz danych, kluczy SSH i danych VPN,
  • odbudować systemy z zaufanych obrazów lub znanych dobrych snapshotów,
  • zachować artefakty śledcze, logi i wskaźniki kompromitacji przed czyszczeniem środowiska,
  • wdrożyć dodatkowe kontrole łańcucha dostaw, w tym monitoring zmian tagów i walidację integralności pakietów,
  • rozważyć pinning do commit SHA lub użycie wewnętrznych mirrorów pakietów,
  • przeprowadzić audyt uprawnień publikacyjnych i procesu release management.

Podsumowanie

Incydent z Laravel-Lang to kolejny przykład dojrzałego ataku na łańcuch dostaw, w którym zaufanie do wersjonowania zostało wykorzystane przeciwko użytkownikom. Najważniejsza lekcja jest jasna: sam numer wersji nie gwarantuje integralności, jeśli mechanizm publikacji i tagowania może zostać przejęty. Dla zespołów bezpieczeństwa oznacza to konieczność monitorowania nie tylko kodu źródłowego, lecz także metadanych wydań, procesu dystrybucji oraz zachowania zależności podczas instalacji. W praktyce każda organizacja, która pobrała dotknięte pakiety w oknie kompromitacji, powinna zakładać możliwość wycieku sekretów i prowadzić działania jak po pełnoprawnym incydencie bezpieczeństwa.

Źródła