Kembali ke Blog

Laravel TokenGuard Auth Bypass: Besok Saya Harus Patch Semua Website Terdampak

Advisory Laravel TokenGuard membuat saya harus mengecek ulang Frendi.web.id, QuickInv, dan website client lain. Artikel ini menceritakan apa yang terjadi, mengapa credential non-string dapat berbahaya, dan langkah mitigasi yang perlu dilakukan segera.

•
Frendi Triarista
L

Malam Ini Bukan Cuma Satu Server yang Harus Dipatch

Setelah membaca advisory terbaru Laravel tentang authentication bypass, saya langsung melakukan pengecekan ke beberapa aplikasi yang saya kelola. Hasilnya membuat pekerjaan besok berubah menjadi agenda patching darurat: website Frendi.web.id dan QuickInv juga masuk daftar yang harus segera diperiksa dan dipatch.

Bukan karena semua aplikasi Laravel otomatis rentan. Masalahnya bergantung pada guard autentikasi yang digunakan, cara aplikasi menerima credential, konfigurasi database, dan route yang dilindungi. Tetapi untuk aplikasi production yang menangani data dan akses user, saya tidak mau menunggu sampai ada bukti eksploitasi baru mulai bertindak.

Kerentanan yang sedang dibahas

Advisory utama ini tercatat sebagai CVE-2026-114509 dan GHSA-f9x3-7vq9-cph6. Severity-nya Critical dengan CVSS 4.0 sebesar 9.2.

Laravel TokenGuard dapat mengalami authentication bypass pada kondisi tertentu. Attacker yang belum login dapat mengirim credential API dengan tipe non-string yang dibuat secara khusus. Jika input tersebut masuk ke proses lookup user dan diperlakukan tidak sesuai, query database dapat mencocokkan record yang tidak semestinya.

Akibatnya, request yang seharusnya gagal dapat dianggap berasal dari user lain. Dampaknya dapat mencakup account takeover, akses ke endpoint API, pembacaan data, atau perubahan data sesuai privilege user yang keliru terpilih.

Mengapa bisa terjadi?

Akar masalahnya bukan sekadar token yang lemah. Ada kombinasi beberapa kondisi:

  1. Aplikasi memakai guard API berbasis TokenGuard.
  2. Credential tidak dipastikan sebagai string tunggal.
  3. Input array, object, atau tipe lain dapat masuk ke proses authentication lookup.
  4. MySQL atau MariaDB dapat melakukan perbandingan dan coercion yang menghasilkan match tidak terduga.
  5. Route hanya memeriksa apakah user sudah terautentikasi tanpa authorization berlapis.

Di sinilah saya melihat pentingnya membedakan authentication dan authorization. Authentication menjawab siapa pemanggilnya. Authorization menentukan data dan aksi apa yang boleh dilakukan.

Apa yang saya temukan saat melakukan pengecekan?

Saat saya mengecek website yang saya kelola, Frendi.web.id dan QuickInv sama-sama perlu masuk ke pekerjaan patching. Saya tidak akan menunggu pekerjaan ini selesai hanya karena website masih terlihat normal atau endpoint publik masih merespons HTTP 200.

Celah autentikasi tidak selalu terlihat dari halaman utama. Website dapat tampak sehat, sementara route API, guard, atau dependency framework masih berada pada versi yang belum menerima patch.

Besok saya harus kembali begadang untuk membereskan semua website client yang terdampak. Pekerjaannya bukan hanya mengganti nomor versi. Saya perlu memastikan dependency dapat di-resolve, membuat backup, menguji route authentication, me-restart worker, dan memeriksa log setelah deployment.

Versi yang perlu diperiksa

Advisory Laravel framework menyebut versi terdampak:

Laravel 12.x sebelum 12.68.0
Laravel 13.x sebelum 13.29.0

Versi patched minimum:

Laravel 12.68.0
Laravel 13.29.0

Karena ada advisory Laravel lain pada periode yang sama, termasuk unauthorized data destruction dan XSS pada debug page, saya tidak akan berhenti pada patch minimum TokenGuard. Versi target harus mengikuti branch yang didukung dan seluruh advisory terkait.

