.png)
Kerentanan baru pada aplikasi manajemen unduhan pyLoad mengungkap kelemahan serius yang memungkinkan eksekusi kode arbitrer tanpa autentikasi melalui mekanisme yang tidak biasa, yaitu manipulasi direktori penyimpanan dan penyalahgunaan sistem sesi berbasis filesystem. Celah ini merupakan kelanjutan dari perbaikan yang tidak lengkap terhadap kerentanan sebelumnya, CVE-2026-33509, dan menunjukkan bagaimana kontrol akses yang tidak komprehensif dapat membuka jalur eksploitasi baru yang signifikan.
Masalah utama berakar pada opsi konfigurasi bernama storage_folder yang tidak dimasukkan dalam daftar parameter sensitif yang dibatasi hanya untuk admin. Dalam implementasi sebelumnya, pengembang telah memperkenalkan mekanisme pembatasan melalui sebuah set bernama ADMIN_ONLY_OPTIONS untuk mencegah pengguna non-admin mengubah konfigurasi kritikal. Namun, storage_folder tidak termasuk dalam daftar tersebut. Akibatnya, pengguna dengan kombinasi izin tertentu masih dapat mengubah lokasi penyimpanan file unduhan tanpa pembatasan yang memadai.
Dalam konteks ini, eksploitasi membutuhkan seorang pengguna non-admin yang memiliki dua jenis izin, yaitu SETTINGS dan ADD. Kedua izin ini bersifat independen dan dapat diberikan secara bersamaan oleh administrator. Dengan izin SETTINGS, pengguna dapat mengubah konfigurasi storage_folder. Sementara itu, izin ADD memungkinkan pengguna untuk menambahkan URL unduhan. Kombinasi ini menjadi fondasi utama dalam rantai serangan.
Eksploitasi dimulai dengan mengarahkan storage_folder ke direktori yang digunakan oleh sistem sesi Flask, yang secara default berada di jalur seperti /tmp/pyLoad/flask dalam deployment berbasis Docker. Jalur ini lolos dari mekanisme validasi karena tidak berada dalam direktori yang dibatasi seperti PKGDIR atau userdir. Validasi yang ada hanya memeriksa apakah path hasil realpath berada dalam dua direktori tersebut, sehingga direktori sesi Flask tetap dapat diakses.
Selanjutnya, penyerang menghitung nama file sesi yang akan ditargetkan. Sistem sesi Flask yang digunakan oleh pyLoad dikonfigurasi dengan SESSION_TYPE = "filesystem" dan memanfaatkan cachelib FileSystemCache untuk menyimpan sesi. File sesi disimpan menggunakan hash MD5 dari string yang menggabungkan prefix default "session:" dengan session_id. Dengan mengetahui pola ini, penyerang dapat menentukan nama file sesi yang valid secara deterministik.
Tahap berikutnya melibatkan pembuatan payload berbahaya menggunakan serialisasi Python melalui modul pickle. Payload ini dirancang untuk mengeksekusi perintah sistem ketika dide-serialisasi. Dalam contoh yang diuji, payload tersebut menulis hasil perintah id ke dalam file tertentu sebagai bukti eksekusi. File payload kemudian di-host oleh penyerang dan diunduh oleh pyLoad melalui mekanisme normal unduhan, yang menyimpannya ke direktori storage_folder yang telah dimanipulasi, yaitu direktori sesi Flask.
Yang membuat kerentanan ini semakin signifikan adalah tahap akhir eksploitasi yang tidak memerlukan autentikasi. Setelah file sesi berbahaya berhasil ditempatkan di direktori yang tepat, penyerang hanya perlu mengirimkan permintaan HTTP dengan cookie sesi yang sesuai. Ketika aplikasi memproses permintaan tersebut, Flask akan memuat file sesi berdasarkan session_id yang diberikan. Proses ini melibatkan deserialisasi menggunakan pickle.load(), yang secara langsung mengeksekusi payload berbahaya.
Hasil akhirnya adalah eksekusi kode arbitrer dengan hak akses proses pyLoad. Dalam pengujian yang dilakukan pada image Docker lscr.io/linuxserver/pyload-ng:latest, eksploitasi ini berhasil dijalankan dan menunjukkan bahwa penyerang dapat menjalankan perintah sistem, membaca variabel lingkungan, mengakses sistem file, dan berpotensi melakukan pivot ke sumber daya jaringan lain. Fakta bahwa trigger akhir tidak memerlukan autentikasi meningkatkan tingkat risiko secara signifikan.
Dari perspektif desain sistem, kerentanan ini menunjukkan kelemahan dalam pendekatan validasi path yang hanya berfokus pada pembatasan direktori tertentu tanpa mempertimbangkan direktori sensitif lain yang digunakan secara internal oleh aplikasi atau dependensinya. Dalam kasus ini, direktori sesi Flask menjadi target yang ideal karena file di dalamnya secara otomatis diproses oleh aplikasi.
Selain itu, penggunaan pickle untuk deserialisasi data yang tidak terpercaya merupakan praktik yang dikenal berisiko tinggi. Pickle tidak dirancang untuk keamanan dan dapat mengeksekusi kode arbitrer selama proses deserialisasi. Ketika digabungkan dengan kemampuan menulis file ke lokasi yang diproses otomatis, risiko eksploitasi meningkat secara drastis.
Sebagai langkah mitigasi, disarankan untuk menambahkan storage_folder ke dalam daftar ADMIN_ONLY_OPTIONS agar hanya dapat dimodifikasi oleh administrator. Alternatif lain adalah memperluas validasi path untuk mencegah penulisan ke direktori sementara yang secara otomatis dikonsumsi oleh aplikasi, termasuk direktori sesi Flask, cache bytecode Jinja, dan direktori sementara pyLoad. Perbaikan tambahan juga mencakup koreksi nama opsi konfigurasi yang sebelumnya salah, seperti ssl_cert dan ssl_key yang seharusnya menggunakan nama ssl_certfile dan ssl_keyfile.
Kasus ini menyoroti pentingnya pendekatan holistik dalam pengamanan aplikasi, terutama dalam sistem yang memungkinkan konfigurasi dinamis oleh pengguna. Kontrol akses yang tidak lengkap, validasi input yang terbatas, dan penggunaan mekanisme deserialisasi yang tidak aman dapat saling berinteraksi dan menciptakan jalur eksploitasi yang kompleks namun efektif.
Bagi praktisi keamanan dan developer, temuan ini menjadi pengingat bahwa kerentanan tidak selalu berasal dari satu kesalahan tunggal, melainkan dari kombinasi beberapa asumsi yang tidak divalidasi secara menyeluruh. Dalam konteks pyLoad, celah ini muncul dari interaksi antara kontrol akses, manajemen path, dan mekanisme penyimpanan sesi. Tanpa evaluasi menyeluruh terhadap bagaimana komponen-komponen ini saling berinteraksi, risiko seperti ini dapat dengan mudah terlewatkan.
Dengan semakin banyaknya aplikasi yang mengandalkan komponen pihak ketiga seperti Flask dan cachelib, pemahaman terhadap bagaimana komponen tersebut bekerja secara internal menjadi semakin penting. Kerentanan ini menunjukkan bahwa bahkan konfigurasi default yang tampak aman dapat menjadi titik lemah jika tidak dipertimbangkan dalam model ancaman secara menyeluruh.
References: