Atak na łańcuch dostaw w ekosystemie Laravel. Jak programiści mogą chronić swoje projekty?
Złośliwe pakiety Laravel Lang dystrybuowały kradzież poświadczeń. Opisujemy mechanizm ataku i podajemy konkretne kroki defensywne dla zespołów developerskich.
Pod koniec maja 2026 roku świat programistów PHP obiegła wiadomość o złożonym ataku na łańcuch dostaw, który wymierzony był w pakiet lokalizacyjny Laravel Lang. Badacze z firm StepSecurity, Aikido Security i Socket ostrzegli, że napastnicy wykorzystali mechanizm tagów w repozytoriach GitHub, by rozsiać złośliwy kod w pakietach Composer. Atak nie polegał na stworzeniu nowej, złośliwej wersji pakietu, lecz na podmianie istniejących tagów w czterech repozytoriach należących do organizacji Laravel Lang. Taka technika czyni standardowe narzędzia programistyczne, które domyślnie ufają danym tagom, wektorem zagrożenia.
Jak działał atak i kogo dotknął?
Zgodnie z analizą opublikowaną przez BleepingComputer, napastnicy wykorzystali, że tagi w GitHub mogą wskazywać na commity w forku tego samego repozytorium. Zamiast modyfikować kod źródłowy projektu, przepisali każdy istniejący tag, by wskazywał na złośliwy commit. Operacja rozpoczęła się 22 maja o 22:32 UTC od repozytorium laravel-lang/lang i objęła wszystkie cztery pakiety: lang, http-statuses, attributes i actions. Według raportu Aikido skompromitowano 233 wersje, a zdaniem Socket dotkniętych mogło być nawet około 700 historycznych wydań. Ważne, że pakiety Laravel Lang są pakietami firm trzecich, nie zaś oficjalną częścią projektu Laravel – jednak są szeroko stosowane w społeczności.
Co robiło złośliwe oprogramowanie?
Gdy programista instalował pakiet przez Composera, pobierał zmodyfikowany plik src/helpers.php, który był automatycznie ładowany. Pełnił on rolę tzw. droppera – pobierał z serwera attacker controlled (flipboxstudio[.]info) właściwy ładunek. Ten ładunek to wieloplatformowy kradzież poświadczeń (credential-stealer) napisany w PHP, działający na systemach Linux, macOS i Windows. Złośliwe oprogramowanie polowało na:
- poświadczenia chmurowe (AWS, GCP, Azure),
- sekrety Kubernetes, tokeny Vault,
- klucze SSH, dane z przeglądarek (w tym klucze App-Bound Encryption),
- portfele kryptowalut, menedżery haseł, konfiguracje VPN,
- lokalne pliki .env z bazami danych i kluczami API.
Na komputerach z systemem Windows dodatkowo uruchamiany był plik wykonywalny o nazwie DebugElevator, który atakował przeglądarki Chrome, Brave i Edge, by wykraść zapisane hasła. Badacze znaleźli w pliku PDB ślady sugerujące, że do stworzenia tego komponentu mogło zostać użyte AI (nazwa „claude” oraz „Mero” – nazwa konta Windows autora). Zebrane dane były szyfrowane i wysyłane do serwera C2.
Reakcja i praktyczne kroki obronne
Po zgłoszeniu incydentu do Packagist (głównego repozytorium pakietów PHP), administratorzy szybko usunęli złośliwe wersje i czasowo wycofali dotknięte pakiety, by uniemożliwić dalsze instalacje. Dla zespołów developerskich, które używały pakietów Laravel Lang, eksperci zalecają kilka natychmiastowych działań:
- Sprawdź zainstalowane wersje pakietów – upewnij się, że pochodzą one z zaufanego źródła i nie zawierają podejrzanych plików helpers.php.
- Zrotuj wszystkie sekrety i poświadczenia – zwłaszcza te przechowywane w plikach .env, ponieważ mogły zostać wykradzione.
- Przeskanuj systemy pod kątem połączeń z domeną flipboxstudio[.]info i usuń wszelkie ślady infekcji.
- Zweryfikuj integralność repozytoriów – sprawdź, czy tagi w forkowanych projektach nie wskazują na nieoczekiwane commity.
Lekcja na przyszłość
Incydent z pakietami Laravel Lang pokazuje, że zagrożenie dla łańcucha dostaw oprogramowania nie ogranicza się do dużych, oficjalnych projektów. Nawet popularne pakiety firm trzecich mogą stać się celem, jeśli mechanizmy uwierzytelniania i kontroli tagów w systemach takich jak GitHub nie są odpowiednio chronione. Dla polskich firm i programistów oznacza to konieczność wdrożenia bardziej rygorystycznych praktyk: używania blokad plików (np. composer.lock), weryfikacji sum kontrolnych pakietów oraz ograniczania zaufania do zewnętrznych repozytoriów. Ataki tego typu będą prawdopodobnie coraz częstsze, dlatego warto śledzić komunikaty od dostawców bezpieczeństwa i reagować szybciej niż kiedykolwiek.
