MaxKB: jalur pengiriman agen memungkinkan pengguna yang ditolak akses ke suatu alat untuk tetap memanggilnya dan membaca kredensialnya

MaxKB, asisten AI perusahaan sumber terbuka yang dikelola oleh 1Panel-dev, menyediakan daftar izin per pengguna dan per alat sehingga administrator dapat memberikan satu alat kepada anggota ruang kerja dan menolak alat lainnya. Menurut advisory keamanan yang diterbitkan pada 2 September 2026, penolakan tersebut berlaku pada rute alat itu sendiri tetapi tidak pada jalur yang digunakan agen atau alur kerja untuk memanggil alat yang sama. Anggota ruang kerja dengan peran terendah dapat menyebutkan pengenal alat yang ditolak saat membuat alur kerja, menjalankan alur kerja tersebut, dan menerima bukan hanya keluaran alat itu tetapi juga kredensial yang didekripsi MaxKB di sisi server untuk menjalankannya. Versi 2.0.0 hingga 2.9.2 terdampak, dan advisory tersebut tidak menyebutkan versi yang telah ditambal. Catatan ini — bypass otorisasi pengiriman alat MaxKB — adalah satu entri dalam OrcaRouter AI Incident Archive, yang memuat kumpulan catatan lengkap dan entri-entri di sekitar insiden ini.

Yang membuat kasus ini layak dibaca dengan saksama bukanlah skornya. Melainkan bahwa produk tersebut sudah memiliki pemeriksaan yang tepat, menerapkannya pada pintu yang jelas, dan membiarkan pintu kedua menuju kemampuan yang sama tanpa pengawasan. Advisori, GHSA-383v-fx78-pphm, ditulis oleh peneliti yang menemukannya dan diterbitkan melalui sistem advisori GitHub pada 07.43 UTC, 2 September 2026, dengan mencantumkan kredit untuk Matteo Panzeri (@matte1782). Catatan CVE, CVE-2026-77516, menyusul pada 21 September 2026.

Apa yang ditetapkan oleh advisory tersebut

Model per-tool MaxKB adalah WorkspaceUserResourcePermission, yang dijelaskan dalam advisory sebagai daftar izin default-deny yang diselesaikan pada waktu permintaan. Rute tool khusus menegakkannya. Advisory mencantumkan penegakan tersebut di apps/tools/views/tool.py, tempat Operate.put, Operate.get, Debug.post, Export.get, dan Delete masing-masing membawa pemeriksaan izin tampilan terhadap izin tool workspace pemanggil. Debug.post adalah rute yang paling dekat dengan sekadar menjalankan tool, dan rute itu dibatasi.

Jalur dispatch agen dan workflow tidak menerapkan kembali pemeriksaan tersebut. Advisory itu menelusuri tiga tempat terpisah yang pemeriksaan tersebut hilang. Di apps/application/serializers/application.py, serializer aplikasi mengikat tool_ids, skill_tool_ids dan mcp_tool_ids langsung dari input permintaan tanpa otorisasi per alat — dan advisory tersebut menunjukkan bahwa asimetri itu terlihat di file yang sama, karena knowledge_id_list divalidasi terhadap basis pengetahuan yang dapat diakses pengguna beberapa baris di bawahnya sementara alat tidak. Di apps/common/utils/shared_resource_auth.py, filter_authorized_ids meneruskan setiap alat di ruang kerja pemanggil tanpa syarat; gerbang lintas ruang kerja yang menjadi sandarannya adalah hook khusus enterprise yang tidak ada di edisi komunitas, dan hook itu tidak pernah memeriksa WorkspaceUserResourcePermission. Dan pada sink, apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py menjalankan kode tersimpan milik alat dengan init_params yang didekripsi oleh rsa_long_decrypt di bawah identitas aplikasi, tanpa pemeriksaan pemberian izin per alat.

