MaxKB Memasang Shell Tool pada Setiap Asisten yang Mendukung Tool dan Tidak Pernah Membatasi Aksesnya

MaxKB, platform asisten perusahaan open-source yang diterbitkan di bawah organisasi GitHub 1Panel-dev, membangun agen chat-nya di atas framework yang secara diam-diam menambahkan alat shell setiap kali backend yang mendukung shell diberikan — dan MaxKB tidak pernah menghapus alat tersebut atau meminta siapa pun menyetujui penggunaannya. Cacat ini adalah CVE-2026-77521, yang diterbitkan sebagai advisory GitHub GHSA-f36j-f34j-h3rx pada 2 September 2026 dan diberi skor 10,0 dari 10 berdasarkan CVSS 3.1 untuk kasus asisten publik atau tertanam. Lasso Security, yang menemukan dan melaporkannya, menunjukkan bahwa sebuah pesan chat — atau teks yang hanya diingesti oleh asisten melalui retrieval atau dokumen yang diunggah — dapat mendorong model untuk menjalankan perintah: pada deployment bare-metal langsung di host, dan pada container resmi melalui wrapper yang menurut para peneliti dapat dilewati dengan titik koma. Tidak ada sumber yang dikutip mencatat cacat tersebut dieksploitasi di alam liar. Tingkat keparahan, penilaian keyakinan, dan daftar sumber milik catatan itu sendiri berada di arsip insiden AI, bersama entri MaxKB dan agent-tooling di sekitarnya dari batch pengungkapan yang sama.

MaxKB adalah produk self-hosted untuk membangun asisten yang diperkaya dengan retrieval: operator membuat asisten, melampirkan kemampuan padanya — alat, server Model Context Protocol, keterampilan, sub-aplikasi — menghubungkan basis pengetahuan yang dibangun dari dokumen yang diunggah atau situs web yang dirayapi, lalu mengekspos asisten tersebut baik melalui konsol yang terautentikasi maupun sebagai widget chat publik yang dapat disematkan. Fleksibilitas itulah titik eksposurnya. Kondisi pemicu dalam advisory bukanlah konfigurasi yang tidak biasa, melainkan konfigurasi yang biasa: setiap asisten dengan setidaknya satu kemampuan terlampir merutekan chat-nya melalui jalur agen yang terdampak, sedangkan chat tanpa kemampuan terlampir tidak. Tulisan Lasso menggambarkan proyek ini sebagai salah satu yang lebih luas diadopsi dalam kategorinya, dan mencatat bahwa MaxKB biasanya diterapkan sebagai layanan multi-tenant — yang menempatkan perintah yang berjalan sebagai pengguna aplikasi di bawah model tenancy, bukan di dalam irisan milik satu tenant.

Alat shell hadir bersama framework, bukan produk

MaxKB membangun agen-agen ini dengan pustaka deepagents milik LangChain, yang dipatok ke versi 0.6.11 dalam pyproject.toml proyek pada tag yang rentan maupun tag saat ini. Dalam apps/application/flow/tools.py, pada baris 467 dari tag v2.10.3-lts, proyek memanggil create_deep_agent dengan backend diatur ke SandboxShellBackend, subkelas MaxKB yang menjalankan perintah di host. Menurut advisory, deepagents secara otomatis menyuntikkan serangkaian alat setiap kali backend shell diteruskan dengan cara itu: execute, ls, read_file, write_file, edit_file, glob, dan grep. Alat-alat tersebut bukan bagian dari argumen tools=list, yang hanya membawa alat milik operator, alat MCP, dan alat skill. Alat-alat tersebut tidak dapat dihapus dari antarmuka atau melalui konfigurasi.

MaxKB juga tidak meneruskan excluded_tools, argumen pustaka yang seharusnya menyingkirkannya. Advisory itu berhati-hati menjelaskan mengapa hal itu penting bahkan sebagai solusi: excluded_tools "menghapus alat tersebut dari apa yang diberitahukan kepada model, bukan dari eksekutor". Perbedaan antara alat yang tidak diketahui oleh model dan alat yang tidak dapat dijalankan adalah inti dari bug ini dalam bentuk mini.

