Atak na łańcuch dostaw Laravel-Lang. Pakiety Composer z kradzieżą kluczy do chmury
W drugiej połowie maja wykryto skażenie czterech pakietów Laravel-Lang w repozytorium Composer. Atakujący nadpisali tagi Git, by dostarczyć złośliwy kod kradnący dane dostępowe do chmur, kontenerów i menedżerów haseł.
W maju 2026 roku ujawniono kolejny incydent w łańcuchu dostaw oprogramowania, który dotknął ekosystem PHP. Ofiarą padły cztery popularne pakiety lokalizacyjne dla frameworka Laravel, utrzymywane przez organizację Laravel-Lang. Badacze bezpieczeństwa wskazują, że atakujący przez 15 minut nadpisywali historyczne tagi Git, aby dostarczyć złośliwy kod kradnący dane uwierzytelniające i klucze do infrastruktury chmurowej.
Jak doszło do skażenia pakietów Laravel-Lang?
Według informacji opublikowanych przez serwis SecurityWeek, atak rozpoczął się 22 maja 2026 roku. W ciągu 15 minut napastnicy opublikowali złośliwe wersje tagów w trzech pakietach, a do 23 maja skażone były już wszystkie cztery: laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes i laravel-lang/actions. Firma bezpieczeństwa łańcucha dostaw Socket oceniła, że „czas i wzór nowo opublikowanych tagów wskazują na szersze przejęcie procesu wydawniczego organizacji Laravel-Lang, a nie pojedynczą szkodliwą wersję”.
Złośliwe tagi nadpisały ponad 700 historycznych wersji pakietów. Co kluczowe – jak wyjaśniają badacze z Aikido Security – „szkodliwy kod nigdy nie został zatwierdzony w oficjalnym repozytorium”. GitHub pozwala, by tagi wersji wskazywały na commity z forka tego samego repozytorium. Atakujący wykorzystali tę funkcję, tworząc tagi wskazujące na commity w kontrolowanym przez siebie forku. Dzięki temu malware został dostarczony bez śladu w oficjalnej historii kodu źródłowego.
Co kradnie malware z pakietów Laravel-Lang?
Szkodliwy kod został umieszczony w pliku src/helpers.php, który udawał pomocnik lokalizacyjny Laravela. Po uruchomieniu skrypt identyfikuje maszynę, a następnie łączy się z domeną flipboxstudio[.]info (Command & Control), aby pobrać i uruchomić w tle kradzieżnika (stealera) napisanego w PHP.
Jak podaje Socket, malware był zaprojektowany do wyodrębniania szerokiego spektrum danych wrażliwych: kluczy i tokenów chmurowych (AWS, GCP, Azure), konfiguracji Dockera i Kubernetes, tokenów HashiCorp Vault, konfiguracji repozytoriów Helm, prywatnych kluczy SSH, poświadczeń programistycznych, tokenów uwierzytelniających, plików historii powłoki oraz plików przechowujących dane logowania. Dodatkowo atakujący celowali w dane zgromadzone w przeglądarkach i menedżerach haseł, portfele i rozszerzenia kryptowalut, konfiguracje VPN oraz różne pliki konfiguracyjne i poświadczeniowe na systemach Windows, Linux i macOS.
Kto jest zagrożony i jakie są zalecenia?
Zagrożenie dotyczy wszystkich aplikacji, które pobrały aktualizacje czterech skażonych pakietów lub zainstalowały je od nowa w oknie czasowym ataku (od 22 do 23 maja 2026 r.). Dotyczy to zarówno środowisk programistycznych, jak i serwerów CI/CD czy kontenerów. Eksperci podkreślają, że malware nie działa wyłącznie na jednej platformie – infekuje systemy Windows, Linux i macOS.
Zalecenia są jednoznaczne:
- Zablokuj skażone pakiety w repozytoriach i menedżerach zależności (Composer).
- Potraktuj każdy system, na którym zainstalowano którąkolwiek z tych bibliotek, jako potencjalnie skompromitowany.
- Sprawdź dostępność czystych wersji pakietów i jak najszybciej je zainstaluj.
- Rotuj wszystkie sekrety, które mogły być dostępne na zaatakowanych maszynach. Jak precyzuje Socket, ze względu na zakres celów (chmura, Kubernetes, Vault, CI/CD, przeglądarki, menedżery haseł, SSH, VPN, pliki .env) rotacja powinna objąć wszystkie wrażliwe dane.
W praktyce oznacza to konieczność wygenerowania nowych kluczy API do chmur, odświeżenia tokenów w Kubernetes i Vault, zmiany haseł w menedżerach haseł oraz ponownego wygenerowania par kluczy SSH. Zaleca się również dokładny audyt środowiska pod kątem nieautoryzowanego ruchu do domen C2 oraz podejrzanych procesów.
Co dalej? Kontekst dla administratorów i developerów
Incydent z pakietami Laravel-Lang to kolejny sygnał, że ataki na łańcuch dostaw oprogramowania stały się powszechną taktyką. W ostatnich tygodniach odnotowano podobne zdarzenia: skażenie oficjalnego wtyczki Checkmarx Jenkins (kwiecień/maj 2026) oraz kampanie Shai-Hulud na npm. Charakterystyczne dla tych ataków jest wykorzystanie przejętych poświadczeń do repozytoriów kodu i mechanizmów tagowania, co czyni je trudnymi do wykrycia standardowymi metodami skanowania kodu.
Dla polskich zespołów developerskich i administratorów wniosek jest praktyczny: nie wystarczy ufać oficjalnym repozytoriom. Weryfikacja sum kontrolnych, stosowanie composer.lock z konkretnymi, sprawdzonymi hash’ami, ograniczenie zasięgu aktualizacji automatycznych oraz monitorowanie ruchu sieciowego z serwerów CI/CD to podstawowe, ale skuteczne środki.
W przypadku wykrycia śladów infekcji kluczowe jest szybkie powiadomienie zespołu bezpieczeństwa i zastosowanie się do zaleceń audytu oraz rotacji sekretów, zanim atakujący zdąży wykorzystać skradzione dane.