Peringatan tersebut menyebut hasilnya sebagai eksekusi confused-deputy: pengiriman alur kerja menjalankan sebuah alat, beserta rahasia tersimpannya, yang ditolak bagi pemanggil yang sama pada rute milik alat itu sendiri. Paparan kredensial adalah bagian yang melampaui penggunaan alat tanpa izin biasa. init_params milik sebuah alat dienkripsi saat disimpan dengan RSA dan didekripsi di sisi server hanya pada waktu eksekusi, sehingga pemanggil yang memicu eksekusi tersebut menerima nilai yang tidak pernah mereka pegang dan tidak mungkin mereka berikan.

Demonstrasi itu, dalam angka versi peneliti sendiri

Laporan advisory tersebut melaporkan konfirmasi dinamis pada v2.9.2, yang dijalankan dari image all-in-one resmi, 1panel/maxkb:v2.9.2. Konfigurasinya terdiri atas satu workspace, seorang administrator, dan seorang anggota kedua yang memegang peran USER. Administrator membuat Tool A dan Tool B, lalu menaruh secret acak baru di init_params milik Tool B, dan menulis body Tool B agar mengembalikan secret tersebut saat dieksekusi. Anggota tersebut kemudian diberi izin per alat hanya untuk Tool A, dan laporan advisory menyebutkan bahwa status tanpa izin untuk Tool B diperiksa ulang di basis data setelah eksekusi.

Separuh pengujian yang ditolak mengembalikan apa yang dijanjikan produk. Sebagai anggota, rute debug untuk Tool B menjawab 403, rute pembaruan menjawab 403, rute ekspor menjawab 403, dan Tool A yang diizinkan mengembalikan 200 sebagai pemeriksaan kewajaran. Separuh bypass kemudian mengikat Tool B ke dalam aplikasi alur kerja melalui node pustaka alat — pengikatan itu diterima dengan HTTP 200 dan tanpa pemeriksaan per alat — dan menjalankan alur kerja mengembalikan HTTP 200 dengan body yang berisi nama alat, rahasia sentinel, dan daftar kunci ["api_key"].

Advisory tersebut menyebutkan bahwa rahasia itu muncul pada tiga lapisan: dalam respons API alur kerja, dalam catatan eksekusi tool dengan status SUCCESS, dan dalam baris basis data tempat Tool B init_params berada sebagai ciphertext RSA 344 byte — yang menjadi dasar peneliti berargumen bahwa nilai itu didekripsi di sisi server dengan identitas aplikasi, bukan disediakan oleh pemanggil. Anggota yang sama yang ditolak pada rute eksekusi tool tersebut memperoleh rahasia terdekripsi tool itu dengan mengikatnya ke dalam alur kerja.

Satu skor diterbitkan, skor yang lebih tinggi diperdebatkan

Skor yang dilampirkan pada CVE-2026-77516 adalah CVSS 3.1 5.4, Sedang, dengan vektor AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Catatan NVD menunjukkan bahwa skor tersebut bersumber dari feed advisory GitHub, bukan dari analisis NVD sendiri, dan entri tersebut memiliki status Deferred, yang berarti NVD belum memperkaya entri itu. Klasifikasi arsip itu sendiri mengikuti skor yang dipublikasikan tersebut: tingkat keparahan sedang, tanpa dampak merugikan nyata yang tercatat.

Bagian dampak dari advisory itu sendiri berargumen untuk nilai yang lebih tinggi. Bagian tersebut menyatakan tingkat keparahan 7.1, Tinggi, pada vektor yang menaikkan dampak kerahasiaan menjadi tinggi, dan menyebut bahwa angka itu naik menjadi 8.1 ketika alat yang dikerahkan melakukan penulisan dengan hak istimewa atas identitas aplikasi. Itu adalah ketidaksepakatan tentang cara menghitung paparan kredensial, bukan tentang apakah bypass tersebut ada — dokumen yang sama sekaligus menunjukkan adanya cacat dan berargumen bahwa cacat itu dinilai terlalu rendah. Tidak ada apa pun dalam catatan publik yang menyelesaikan angka mana yang benar, dan peringkat medium dalam arsip mengikuti skor CVE yang dipublikasikan, bukan argumen advisory tersebut.