Gerbang yang mencantumkan tiga alat dan menghilangkan yang keempat

Kontrol human-in-the-loop dalam panggilan yang sama itu terdiri dari satu baris, dan menyebutkan tiga operasi: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. Menulis file, membaca file, dan mengedit file disebutkan. Eksekusi perintah sama sekali tidak menjadi key dalam dictionary tersebut. Dalam tafsiran advisory itu, hal ini berarti tidak ada persetujuan yang diminta untuk execute — tiga operasi filesystem disebutkan dan secara eksplisit diatur agar tidak menginterupsi, sedangkan tool shell sama sekali tidak disebutkan.

Jika dirangkai, alurnya adalah: teks yang tidak tepercaya mencapai model, model memanggil execute, dan perintah itu dijalankan. Advisory tersebut menyebutkan dua cara teks tidak tepercaya bisa masuk. Jalur langsungnya adalah chat — widget publik atau tersemat, atau percakapan tenant lain. Jalur tidak langsungnya adalah konten yang diserap asisten: dokumen RAG, berkas yang diunggah, atau halaman web yang dirayapi platform ke dalam basis pengetahuan. Postingan Lasso membuat rute kedua menjadi konkret, dengan mengamati bahwa "kumpulan orang yang dapat menempatkan teks di depan model lebih besar daripada kumpulan orang yang dapat mengobrol dengannya".

Pada instalasi bare-metal, perintah itu hanyalah sebuah perintah

Apa pun yang dilakukan MaxKB terkait isolasi terjadi di apps/application/flow/backend/sandbox_shell.py, dan pada v2.10.3-lts hal itu dimulai dengan sebuah nilai default. Baris 9 berbunyi _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))), dan SANDBOX tidak muncul di Config.defaults dalam apps/maxkb/conf.py. Tanpa adanya pengaturan MAXKB_SANDBOX yang eksplisit, nilainya adalah nol, cabang pembungkus pada baris 65 dilewati, dan execute mencapai subprocess.run dengan shell=True langsung di host, sebagai pengguna yang menjalankan layanan — root, dalam frasa dari advisory tersebut, jika layanan dijalankan sebagai root.

Itulah konfigurasi yang digunakan para peneliti untuk proof of concept host mereka. Mereka menjalankan kode asli MaxKB dari sumber dengan MAXKB_SANDBOX tidak diatur, membuat asisten dengan satu tool terlampir, dan memintanya dalam satu pesan chat untuk menjalankan perintah informasi sistem. Tool execute terpicu dan menulis file yang isinya adalah output uname, id, dan sw_vers milik host itu sendiri — output yang, menurut catatan advisory, dikonfirmasi tidak ada di dalam container mana pun. Lasso juga mencatat batas dari apa yang menghentikannya: file proof dengan nama yang mencolok ditolak oleh model, sedangkan frasa operasional yang tampak wajar tidak. Penyelarasan model, dalam kata-kata mereka, adalah "penghambat parsial, bukan kontrol".

Pada image resmi, sandbox berjalan tetapi tetap bocor

Container resmi menetapkan MAXKB_SANDBOX=1 di image dasar, pada installer/Dockerfile-base baris 48, sehingga wrapper aktif di sana — dan wrapper adalah cacat kedua. Wrapper itu membangun satu string: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so diikuti oleh gosu sandbox lalu perintah yang disediakan model, yang diserahkan kepada shell yang berjalan sebagai root. Karena perintah itu diinterpolasi sebagai teks, hanya token pertama dari perintah tersebut yang berada di bawah gosu. Setiap titik koma, pipe, pengalihan, atau substitusi perintah dalam keluaran model dievaluasi oleh shell root luar sebelum sandbox sempat melihatnya.

