Hai Friends! bagi para pengguna AI lokal pasti tidak asing GPUStack, kalau kalian menggunakannya buru-buru diupdate ya!

GPUStack adalah sebuah platform untuk mengelola model AI semestinya membedakan permintaan dari pengguna yang sudah login dan yang belum login. Pada GPUStack versi terdampak, autentikasi itu dapat dibypass!. Tim Ethic Ninja mereproduksi kelemahan tersebut di lingkungan terisolasi dan menguji dampaknya sampai pada sisi worker.

Gambar 1. Gambaran umum dampak kerentanan pada manajer dan worker GPUStack (diagram dari pengujian lab).

Mengapa ini penting?

GPUStack merupakan platform untuk mengatur sumber daya GPU, worker, dan deployment model AI, termasuk backend inference seperti vLLM, SGLang, dan llama.cpp. Dalam arsitektur private AI, komponen manajer sering memiliki akses ke konfigurasi, kredensial, serta pengaturan worker. Ketika manajemen autentikasi gagal, dampaknya bisa meluas jauh melampaui dashboard.

 

Di mana letak masalahnya?

Pada versi terdampak, GPUStack memiliki logika yang dapat memperlakukan permintaan yang dianggap berasal dari alamat loopback sebagai administrator bawaan apabila pengaturan force_auth_localhost tidak diaktifkan. Masalahnya, informasi asal koneksi tidak selalu dapat dipercaya: dapat dipengaruhi oleh header dari klien ataupun oleh cara reverse proxy meneruskan koneksi ke aplikasi.

Dengan demikian, koneksi yang sebenarnya berasal dari luar bisa keliru diperlakukan sebagai koneksi lokal yang tepercaya. Akar masalahnya bukan kata sandi yang lemah, melainkan keputusan autentikasi yang bergantung pada konteks jaringan.

Reverse proxy bukan jaminan keamanan autentikasi

GPUStack sering dijalankan di belakang Nginx atau reverse proxy untuk menerima koneksi dari internet. Masalahnya, pada versi yang rentan, GPUStack dapat menganggap koneksi yang datang dari server lokal (127.0.0.1) sebagai administrator tanpa perlu login.

Ketika Nginx dan GPUStack berjalan pada server yang sama, permintaan dari pengguna internet diteruskan oleh Nginx melalui koneksi lokal. Akibatnya, GPUStack bisa salah menganggap pengguna dari internet sebagai administrator.

Selain itu, ditemukan juga kelemahan pada pemeriksaan header HTTP X-GPUStack-Real-IP. Header ini dapat dimanipulasi sehingga GPUStack mengira permintaan berasal dari localhost, padahal sebenarnya datang dari luar server.

Bagaimana kami mengujinya di lab

Pengujian dilakukan menggunakan Docker Desktop di Apple Silicon. Kami menyiapkan GPUStack 2.1.1 sebagai sistem terdampak, satu worker terpisah, dan GPUStack 2.2.0 sebagai pembanding. Seluruh pembuktian dilakukan pada lingkungan laboratorium yang dikendalikan tim, bukan pada sistem pihak ketiga.

Untuk artikel publik ini, kami menampilkan hasil dan perubahan perilaku aplikasi, bukan rangkaian request, payload, maupun parameter operasional yang dapat langsung digunakan untuk mengambil alih layanan.

1. Akses normal tanpa login: ditolak

Pada pengujian awal, permintaan ke fungsi administrasi tanpa autentikasi menghasilkan respons HTTP 401. Inilah kondisi yang diharapkan: API tidak memberikan data pengguna kepada pihak yang belum login.

Gambar 2. Pengujian baseline: layanan menolak akses administratif tanpa autentikasi.

2. Ketika informasi asal request dipercaya

Setelah kondisi sumber koneksi dimanipulasi dalam skenario uji, endpoint yang sama justru mengembalikan HTTP 200 beserta informasi administratif. Ini menjadi bukti authentication bypass: kredensial tidak diberikan, tetapi aplikasi memperlakukan permintaan tersebut seolah memiliki hak yang lebih tinggi.

Gambar 3. Perbedaan hasil pengujian: akses administratif berhasil tanpa kredensial pada versi terdampak.