Dua penilaian lebih lanjut tercatat. Titik keputusan SSVC CISA, yang ditambahkan ke entri NVD pada 28 September 2026, mencatat eksploitasi sebagai "poc", dapat diotomatiskan sebagai "no", dan dampak teknis sebagai "partial" — nilai "poc" mencerminkan bahwa proof of concept memang ada, yang memang demikian, di dalam advisory itu sendiri; ini bukan temuan eksploitasi di lapangan. Model EPSS FIRST menempatkan probabilitas eksploitasi dalam 30 hari ke depan pada 0,242%, pada persentil ke-15,2, dalam estimasi tertanggal 27 Oktober 2026.

Perbaikan yang mendahului advisory, dan tidak ada yang berada dalam rentang terdampak

Tabel versi dalam advisory menyebutkan versi terdampak 2.0.0 hingga 2.9.2, versi yang telah ditambal tidak ada, dan teksnya menyatakan bahwa tidak ada versi perbaikan yang tersedia pada saat peninjauan, serta menambahkan bahwa perbaikan dalam rilis yang diberi tag akan memungkinkan CVE dikaitkan padanya. Repositori vendor menunjukkan cerita yang sedikit berbeda, dan perbedaannya penting bagi siapa pun yang memutuskan versi apa yang akan dijalankan.

Di repositori MaxKB, fungsi-fungsi yang menutup jalur dispatch — validate_bound_tool_permissions dan get_authorized_tool_ids di apps/application/serializers/application.py — tidak ada pada tag v2.9.2 dan pada v2.10.2-lts, v2.10.3-lts, serta v2.10.4-lts, dan ada mulai v2.10.5-lts dan seterusnya. Rilis tersebut diterbitkan pada 6 Agustus 2026, empat minggu sebelum advisory. Tag yang sama menambahkan pemeriksaan tool per pengguna ke base_tool_lib_node.py, dengan memanfaatkan WorkspaceUserResourcePermission, dan menambahkan filter yang sadar pengguna ke shared_resource_auth.py — yang berarti, secara garis besar, implementasi tersebut menerapkan tiga langkah remediasi yang nantinya direkomendasikan advisory.

Tidak ada yang menyatakan koneksi itu secara publik. Catatan rilis v2.10.5-lts tidak menyebutkan perbaikan izin alat; catatan tersebut mencantumkan empat item keamanan yang tidak terkait dan sekumpulan pekerjaan fitur dan bug. Advisory tersebut tidak menyebutkan 2.10.5, dan rentang terdampaknya berhenti begitu saja di 2.9.2, rilis terakhir dari lini 2.9. Riwayat rilis tidak menunjukkan patch 2.9.x setelah advisory tersebut, sehingga deployment pada 2.9.2 tidak memiliki build yang telah diperbaiki di dalam lininya sendiri. Rilis saat ini adalah v2.10.8-lts, yang diterbitkan pada 22 Oktober 2026, yang catatannya menjelaskan perbaikan X-Pack pada otorisasi alat bersama, bukan apa pun di jalur dispatch edisi komunitas.

Apa yang belum ditetapkan

Ada tiga hal yang layak dipisahkan dari demonstrasi. Pertama, tidak ada laporan publik bahwa bypass tersebut digunakan terhadap siapa pun. Catatan yang ada adalah kerentanan yang ditemukan, bukan intrusi yang diinvestigasi; catatan itu tidak menyertakan korban, aktor yang diatribusikan, maupun kerugian, dan proof of concept dalam advisory dijalankan oleh peneliti di ruang kerja terkendali. Kedua, tidak tampak ada organisasi berita, regulator, atau tim riset kedua yang menganalisis cacat tersebut: liputan yang ada terbatas pada basis data dan agregator kerentanan — antara lain VulDB, basis data Rapid7, Armis, SOCRadar, dan openCVE — yang mencantumkan CVE dan memuat deskripsi dari advisory, dan tidak satu pun menawarkan penilaian independen atas kode tersebut. Oleh karena itu, mekanisme sebagaimana dijelaskan di sini bertumpu pada satu advisory dan pada kode sumber milik vendor sendiri. Ketiga, tidak ada angka tentang berapa banyak deployment MaxKB yang berada dalam rentang terdampak, dan baik vendor maupun peneliti tidak menerbitkannya.