Tulisan Lasso memberikan gambaran bentuk yang berfungsi: payload `env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id`, di mana `ls` dibatasi, `whoami` tidak, dan semua yang setelahnya berjalan bebas. Dalam pengujian, para peneliti menulis file milik root dengan pengalihan saat perintah dalam sandbox diblokir. Memperparah hal itu, baik `installer/Dockerfile` maupun `installer/Dockerfile-base` tidak memuat direktif `USER`, sehingga image aplikasi berjalan sebagai UID 0 — advisory melaporkan konfirmasi root saat runtime. Karena itu container tetap mengeksekusi perintah, dan sandbox hanya menentukan perintah mana yang secara kosmetik diatribusikan ke pengguna dengan hak istimewa rendah.

Alur serangan lengkap yang dijelaskan Lasso sama sekali tidak memerlukan akses ke target. Penyerang menaruh perintah di halaman web, menunggu agen korban meng-crawl-nya ke basis pengetahuan, lalu korban mengajukan pertanyaan biasa. Jawabannya kembali dengan benar dan sah; curl yang disuntikkan sudah ditembakkan ke server penyerang. Advisory tersebut mencatat bahwa para peneliti hanya menguji deployment mereka sendiri, bukan instans MaxKB pihak ketiga atau yang di-hosting.

Apa yang ditetapkan oleh sumber-sumber, dan apa yang sama sekali tidak diukur.

Mekanisme, dua mode penerapan, kredit, dan rilis perbaikan tersebut selaras di empat dokumen: advisory GitHub, catatan NVD yang diterbitkan pada 21 September 2026, tulisan teknis Lasso sendiri tanggal 10 September 2026, dan laporan GBHackers tanggal 22 September 2026, yang merupakan satu-satunya liputan media independen yang ditemukan untuk CVE ini. Tidak ada sumber yang membantah bagian mana pun dari temuan tersebut, dan arsip mencatat entri itu sebagai tidak terbantahkan pada tingkat keyakinan tertingginya.

Sumber-sumber tersebut tidak memuat ukuran paparan apa pun. Tidak ada hitungan penerapan MaxKB, tidak ada hitungan asisten yang menghadap internet atau tertanam, tidak ada hasil pemindaian, tidak ada telemetri, dan tidak ada korban yang disebutkan namanya. Tidak ada apa pun dalam catatan yang menunjukkan cacat tersebut digunakan terhadap siapa pun, dan penilaian eksploitasi CISA sendiri sependapat: blok SSVC yang dilampirkan pada catatan NVD tanggal 22 September 2026 menilai eksploitasi sebagai "poc", dapat diotomatiskan sebagai "yes", dan dampak teknis sebagai "total". Model EPSS milik FIRST menetapkan probabilitas eksploitasi dalam 30 hari berikutnya sebesar 1,05 persen, persentil ke-64, pada 27 Oktober 2026, dan CVE tersebut tidak muncul dalam katalog CISA Known Exploited Vulnerabilities bertanggal 27 Oktober 2026. Peringkat arsip itu sendiri mencerminkan bukti yang sama: severity high, real harm false.

Angka 10.0 perlu dijelaskan cakupannya, karena angka inilah yang paling mungkin dikutip di luar konteks. Ini adalah skor untuk kasus asisten publik atau tertanam, dengan vektor CVSS AV:N/AC:L/PR:N/UI:N/S:C — dapat dijangkau melalui jaringan, tanpa hak istimewa, tanpa interaksi pengguna, dengan perubahan cakupan karena perintah di dalam asisten melintasi ke sistem operasi host. Skor ini milik CNA, dan CNA di sini adalah program advisory GitHub, yang juga menjadi tujuan pengenal sumber catatan CVE. NVD memuat vektor yang sama sebagai metrik sekunder dan, per 28 Oktober 2026, mencantumkan entri tersebut dalam status "Deferred", yang berarti NVD telah menerbitkan analisis pemberi penetapan, bukan analisisnya sendiri.

Patch tersebut dirilis sebulan sebelum advisory diterbitkan.