Kami juga menguji skenario reverse proxy yang berkomunikasi dengan GPUStack melalui loopback pada host yang sama. Hasilnya menunjukkan bahwa jalur ini tidak harus bergantung pada manipulasi header oleh klien; konfigurasi arsitektur saja dapat membuat aplikasi salah menilai asal permintaan.

Gambar 4. Skenario reverse proxy same-host pada versi terdampak.

3. Dampak akses yang tidak berhenti pada satu request

Dalam pengujian lanjutan, hak admin yang muncul secara tidak sah memungkinkan pembuatan kredensial API dengan hak luas. Kredensial yang sudah terbit tetap dapat digunakan pada request berikutnya. Ini penting dari sisi respons insiden: memperbaiki jalur bypass belum tentu cukup apabila token yang terbit sebelumnya masih aktif.

Gambar 5. Bukti bahwa fungsi pengelolaan API key dapat diakses setelah bypass.

Gambar 6. Validasi penggunaan kredensial yang diperoleh selama pengujian.

4. Risiko terhadap worker dan kredensial cluster

Lab kami juga menunjukkan akses ke token registrasi worker. Temuan ini memperluas dampak dari sekadar pembacaan data manajer: kredensial yang bocor dapat membahayakan hubungan kepercayaan antar-node. Kemungkinan penyalahgunaan worker atau manipulasi proses inference perlu dipertimbangkan, tetapi tidak semua skenario lanjutan tersebut dibuktikan dalam pengujian ini.

Gambar 7. Akses ke informasi registrasi worker pada sistem uji.

5. Dari kontrol manajer ke eksekusi pada worker

GPUStack mendukung backend inference yang dapat dikonfigurasi. Dalam kondisi hak administrasi telah diambil alih, fitur tersebut menjadi jalur berisiko menuju eksekusi perintah pada lingkungan worker. Di lab, tim berhasil membuktikan terjadinya eksekusi proses dan menerima bukti callback dari worker, dengan proses berjalan sebagai UID 0 pada konfigurasi pengujian.

UID 0 adalah konteks root di lingkungan proses yang diuji. Temuan ini tidak serta-merta berarti seluruh instalasi GPUStack akan memberikan akses root ke host fisik: dampaknya bergantung pada isolasi container, hak akses worker, mounting Docker socket, dan konfigurasi deployment.

Gambar 8. Penerimaan konfigurasi backend dalam skenario uji.

Gambar 9. Objek deployment pengujian berhasil dibuat.

Gambar 10. Status instance menunjukkan workload telah berjalan pada worker.

Gambar 11. Workload uji terlihat pada lingkungan container worker.

Gambar 12. Bukti callback eksekusi dalam lab; konteks proses tercatat sebagai UID 0.

6. Pembanding setelah patch

Kami mengulang pengujian akses awal terhadap GPUStack 2.2.0. Pada jalur yang sebelumnya membuka akses admin, versi yang diperbaiki memberikan HTTP 401. Hasil ini sesuai dengan perubahan keamanan yang dijelaskan pengembang: pengangkatan otomatis permintaan loopback menjadi admin telah dihapus dan penanganan informasi IP diperketat.

Gambar 13. Kontrol pada GPUStack 2.2.0: akses tanpa autentikasi kembali ditolak.

Apa yang terlihat di antarmuka?

Untuk membantu pembaca memahami lingkup akses, berikut dokumentasi dashboard, deployment, dan worker selama pengujian. Gambar-gambar ini merupakan bukti dari lingkungan lab, bukan indikasi bahwa instance GPUStack publik tertentu telah disusupi.

Gambar 14. Dashboard GPUStack pada lingkungan laboratorium.

Gambar 15. Halaman deployments pada skenario pengujian.

Gambar 16. Tampilan worker yang digunakan dalam pengujian.

Pelajaran teknis dari pengujian

Dari pengujian ini, ada dua hal penting yang perlu diperhatikan dalam membangun sistem AI.

Pertama, aplikasi tidak boleh langsung memberikan akses administrator hanya karena permintaan berasal dari 127.0.0.1 (localhost). Sebab, ketika aplikasi menggunakan reverse proxy seperti Nginx, permintaan dari internet bisa saja terlihat seolah-olah berasal dari server itu sendiri.