Mitigasi yang saya lakukan

Upgrade framework

Saya akan memperbarui laravel/framework menggunakan dependency resolution Composer yang terkontrol, bukan mengganti file vendor secara manual.

Sebelum update:

  • backup .env, composer.json, dan composer.lock;
  • backup database;
  • cek package yang menahan versi framework;
  • simulasikan resolusi dependency di staging;
  • siapkan rollback ke lockfile dan artifact sebelumnya.

Audit guard dan route

Saya perlu menginventarisasi semua route yang memakai:

auth:api
auth:sanctum
TokenGuard

Lalu memeriksa apakah route sensitif sudah memiliki policy, gate, ownership check, tenant boundary, dan ability atau scope yang sesuai.

Tolak credential dengan tipe tidak sesuai

Credential API harus diterima sebagai string tunggal. Array, object, nilai kosong, dan format aneh harus ditolak sebelum masuk ke user lookup.

Jangan mengubah input terstruktur menjadi string secara diam-diam. Normalisasi seperti itu bisa menyembunyikan pola request yang seharusnya dianggap invalid.

Periksa konfigurasi database

Saya juga perlu memeriksa query authentication, tipe kolom token, index, dan perilaku perbandingan pada MySQL atau MariaDB. Test harus mencakup token string valid, token salah, array, object, nilai numerik, dan nested input.

Restart dan verifikasi

Setelah patch, pekerjaan belum selesai. Saya harus me-restart PHP-FPM, queue worker, scheduler, dan service Laravel yang masih memuat dependency lama.

Verifikasi minimum:

composer show laravel/framework
php artisan about --no-ansi
php artisan route:list --no-ansi

Lalu saya perlu menguji token valid, token salah, credential non-string, authorization tanpa ability, rate limit, audit log, endpoint publik, dan health check aplikasi.

Mitigasi sementara

Jika deployment harus menunggu maintenance window, beberapa langkah dapat mengurangi risiko:

  • nonaktifkan guard token standar yang tidak diperlukan;
  • batasi endpoint API terdampak melalui gateway atau allowlist;
  • tolak credential non-string di middleware;
  • perketat rate limit;
  • monitor request authentication yang tidak lazim;
  • tambahkan authorization check pada route sensitif;
  • prioritaskan patch secepat mungkin.

Ini hanya mitigasi sementara. Patch dependency tetap diperlukan.

Jangan lupa advisory terkait

Aplikasi yang memakai Laravel Passport juga perlu memeriksa advisory GHSA-349c-2h2f-mxf6 terkait client_credentials token yang dapat dipetakan ke user yang tidak terkait pada kondisi tertentu. Versi Passport patched yang disebut advisory adalah 13.7.1.

Selain itu, production wajib memastikan:

APP_DEBUG=false

Debug page XSS dan informasi sensitif tidak boleh terbuka di lingkungan production.

Penutup

Pelajaran dari advisory ini sederhana, tetapi sering terlambat dilakukan: patch management harus mencakup framework, runtime, guard, database, worker, dan konfigurasi deployment.

Malam ini saya sudah tahu bahwa pekerjaan besok bukan hanya memperbarui satu aplikasi. Frendi.web.id, QuickInv, dan website client lain perlu diperiksa satu per satu. Lebih baik begadang untuk patching dan verifikasi sekarang daripada menjelaskan kepada client mengapa account atau data mereka bisa diakses melalui jalur yang seharusnya tertutup.

Referensi

  1. GitHub Laravel Framework, Token-based API guard Auth Bypass, GHSA-f9x3-7vq9-cph6: https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6
  2. OSV, CVE-2026-114509, Laravel TokenGuard authentication bypass: https://osv.dev/vulnerability/GHSA-f9x3-7vq9-cph6
  3. GitHub Laravel Passport, TokenGuard Authenticates Unrelated User for Client Credentials Tokens, GHSA-349c-2h2f-mxf6: https://github.com/laravel/passport/security/advisories/GHSA-349c-2h2f-mxf6
  4. Laravel framework security advisories: https://github.com/laravel/framework/security/advisories

Tanggal publish sumber: 19 October 2026