Kronologinya berjalan mundur dari publikasi, dan itu adalah bagian catatan yang paling tidak intuitif. Lasso melaporkan cacat tersebut secara privat melalui saluran advisory GitHub pada 8 Juli 2026. MaxKB membalas keesokan harinya, membatasi laporan pada image resmi dan meminta proof of concept container; para peneliti menyediakannya bersama bypass sandbox pada 10 Juli. Sebuah commit perbaikan, 594f50f2, masuk pada 9 Juli — satu hari setelah laporan — dan menulis ulang sandbox_shell.py sehingga string perintah model diurai terlebih dahulu dan prefiks gosu diterapkan ke setiap perintah sederhana, bukan hanya ke perintah pertama, dengan setiap daftar argumen dikutip ulang sehingga substitusi tidak dapat lolos ke shell induk. Tulisan Lasso menggambarkan perubahan itu sebagai penerapan prefiks gosu "ke setiap perintah sederhana, bukan hanya yang pertama".

Rilis yang membawanya, v2.10.5-lts, diterbitkan pada 6 Agustus 2026. Advisori GitHub dipublikasikan pada 2 September, NVD menerbitkan CVE pada 21 September, blok SSVC dari CISA ditambahkan dan GBHackers melaporkannya pada 22 September, serta tulisan Lasso sendiri muncul pada 10 September — di tengah urutan itu, bukan di awal. Operator yang melacak tag rilis alih-alih feed advisori telah memiliki patch tersebut sekitar empat minggu sebelum peringatan.

Batas versi ini lebih layak diperhatikan daripada yang diberikan advisory, karena kedua sumber utama tidak sependapat dan repositori menyelesaikan persoalan itu. Kolom formulir advisory mencatat versi yang terdampak sebagai "<= 2.10.3-lts", dengan catatan bahwa ini diverifikasi pada 2.10.3-lts dan bahwa jalur rentan "kemungkinan" memengaruhi semua versi yang membangun agen dengan cara ini. Tulisan Lasso sendiri menyatakan rentang yang terdampak sebagai "<= 2.10.4-lts". Tag mengonfirmasi rentang yang lebih luas: v2.10.4-lts, dirilis 16 Juli 2026, membawa sandbox_shell.py 75 baris yang sama dengan v2.10.3-lts, dan file 311 baris yang ditulis ulang pertama kali muncul di v2.10.5-lts. Seorang operator pada 2.10.4-lts yang hanya membaca rentang pada advisory akan menyimpulkan bahwa mereka berada di luar rentang itu. Padahal tidak.

Apa yang tidak dilakukan oleh perbaikan tersebut

Yang diperbaiki 2.10.5-lts adalah wrapper-nya: wrapper tersebut tidak lagi membangun satu string shell di bawah root. Yang tidak dilakukannya adalah apa pun terhadap tool tersebut. Pembacaan langsung repositori pada tag v2.10.8-lts, yang diterbitkan 22 Oktober 2026, menunjukkan agen masih dikonstruksi dengan backend=SandboxShellBackend dan interrupt_on masih membawa tepat tiga kunci — write_file, read_file, dan edit_file — tanpa execute. Dua saran remediasi pertama dalam advisory tersebut, yaitu membangun di atas backend non-eksekusi secara default dan menambahkan "execute": True ke peta persetujuan, tidak ada dalam rilis itu.

Rekomendasi fail-closed baru muncul kemudian, di v2.10.7-lts, dan ini penting bagi mode deployment yang kondisinya paling buruk. Diterbitkan pada 15 Oktober 2026, perubahan itu mengubah baris di sandbox_shell.py dari CONFIG.get("SANDBOX", 0) menjadi CONFIG.get("SANDBOX", 1). Instalasi dari sumber atau bare-metal yang tidak pernah menyetel variabel tersebut kini membuat wrapper aktif secara default, bukan nonaktif, yang merupakan rekomendasi "fail closed on non-container deploys" dalam arti sempit. Advisory meminta lebih dari itu di bawah judul yang sama — yaitu agar alur yang mampu mengeksekusi menolak untuk mulai saat runtime sandbox tidak tersedia — dan secara terpisah meminta wrapper tidak pernah membangun string perintah untuk shell root. Di sisi container, ini fakta, bukan rekomendasi: baik installer/Dockerfile maupun installer/Dockerfile-base tidak memuat direktif USER pada tag v2.10.8-lts, sehingga image aplikasi masih dimulai sebagai root.

