Satu pagi, ponsel pemilik toko berbunyi. Pesan dari developer websitenya: "Pak, ada update keamanan dari framework. Dipasang sekarang atau besok?" (Ini skenario ilustrasi, bukan cerita klien mana pun.)

Jawaban yang paling sering muncul ada dua: "yang aman saja" atau "nanti dulu, lagi ramai pesanan". Dua-duanya menunjukkan masalah yang sama. Keputusan update dibuat saat ada pesan masuk, bukan lewat jadwal yang sudah disepakati.

Oktober 2026 memberi contoh bagus kenapa itu penting. Celah keamanan menumpuk di PHP, Laravel, dan Node.js dalam hitungan hari. Artikel ini fokus ke satu yang belum banyak dibahas: Laravel.

Apa yang terjadi di Laravel

Laravel adalah framework PHP yang dipakai banyak website dan aplikasi bisnis. Pada 19 Oktober 2026, tim Laravel menerbitkan advisory keamanan untuk CVE-2026-114509, dengan tingkat kritis dan skor 9,2 dari 10 (CVSS 4.0). Inti masalahnya ada di TokenGuard, fitur bawaan untuk mengamankan API dengan token. Penyerang tanpa login bisa masuk sebagai pengguna yang sudah ada, di rute mana pun yang dilindungi guard itu.

Versi yang terdampak: semua di bawah 12.68.0, dan seri 13 yang di bawah 13.29.0. Celahnya dilaporkan terjadi pada konfigurasi MySQL atau MariaDB.

Garis waktu celah Laravel: perbaikan rilis 25 Agustus, advisory terbit 19 Oktober, CVE tercatat 21 Oktober, kode percobaan beredar 22 Oktober

Perhatikan tanggalnya. Perbaikan di Laravel 12.68.0 dan 13.29.0 sudah dirilis sejak 25 Agustus. Advisory baru terbit hampir dua bulan kemudian. Website yang rutin diperbarui sejak akhir Agustus sudah aman dari celah ini jauh sebelum beritanya ramai. Yang baru kelabakan adalah yang menunggu ada berita dulu.

Menurut analisis Ostorlab, kode percobaan (proof of concept) sudah terbuka sejak 22 Oktober. Per 24 Oktober, mereka belum mencatat serangan di lapangan, dan celah ini belum masuk daftar CISA KEV. Status itu bisa berubah cepat, jadi jangan dijadikan alasan menunda.

Bagaimana celahnya bekerja

Tanpa kode: guard hanya memeriksa apakah token tidak kosong. Kalau penyerang mengirim token berbentuk daftar, misalnya berisi angka 0, pemeriksaan itu lolos. Lalu database ikut berperan. MySQL dan MariaDB mengubah teks menjadi angka saat membandingkan, dan teks yang diawali huruf dibaca sebagai 0. Hasilnya, token palsu itu cocok dengan seorang pengguna. Menurut Ostorlab, yang cocok adalah pengguna pertama yang ditemukan, sering kali admin.

Empat langkah celah: kirim token janggal, lolos pemeriksaan, database salah baca, akun cocok

Tidak semua website Laravel otomatis kena. Syaratnya: ada guard dengan driver token, ada rute yang memakainya, dan databasenya MySQL atau MariaDB. Menurut analisis publik, PostgreSQL dan SQLite tidak menunjukkan perilaku yang sama. Satu advisory lain, CVE-2026-114508 (tingkat sedang, skor 6,5), diperbaiki oleh update yang sama.

Bukan cuma Laravel

Pada pekan yang sama, 21 Oktober, PHP merilis patch darurat untuk dua celah yang dijuluki PHP2Shell (CVE-2026-109618 dan CVE-2026-109619). Keduanya memungkinkan eksekusi kode dari jarak jauh tanpa login. Versi aman: PHP 8.2.35, 8.3.36, 8.4.27, dan 8.5.12. Menurut BleepingComputer, CTO Cloudflare menyebut serangan awal sudah terlihat sebelum patch keluar.

Di hari yang sama, Node.js menutup 10 celah, empat di antaranya tingkat tinggi, lewat versi 22.23.4, 24.22.1, dan 26.12.1. Salah satunya celah di decoder Brotli yang bisa berujung eksekusi kode.

Tiga lapis website: framework, bahasa pemrograman dan runtime, serta server dan database

Satu website punya beberapa lapis, dan tiap lapis punya jadwal rilisnya sendiri. Kalau developer cuma memantau satu, lapis lain bisa tertinggal berbulan-bulan.

Patch itu rutinitas, bukan reaksi

Reaksi saat berita ramai punya dua cacat. Yang pertama, update dipasang terburu-buru tanpa diuji, lalu website malah error. Yang kedua, update ditunda karena sedang sibuk, lalu lupa. Jadwal tetap menghindari keduanya: pantau rilis, uji di salinan website, pasang di jam sepi, catat versi dan tanggalnya. Cukup sekali sebulan untuk update rutin.

Ada satu catatan jujur. Celah Laravel ini beruntung karena perbaikannya sudah menunggu dua bulan. Celah PHP2Shell tidak: serangan mulai sebelum patch ada. Karena itu jadwal bulanan perlu dilengkapi jalur darurat, yaitu aturan yang disepakati di awal tentang celah apa yang boleh dipasang di hari yang sama.

Lima pertanyaan untuk developer

Kalau websitemu dibuatkan pihak lain, kamu tidak perlu membaca kode. Cukup minta jawaban tertulis untuk hal berikut:

  1. Versi Laravel (dan PHP) yang dipakai sekarang, dan tanggal update terakhir.
  2. Apakah ada guard dengan driver token di konfigurasi auth, dan rute mana yang memakainya.
  3. Apakah databasenya MySQL atau MariaDB.
  4. Apakah log sudah dicek untuk permintaan dengan api_token berbentuk daftar (array).
  5. Apakah ada backup yang bisa dipulihkan sebelum update dipasang.
Tujuh hal yang bisa ditanyakan ke developer: versi, guard token, rute, database, log, tanggal update, backup

Developer biasanya mengecek ini lewat perintah seperti `composer show laravel/framework` dan `php artisan config:show auth`. Kalau update belum bisa dipasang hari ini, ada pengaman sementara: middleware yang menolak api_token bukan teks, atau aturan WAF yang memblokirnya. Itu cuma penahan, bukan pengganti update.

Satu hal lagi. Kalau websitemu masih berjalan di Laravel 11 atau lebih lama, advisory ini tidak mencantumkan versi perbaikan untuknya, dan dukungan keamanan Laravel 11 menurut Convika sudah berakhir 12 Maret 2026. Itu alasan untuk membicarakan upgrade versi, bukan sekadar patch.

Kalau mau dicek bareng

XETUP membangun dan merawat sistem untuk bisnis. Kalau kamu ingin cek cepat kondisi websitemu, versi yang jalan, dan jadwal updatenya, chat saja lewat WhatsApp di +62 823 1499 5005 atau cek xetup.id. Tidak perlu mengganti siapa yang mengelola website kamu.