InvoiceShelf merilis patch untuk CVE-2026-55610, sebuah celah kritis yang memungkinkan pemilik di satu perusahaan membajak akun pengguna di perusahaan lain. Kerentanan ini, dengan skor 8,7 pada skala CVSS, berasal dari kurangnya pemeriksaan cakupan tenant (tenant-scope check) dalam kode Laravel aplikasi tersebut.

Cara Kerja Celah Tersebut

InvoiceShelf adalah alat SaaS yang dibangun di atas Laravel yang memungkinkan perusahaan mengelola pengguna, faktur, dan pengaturan dari satu dasbor tunggal. Platform ini membaca header khusus untuk mengidentifikasi tenant. Saat seorang Owner meminta catatan pengguna, kode tersebut hanya memeriksa, “Apakah peminta adalah seorang Owner dari perusahaannya sendiri?”

Kode tersebut tidak pernah memverifikasi apakah pengguna target termasuk dalam tenant yang sama. Route-model binding implisit milik Laravel memecahkan user ID menjadi baris dalam tabel pengguna global, dan kebijakan otorisasi menyetujui permintaan tersebut semata-mata berdasarkan peran peminta.

Oleh karena itu, penyerang dapat:

  • Menyertakan ID pengguna numerik apa pun dalam URL permintaan.
  • Menerima catatan pengguna lengkap, termasuk email.
  • Melakukan pembaruan yang menimpa email, kata sandi korban, dan bahkan menetapkan kembali akun tersebut ke perusahaan penyerang sebagai super-admin.

Dalam praktiknya, seorang Owner yang berniat jahat mengubah alat manajemen perusahaan menjadi senjata pengambilalihan akun universal. Tidak diperlukan hak istimewa lebih dari sekadar “Owner”.

Siapa yang Terdampak

Setiap pelanggan InvoiceShelf yang menjalankan versi sebelum 2.4.1 terpapar risiko. Karena celah ini berada di jalur penanganan permintaan inti, tenant mana pun dapat menjadi target oleh Owner dari tenant lainnya, terlepas dari ukuran atau postur keamanan mereka. Dampaknya mencakup hilangnya kerahasiaan (alamat email) dan hilangnya integritas (perubahan kata sandi tanpa izin, eskalasi ke super-admin).

Patch Tersebut

Pengembang merilis versi 2.4.1, dengan menambahkan pemeriksaan tenant secara eksplisit sebelum operasi baca atau tulis apa pun pada catatan pengguna. Perbaikan ini membatasi cakupan kueri ke pengenal perusahaan yang aktif, memaksa Laravel untuk hanya mengembalikan baris yang termasuk dalam tenant peminta.

Apa yang Harus Dipelajari Pengembang

  • Jangan pernah mengandalkan primary key global dalam aplikasi multi-tenant.
  • Terapkan filter tenant pada setiap pencarian database, bukan hanya pada tindakan hapus atau buat.
  • Pastikan kebijakan otorisasi memvalidasi peran aktor dan kepemilikan tenant dari objek target.
  • Anggap fitur framework implisit seperti route-model binding sebagai kemudahan yang dapat menyembunyikan celah keamanan kecuali Anda menambahkan pembatasan cakupan (scoping) secara eksplisit.

Menatap ke Depan

Insiden ini menunjukkan risiko yang lebih luas bagi SaaS apa pun yang berbagi tabel. Audit keamanan harus meninjau semua endpoint yang menerima pengenal dan memastikan bahwa pembatasan cakupan tenant diterapkan secara seragam.

Kesimpulan: satu pemeriksaan tenant yang terlewat dapat mengubah peran pengguna yang memiliki hak istimewa menjadi backdoor universal. Pembatasan cakupan (scoping) yang tepat bukanlah pilihan; itu adalah fondasi isolasi data dalam sistem multi-tenant apa pun.