Serangan supply chain Laravel Lang menjadi peringatan penting bagi developer PHP dan Laravel. Dalam insiden ini, beberapa paket Laravel Lang yang biasa digunakan untuk kebutuhan bahasa dan translasi disusupi malware pencuri kredensial.

Kasus ini berbahaya karena serangannya tidak terjadi seperti bug biasa pada aplikasi. Penyerang tidak hanya mencari celah pada website. Mereka menyerang jalur distribusi software, yaitu proses saat package dirilis, diberi versi, lalu diinstall oleh developer melalui Composer.

Akibatnya, sebuah package bisa terlihat normal saat diinstall. Namun di balik itu, ada kode jahat yang berjalan diam diam ketika aplikasi memuat autoloader Composer.

Apa yang Terjadi pada Serangan Supply Chain Laravel Lang

Paket yang terdampak berasal dari ekosistem Laravel Lang. Paket seperti ini biasanya dipakai untuk kebutuhan localization, misalnya terjemahan pesan validasi, status HTTP, nama atribut, dan teks lain yang dipakai dalam aplikasi Laravel.

Beberapa paket yang disebut dalam laporan adalah laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, dan laravel-lang/actions. Paket ini bukan bagian resmi dari Laravel framework, tetapi cukup dikenal dan banyak digunakan oleh komunitas Laravel.

Berdasarkan laporan keamanan, penyerang tidak hanya membuat satu versi baru yang berisi malware. Mereka justru menulis ulang git tag yang sudah ada dan mengarahkannya ke commit berbahaya. Inilah yang membuat kasus ini lebih licin.

Bagi developer, versi package bisa terlihat seperti versi lama yang aman. Namun saat Composer mengambil package tersebut, isinya bisa mengarah ke kode yang sudah disusupi.

Beberapa peneliti keamanan menyebut ada ratusan versi historis yang terdampak. Laporan terbaru menyebut jumlahnya mencapai lebih dari 700 versi di beberapa package Laravel Lang.

Kenapa Serangan Ini Berbahaya

Bagian paling berbahaya dari serangan supply chain Laravel Lang adalah cara malware berjalan.

Penyerang menambahkan file bernama src/helpers.php. File ini kemudian didaftarkan di composer.json melalui bagian autoload.files. Dalam Composer, file yang dimasukkan ke autoload.files akan otomatis dimuat saat aplikasi menjalankan autoloader.

Artinya, developer tidak perlu memanggil fungsi tertentu agar malware berjalan. Tidak perlu ada tombol yang diklik. Tidak perlu ada aksi khusus dari user. Saat aplikasi memulai proses normal dan memuat vendor/autoload.php, file jahat itu bisa ikut aktif.

Bagi aplikasi Laravel, Symfony, atau aplikasi PHP lain, memuat Composer autoloader adalah hal yang sangat umum. Karena itulah serangan ini bisa berjalan tanpa terlihat mencurigakan di awal.

Data Apa yang Bisa Dicuri

Malware yang ditemukan dalam insiden ini dirancang sebagai credential stealer. Setelah berjalan, malware mencoba menghubungi domain milik penyerang, yaitu flipboxstudio[.]info, lalu mengambil payload tahap berikutnya.

Payload tersebut bisa berjalan di Linux, macOS, dan Windows. Pada Windows, malware dapat memakai launcher berbasis script. Pada Linux dan macOS, malware bisa berjalan melalui proses PHP di background.

Target pencuriannya cukup luas. Malware ini mencari kredensial cloud, token Kubernetes, token HashiCorp Vault, secret CI/CD, SSH private key, kredensial Git, environment variable, data browser, file password manager, wallet crypto, dan file konfigurasi seperti .env, wp-config.php, dan docker-compose.yml.

Bagi perusahaan, ini bukan sekadar masalah website terkena malware. Jika token cloud, kredensial database, atau secret deployment ikut bocor, dampaknya bisa masuk ke server, source code, pipeline deployment, sampai infrastruktur produksi.

Kenapa Composer Lock Perlu Dicek

Dalam kasus seperti ini, file composer.lock sangat penting karena dapat menunjukkan package apa yang pernah diinstall oleh project.