Jika dibaca bersama, status catatan per 28 Oktober 2026 adalah sebagai berikut. Separuh kedua kerentanan — sandbox yang berhasil ditembus oleh sebuah titik koma — sudah ditutup, dan default fail-open pada deployment host juga sudah ditutup. Separuh pertama, yaitu alat execute yang datang dengan objek backend dan bukan merupakan kunci dalam peta persetujuan, masih menjadi cara MaxKB membangun asisten yang mendukung alat. Saran remediasi dari para peneliti sendiri bersifat spesifik: lakukan peningkatan ke 2.10.5-lts atau yang lebih baru, dan jalankan versi Docker dengan sandbox diaktifkan. GBHackers menyampaikan instruksi yang sama ditambah daftar yang lebih luas untuk administrator — nonaktifkan backend agen yang mampu menjalankan shell kecuali eksekusi kode secara eksplisit diperlukan, wajibkan persetujuan manusia sebelum tindakan execute apa pun, jalankan kontainer sebagai non-root, dan perlakukan halaman yang di-crawl, dokumen RAG, dan unggahan sebagai input yang tidak tepercaya.

Catatan MaxKB lainnya dari batch September yang sama

Entri MaxKB kedua dari arsip dalam batch ini adalah bug berbeda dengan akhir yang lebih buruk. CVE-2026-77516, yang juga diterbitkan ke NVD pada 21 September 2026, adalah bypass izin, bukan injeksi perintah: dari versi 2.0.0 hingga 2.9.2, anggota workspace dengan peran terendah, yang secara eksplisit ditolak aksesnya ke suatu tool melalui WorkspaceUserResourcePermission, tetap dapat mengikatkan pengenal tool tersebut melalui tool_ids, skill_tool_ids, atau mcp_tool_ids dan mengeksekusinya melalui jalur dispatch agent atau workflow. Jalur dispatch tidak menerapkan kembali pemberian izin per-tool yang ditegakkan oleh rute tool khusus, dan eksekusi tool mendekripsi init_params di sisi server, sehingga pemanggil menerima kredensial yang dibawa oleh tool yang aksesnya ditolak. Skornya 5,4, dan deskripsi NVD ditutup dengan kalimat yang tidak harus dimuat oleh CVE-2026-77521: "Tidak ada versi perbaikan yang tersedia pada saat tinjauan ini."

Kontrasnya adalah bagian yang berguna bagi siapa pun yang melakukan triase terhadap pasangan tersebut. Cacat yang mendapat skor 10,0 memiliki perbaikan yang di-commit dalam waktu sehari dan dirilis sebulan sebelum dipublikasikan. Cacat yang mendapat skor 5,4 tidak memiliki versi perbaikan yang dipublikasikan pada saat CVE-nya.

Yang benar-benar masih terbuka lebih kecil daripada yang disiratkan skor dan lebih besar daripada yang disiratkan catatan tambalan. Temuan ini tidak diperdebatkan dan mekanismenya telah diverifikasi secara menyeluruh pada kedua mode penerapan oleh tim yang menemukannya. Tingkat paparannya sama sekali belum terukur — belum ada yang menerbitkan berapa banyak asisten MaxKB yang membawa sebuah tool, berapa banyak di antaranya yang dapat dijangkau oleh pihak tak tepercaya, atau berapa banyak yang berjalan di host tanpa sandbox — sehingga konsekuensi nyata dari cacat ini merupakan fungsi dari kebiasaan penerapan yang tidak dihitung oleh sumber mana pun yang dikutip. Dan bagian dari rancangan yang mendorong skor hingga maksimum masih ada dalam rilis saat ini: sebuah kemampuan yang menjalankan perintah, terpasang secara default, tidak ada dalam peta yang meminta persetujuan manusia terlebih dahulu.