Kedua, celah keamanan pada GPUStack tidak hanya berdampak pada akses ke halaman administrator. Jika penyerang berhasil mendapatkan hak akses admin, mereka juga berpotensi mengendalikan worker yang menjalankan model AI, termasuk menjalankan perintah melalui fitur pengelolaan model.

Selama pengujian, tim Ethic Ninja juga menemukan bahwa keberhasilan eksekusi perintah dipengaruhi oleh konfigurasi worker, proses penjadwalan model, dan ketersediaan komponen yang dibutuhkan. Artinya, meskipun celah autentikasi berhasil dilewati, eksekusi perintah tidak selalu langsung berhasil pada setiap lingkungan.

Detail teknis eksploitasi tidak dibahas secara lengkap dalam artikel ini. Fokus pengujian kami adalah membuktikan dampak kerentanan dan memberikan informasi yang dapat digunakan administrator untuk mengamankan sistemnya.

Mitigasi: apa yang perlu dilakukan administrator?

Prioritas pertama: perbarui dan batasi akses

·       Perbarui GPUStack ke versi 2.2.0 atau yang lebih baru. Verifikasi versi pada seluruh manager, lalu uji ulang bahwa endpoint administratif menolak request yang tidak memiliki kredensial.

·       Apabila pembaruan belum dapat dilakukan, aktifkan force_auth_localhost=true sebagai mitigasi sementara sesuai advisory. Validasi perubahan setelah restart dan jangan menganggapnya sebagai pengganti patch.

·       Batasi akses dashboard dan API manajer melalui jaringan internal, VPN, atau gateway dengan autentikasi kuat. Hindari paparan langsung ke internet yang tidak diperlukan.

·       Konfigurasikan reverse proxy untuk membuang header identitas IP yang berasal dari klien dan hanya meneruskan nilai yang dibuat gateway tepercaya. Jangan menjadikan alamat loopback sebagai dasar pemberian hak admin.

·       Terapkan prinsip least privilege pada worker. Hindari memberikan akses Docker socket dan izin tingkat host kepada layanan kecuali benar-benar dibutuhkan.

Jika layanan pernah terekspos: periksa kemungkinan kompromi

·       Inventarisasi seluruh instance GPUStack, versi, koneksi reverse proxy, dan periode paparan akses administratif.

·       Audit API key yang dibuat, perubahan akun, backend custom, deployment model, worker baru, dan konfigurasi cloud/provider yang tidak dikenali.

·       Periksa log API, reverse proxy, dan aktivitas container/worker untuk request administratif yang tidak lazim, proses baru, koneksi keluar, serta perubahan konfigurasi.

·       Cabut dan rotasi API key serta token registrasi worker yang berpotensi bocor. Rotasi pula kredensial cloud/provider dan rahasia lain yang dapat diakses oleh manager.

·       Apabila ada indikasi eksekusi perintah, lakukan isolasi worker terkait, simpan bukti forensik, dan evaluasi pembangunan ulang dari image bersih. Patch saja tidak menghapus akses yang sudah tertanam.

Penutup

Pengujian ini mengingatkan bahwa satu asumsi yang kelihatannya sederhana—“request lokal pasti tepercaya” dapat mengubah sebuah platform pengelola AI menjadi pintu masuk ke seluruh cluster. Di GPUStack versi terdampak, tim Ethic Ninja membuktikan perubahan akses dari HTTP 401 menjadi akses administratif, keberlanjutan akses melalui API key, paparan token worker, dan eksekusi pada worker laboratorium. Pembanding pada versi 2.2.0 kembali menolak akses yang tidak sah.

Bagi organisasi yang sedang membangun private AI, keamanan model tidak cukup dinilai dari endpoint inference saja. Manajer, reverse proxy, secret, permission worker, dan aktivitas deployment harus menjadi satu kesatuan dalam audit keamanan.

Referensi

GPUStack Security Advisory — GHSA-gj9m-f8ph-pmhr: https://github.com/gpustack/gpustack/security/advisories/GHSA-gj9m-f8ph-pmhr

GPUStack v2.2.0 Release: https://github.com/gpustack/gpustack/releases/tag/v2.2.0

NVD — CVE-2026-102895: https://nvd.nist.gov/vuln/detail/CVE-2026-102895

CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Dokumentasi laboratorium: tim Ethic Ninja, pengujian 10 November 2026. Hasil dan tangkapan layar diambil dari lingkungan uji terisolasi.