Namun, ada catatan penting. Nomor versi saja tidak selalu cukup untuk memastikan apakah sebuah sistem aman. Dalam insiden ini, beberapa tag berbahaya kemudian sudah diremediasi atau dikembalikan ke kode yang benar. Jadi, sebuah nomor versi yang terlihat aman sekarang belum tentu membuktikan bahwa sistem tidak pernah mengambil kode berbahaya saat periode kompromi terjadi.

Karena itu, developer perlu mengecek composer.lock, log build, log deployment, cache Composer, dan waktu terakhir package diinstall atau diperbarui.

Jika project pernah menjalankan composer update atau melakukan install package terdampak pada periode serangan, sistem tersebut sebaiknya dianggap mencurigakan sampai ada bukti yang jelas bahwa tidak ada eksekusi malware.

Apa yang Perlu Dicek Developer

Langkah pertama adalah mengecek composer.json dan composer.lock. Cari apakah ada package laravel-lang/lang, laravel-lang/http-statuses, laravel-lang/attributes, atau laravel-lang/actions.

Setelah itu, cek folder vendor/laravel-lang jika masih ada di server atau environment build. Perhatikan apakah ada file src/helpers.php. Cek juga apakah composer.json package tersebut memiliki autoload.files yang mengarah ke file itu.

Tim IT atau security juga perlu mengecek log DNS, proxy, firewall, dan EDR. Cari apakah ada koneksi ke flipboxstudio[.]info. Satu request saja sudah cukup untuk menjadi tanda bahwa payload mungkin pernah mencoba berjalan.

Pada Linux dan macOS, cek folder temporary untuk melihat apakah ada direktori .laravel_locale. Pada Windows, cek file VBS mencurigakan di folder temporary dan cari apakah ada file bernama DebugChromium.exe.

Apa yang Harus Dilakukan Jika Terdampak

Jika ada bukti bahwa package berbahaya pernah terinstall atau berjalan, anggap kredensial di sistem itu mungkin sudah bocor.

Langkah paling aman adalah mengisolasi host dari jaringan. Simpan log dan artefak penting untuk kebutuhan investigasi. Setelah itu, rebuild sistem dari image yang benar benar bersih. Jangan hanya menghapus file malware lalu menganggap semuanya selesai.

Rotasi kredensial harus dilakukan dengan serius. Ganti cloud key, password database, API token, SSH key, token GitHub atau GitLab, secret CI/CD, token Kubernetes, token Vault, kredensial Docker registry, Laravel APP_KEY, dan secret lain yang tersimpan di environment variable.

Jika malware berjalan di laptop developer, akun pribadi dan akun kerja juga perlu diperiksa. Browser login, session Slack atau Discord, password manager, dan wallet crypto bisa ikut menjadi target jika dapat diakses dari mesin tersebut.

Pelajaran dari Insiden Laravel Lang

Serangan supply chain Laravel Lang menunjukkan bahwa keamanan aplikasi bukan hanya tentang kode yang kita tulis sendiri. Keamanan juga bergantung pada package yang kita install, cara package itu dirilis, dan sistem otomatis yang menarik package tersebut ke project kita.

Developer perlu lebih berhati hati saat menjalankan update dependency. Composer lock harus diperiksa. Perubahan package perlu dipantau. Build environment sebaiknya memiliki akses internet yang dibatasi dan secret yang digunakan harus seminimal mungkin.

Maintainer package juga perlu memperketat keamanan akun dan proses rilis. Multi factor authentication, token yang terbatas, proteksi release, dan transparency log dapat membantu mengurangi dampak jika ada akun atau token yang dicuri.

Kesimpulan

Serangan supply chain Laravel Lang adalah contoh nyata bagaimana package yang dipercaya komunitas bisa berubah menjadi jalur pencurian kredensial ketika proses rilisnya disusupi.

Bagi tim Laravel dan PHP, pesan utamanya jelas. Dependency security harus dianggap sebagai bagian dari keamanan produksi. Cek riwayat package, periksa Composer lock, cari autoload entry yang mencurigakan, dan segera rotasi secret jika ada tanda paparan.

Update package memang terlihat seperti pekerjaan rutin. Namun dalam serangan supply chain, proses rutin itu bisa menjadi pintu masuk menuju infrastruktur yang lebih dalam.

Source: https://thehackernews.com/2026/05/laravel-lang-php-packages-compromised.html