W nocy z 22 na 23 maja 2026 roku doszło do jednego z poważniejszych w tym roku ataków na łańcuch dostaw oprogramowania w ekosystemie PHP. Celem padła organizacja Laravel-Lang, która utrzymuje zestaw bardzo popularnych pakietów z tłumaczeniami i lokalizacją dla frameworka Laravel. Napastnik nie podstawił jednej fałszywej paczki — przerobił całą historię wydań, przepisując ponad 700 istniejących tagów w czterech repozytoriach tak, by wskazywały na złośliwy kod. Każdy, kto w tym oknie czasowym instalował lub aktualizował te biblioteki przez Composera, ściągał na swój serwer rozbudowanego złodzieja poświadczeń. Sprawę nagłośniły firmy Socket, Aikido Security i StepSecurity, a serwis Packagist 23 maja zaczął usuwać złośliwe wersje i tymczasowo wycofał dotknięte pakiety.
Przepisane tagi zamiast nowych wersji
To, co odróżnia ten atak od typowego podrzucenia złośliwej paczki, to jego metoda. Atakujący nie zmienił kodu w gałęzi głównej projektu. Zamiast tego przepisał każdy istniejący tag Gita w repozytoriach laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes oraz laravel-lang/actions, kierując go na nowy, złośliwy commit. Wykorzystał przy tym sposób, w jaki Packagist rozwiązuje tagi z GitHuba — pozwala on, by tag wskazywał na commit pochodzący z forka tego samego repozytorium.
Skala wskazuje na automatyzację: tagi pojawiały się jeden po drugim, część zaledwie kilka sekund od siebie. Badacze podejrzewają, że napastnik zdobył dostęp do poświadczeń na poziomie całej organizacji albo do infrastruktury wydawniczej. Efekt jest groźny, bo ofiara, która „dla bezpieczeństwa” przypina w composer.json konkretną, starą i sprawdzoną wersję pakietu, wcale nie jest chroniona — ten sam numer wersji wskazywał już bowiem na zatruty kod.
helpers.php, czyli kod uruchamiany przy każdym żądaniu
Złośliwa logika trafiła do pliku src/helpers.php, który atakujący dopisał do sekcji autoload.files w pliku composer.json każdego pakietu. To kluczowy szczegół. Każda aplikacja Laravela wykonuje na starcie require vendor/autoload.php, podobnie robi Symfony, PHPUnit i większość innych narzędzi PHP. Dzięki temu kod uruchamiał się sam, przy każdym żądaniu HTTP obsługiwanym przez zainfekowaną aplikację — bez tworzenia obiektu, bez wywołania metody, bez żadnego dodatkowego wyzwalacza.
Plik helpers.php najpierw tworzył unikalny dla danego hosta znacznik (skrót MD5 łączący ścieżkę katalogu, architekturę systemu i numer inode), aby payload odpalił się tylko raz na maszynę i nie zdradzał się powtarzającą aktywnością. Następnie łączył się z serwerem flipboxstudio[.]info i pobierał właściwy ładunek — wieloplatformowy stealer napisany w PHP, działający na Windowsie, Linuksie i macOS. Na Windowsie uruchamiał go skrypt VBS przez cscript, na pozostałych systemach przez funkcję exec().
Co kradł payload
Pobierany ładunek to według analizy Aikido około 5900 linii kodu PHP rozbitych na piętnaście wyspecjalizowanych modułów. Zakres tego, co wykradał, jest wyjątkowo szeroki: dane uwierzytelniające do chmur (AWS, Google Cloud, Azure, DigitalOcean, Heroku, Vercel, Netlify), tokeny i konfiguracje systemów CI/CD (GitHub Actions, GitLab Runner, Jenkins, CircleCI, ArgoCD), tokeny HashiCorp Vault i sekrety Kubernetes, klucze SSH, pliki .env, wp-config.php i docker-compose.yml, dane logowania z menedżerów haseł (1Password, Bitwarden, LastPass, KeePass), historię i ciasteczka przeglądarek, tokeny sesji Discorda, Slacka i Telegrama, a także frazy odzyskiwania portfeli kryptowalut. Zebrane dane były szyfrowane algorytmem AES-256 i wysyłane na ten sam serwer, po czym stealer kasował się z dysku, by utrudnić analizę powłamaniową.
Co powinien zrobić deweloper i administrator
Najpilniejsza sprawa to ustalenie, czy między 22 a 23 maja na serwerze lub w pipelinie CI/CD wykonywało się composer install albo composer update z udziałem pakietów laravel-lang. Jeśli tak, należy traktować maszynę jak skompromitowaną — odśwież zależności do czystych wersji, ale przede wszystkim unieważnij i wygeneruj na nowo wszystkie poświadczenia, do których proces PHP miał dostęp: klucze API chmury, tokeny CI/CD, klucze SSH, hasła z plików .env i sekrety Vaulta.
Warto też wpisać domenę flipboxstudio[.]info na listę blokowanych w firewallu i sprawdzić logi sieciowe pod kątem połączeń do niej. Na przyszłość: stosuj plik composer.lock i weryfikuj sumy kontrolne zależności, a w środowiskach CI/CD ogranicz zakres tokenów do minimum i rozważ skanery łańcucha dostaw, które wychwytują podejrzane wpisy w autoload.files. Pamiętaj, że samo przypięcie konkretnej wersji w tym ataku nie pomogło — bezpieczeństwo daje dopiero zablokowany, zweryfikowany skrót commita.
Podsumowanie
Atak na Laravel-Lang to przypomnienie, że zależność, której nikt nie rusza od lat, wcale nie jest bezpieczna. Napastnik nie musiał przekonać nikogo do instalacji nowej paczki — wystarczyło, że przejął proces wydawniczy i przepisał historię. Dla świata PHP, w którym Composer i autoload to fundament każdego projektu, jeden dopisany plik w autoload.files oznaczał wykonanie obcego kodu przy każdym żądaniu. Jeśli korzystasz z bibliotek laravel-lang, dzisiaj jest dobry dzień, by sprawdzić daty ostatnich instalacji zależności i — w razie wątpliwości — zrotować klucze. W łańcuchu dostaw oprogramowania zaufanie nie jest stanem, który raz się ustala; trzeba je weryfikować przy każdym buildzie.
źródło: https://thehackernews.com/2026/05/laravel-lang-php-packages-compromised.html