Populasi yang berisiko memang sempit tetapi tidak sepele untuk dihitung: instalasi MaxKB edisi komunitas yang dihosting sendiri pada versi 2.0.0 hingga 2.9.2 yang memiliki lebih dari satu anggota workspace, ketika seorang administrator telah menggunakan izin per alat untuk menahan akses ke alat yang membawa kredensial. Cacat ini bukan eksekusi kode jarak jauh dan memerlukan akun valid dengan hak istimewa rendah, sehingga dampak kerahasiaanlah yang mendorong skor, bukan jalur serangannya. Apa yang diperoleh penyerang dibatasi oleh apa yang disimpan alat yang ditolak aksesnya — kunci API, token, dan apa pun yang dapat dibuka olehnya — yang juga menjadi alasan para penulis advisory berpendapat bahwa dampaknya lebih besar daripada yang disiratkan oleh peringkat kerahasiaan yang rendah.

Apa yang dapat dilakukan operator

Remediasi dalam advisory ini ditujukan kepada para maintainer, bukan kepada operator, dan ketiga langkahnya dipetakan ke kode yang muncul di v2.10.5-lts: terapkan pemberian izin per-alat sebelum mengeksekusi alat dalam implementasi tool-library dan tool node, validasi setiap tool_ids, skill_tool_ids dan mcp_tool_ids yang terikat pada waktu binding seperti knowledge_id_list yang sudah ada, dan buat filter_authorized_ids merujuk pada pemberian izin per-alat alih-alih hanya pada keanggotaan workspace.

Bagi tim yang menjalankan build terdampak, langkah-langkah praktis yang mengikuti dari deskripsi advisory itu sendiri adalah sebagai berikut.

• Perlakukan setiap rahasia yang tersimpan di init_params sebuah tool pada deployment yang terdampak sebagai dapat dijangkau oleh setiap anggota workspace, termasuk peran terendah, dan rotasikan kredensial tersebut alih-alih mengasumsikan bahwa penolakan per-tool melindunginya.

• Audit keanggotaan workspace. Bypass ini memerlukan akun terautentikasi di workspace, jadi menghapus anggota yang dorman atau tidak tepercaya akan mengurangi eksposur bahkan ketika kode tidak dapat ditambal.

• Tinjau alur kerja dan agen mana yang mengikat alat yang membawa kredensial, karena pengikatan itulah langkah yang menurut advisory diterima tanpa pemeriksaan per alat.

• Jika melakukan peningkatan versi, perhatikan bahwa pemeriksaan per pengguna muncul di repositori mulai dari v2.10.5-lts dan seterusnya dan bahwa tidak ada rilis yang ditetapkan sebagai perbaikan oleh advisory — operator yang mengandalkan peningkatan versi tersebut mengandalkan sumber yang diberi tag, bukan pada pernyataan patch dari vendor.

Tidak ada dari semua ini yang membuat cacat tersebut dramatis. Semua ini justru membuatnya biasa dengan cara yang spesifik dan instruktif: model otorisasinya dirancang dengan benar, didokumentasikan dengan benar, dan ditegakkan pada rute-rute yang diingat seseorang untuk dibatasi aksesnya. Jalur dispatch ditulis oleh orang-orang yang memikirkan apa yang seharusnya bisa dilakukan sebuah alur kerja, bukan tentang siapa yang meminta — dan dalam platform agen, itulah jalur yang sebenarnya dilalui sebagian besar permintaan.

Pelajaran dari catatan ini bersifat struktural, bukan numerik. Izin per sumber daya hanya sekuat titik masuknya yang paling lemah pengamanannya, dan platform agen mengumpulkan titik masuk dengan cepat: rute debug, rute ekspor, node alur kerja, pemicu chat. MaxKB memiliki daftar pemberian izin dan pemeriksaannya; yang tidak dimilikinya, untuk lini 2.0 hingga 2.9, adalah kebiasaan mengajukan pertanyaan yang sama di setiap pintu.