Laravel baru saja menutup celah keamanan paling serius tahun ini. Sebuah authentication bypass di komponen bawaan TokenGuard memungkinkan penyerang masuk sebagai pengguna lain tanpa mengetahui token API korban — bahkan tanpa punya akun sama sekali. Skornya CVSS 9.2 (Critical), dan kode eksploitasi (PoC) sudah beredar publik.

Kabar baiknya: perbaikannya sederhana, cukup satu perintah composer. Kabar buruknya: aplikasi yang masih memakai guard token di atas MySQL/MariaDB dan belum diperbarui sejak 25 Agustus 2026 berisiko diambil alih.

Apa yang sebenarnya terjadi

TokenGuard adalah kelas di balik driver token — guard API klasik sebelum era Sanctum. Cara kerjanya sederhana: ambil nilai token dari request, lalu cari user yang kolom token-nya cocok.

Masalahnya ada di pengecekan awal. Sebelum patch, guard hanya memastikan token tidak kosong, tanpa memastikan nilainya berupa string:

if (! empty($token)) {
    return $this->provider->retrieveByCredentials([...]);
}

Penyerang bisa mengirim nilai non-string — misalnya sebuah array — lewat body JSON. Nilai itu lolos pengecekan, lalu diteruskan ke query database. Di MySQL/MariaDB, perbandingan kolom teks dengan nilai numerik membuat token yang tidak diawali angka dikonversi menjadi 0. Hasilnya: query mencocokkan user yang salah, dan request dianggap terautentikasi sebagai user tersebut.

Perhatikan dua syarat agar serangan ini berhasil:

• Aplikasi memakai guard dengan 'driver' => 'token' di config/auth.php
• Data user disimpan di MySQL atau MariaDB (perilaku konversi tipe inilah yang menjadi inti celah)

Jika cocok, dampaknya adalah account takeover pada semua route yang dilindungi guard tersebut. Bila user yang berhasil dicocokkan adalah administrator, seluruh aplikasi berada di tangan penyerang.

Yang tidak terdampak: aplikasi yang memakai Sanctum, Passport, atau login session biasa. Sanctum dan Passport mendaftarkan driver guard sendiri, jadi tidak melewati jalur kode yang rentan ini.

Versi yang terdampak dan versi perbaikan

• Laravel 12.x sebelum 12.68.0 — terdampak
• Laravel 13.x sebelum 13.29.0 — terdampak
• Laravel 11.x sebelum 11.56.1 — menurut penulis PoC juga terdampak; 11.56.1 sudah memuat perbaikan
• Laravel 10.x — tidak menerima patch resmi, sudah lewat masa dukungan

Perbaikannya sendiri sudah dirilis 25 Agustus 2026 (commit 24 Agustus), tetapi advisory-nya baru dipublikasikan 19 Oktober 2026. Artinya aplikasi yang rutin composer update kemungkinan sudah aman tanpa sadar.

Cek apakah aplikasi Anda terdampak

Langkah pertama, lihat konfigurasi guard:

grep -n "driver" config/auth.php

Cari blok seperti ini:

'guards' => [
    'api' => [
        'driver' => 'token',
        'provider' => 'users',
    ],
],

Kalau tidak ada guard dengan driver token, aplikasi Anda tidak terkena celah ini — tapi tetap disarankan memperbarui framework.

Langkah kedua, cek versi terpasang:

composer show laravel/framework | grep -i versions

Langkah ketiga, bandingkan seluruh dependency dengan advisory resmi:

composer audit

Cara menambal

Untuk Laravel 12 dan 13, cukup naikkan paket framework:

composer update laravel/framework --with-all-dependencies
composer show laravel/framework | grep -i versions
php artisan optimize:clear
php artisan config:cache
php artisan route:cache

Pastikan versi yang terpasang 12.68.0 atau lebih tinggi (jalur 12.x) atau 13.29.0 atau lebih tinggi (jalur 13.x). Setelah itu restart worker: PHP-FPM, queue worker, dan Octane bila dipakai. Tanpa restart, proses lama masih memuat kode yang rentan.

Untuk Laravel 11, arahkan ke 11.56.1. Untuk Laravel 10 ke bawah, perbaikan resmi tidak tersedia — pilihannya memperbarui framework atau memasang mitigasi sementara di bawah ini.

Mitigasi sementara bila belum bisa update hari ini

Inti perbaikannya kecil: TokenGuard sekarang menolak token yang bukan string. Anda bisa meniru pengecekan itu lewat middleware yang dijalankan sebelum guard:

<?php
// app/Http/Middleware/RejectNonStringApiToken.php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class RejectNonStringApiToken
{
    public function handle(Request $request, Closure $next)
    {
        // Sesuaikan input_key bila Anda mengubahnya dari default.
        $token = $request->input('api_token');

        if ($token !== null && ! is_string($token)) {
            abort(401);
        }

        return $next($request);
    }
}

Daftarkan middleware tersebut agar berjalan sebelum auth:api pada route yang memakai guard token. Ini hanya penambal sementara — update framework tetap wajib.

Bila mencurigai sudah ada yang masuk

• Periksa log akses untuk request sukses (2xx) ke route API bertoken dengan nilai token yang tidak wajar (array, angka, atau kosong)
• Audit kolom api_token di tabel user: token yang tidak pernah dibuat, atau duplikat
• Rotasi seluruh API token dan paksa login ulang bila ada indikasi penyalahgunaan
• Periksa perubahan data atau akun administrator yang tidak Anda lakukan

Sejauh pemantauan publik, belum ada laporan eksploitasi aktif di lapangan dan skor EPSS masih rendah (sekitar 0,4%). Namun karena PoC sudah terbuka dan celahnya mudah dijalankan, jangan menunda pembaruan.

Bonus: celah kedua di rilis yang sama

Pada tanggal yang sama Laravel juga memperbaiki GHSA-5wcm-3v2w-8362 (CVSS 6.5, medium) pada fitur JSON:API resources yang diperkenalkan di Laravel 12.45. Dalam kondisi tertentu, request ke endpoint read-only bisa memicu operasi destruktif pada tabel relasi — pengguna dengan hak baca saja berpotensi mengosongkan tabel terkait. Perbaikannya ada di 12.68.0 dan 13.27.0, jadi ikut tertutup oleh pembaruan di atas.

Pelajaran yang bisa dibawa ke proyek lain: validasi tipe data bukan formalitas. Sebuah nilai yang "tidak kosong" belum tentu aman dipakai sebagai kunci pencarian di database.

Sumber:

• Laravel News — Critical Token Guard Auth Bypass Fixed in Laravel 13.29 and 12.68
• GitHub Security Advisory — GHSA-f9x3-7vq9-cph6
• SecurityOnline — PoC publik untuk CVE-2026-114509
• Rapid7 — CVE-2026-114509