.png)
Kerentanan pada MetInfo CMS versi 7.9 hingga 8.1 input tidak disanitasi tetapi secara teknis jauh lebih dalam. Ia menggabungkan tiga elemen yang biasanya dianggap “aman” jika berdiri sendiri: endpoint API (WeChat), mekanisme cache berbasis file, dan parsing string PHP. Ketika ketiganya bertemu dalam satu execution path, hasilnya adalah unauthenticated remote code execution.
Masalah dimulai dari method "weixinreply::wxAdminLogin()" yang memproses request XML dari integrasi WeChat. Dua field, "EventKey" dan "FromUserName", langsung digunakan tanpa validasi ketat. "EventKey" dipakai sebagai parameter "$code" dalam "cache::get()", sementara "FromUserName" disimpan melalui "cache::put()". Secara desain, ini tampak seperti alur caching biasa, tetapi implementasinya membuka celah serius.
Ketika "$code" dapat dikontrol attacker, ia bisa menyisipkan path traversal untuk memanipulasi file yang di-include oleh "cache::get()". Di titik ini, tujuan attacker bukan hanya membaca file, melainkan mengubah state aplikasi. Dengan memaksa hasil tertentu misalnya string "Array" attacker mengarahkan flow ke penulisan file cache baru dengan nama yang bisa diprediksi: "/cache/weixin/Array.php"
Tahap berikutnya adalah inti dari eksploitasi. Nilai "FromUserName" ditulis ke dalam file tersebut dalam konteks string PHP. Di sinilah fitur yang jarang disadari developer menjadi senjata: complex curly syntax dalam PHP memungkinkan evaluasi ekspresi di dalam string. Artinya, input yang tampak seperti teks biasa bisa berubah menjadi kode yang dieksekusi saat file di-include. Ketika file cache itu dipanggil kembali oleh sistem, payload langsung berjalan tanpa hambatan.
Skenario eksploitasi di dunia nyata tidak membutuhkan kondisi yang rumit. Target yang menggunakan plugin WeChat secara default sudah memiliki direktori "/cache/weixin/". Attacker hanya perlu mengirim request XML crafted ke endpoint webhook. Request pertama bertujuan menulis file berisi payload, dan request berikutnya (atau bahkan alur internal yang sama) memicu include file tersebut. Dalam hitungan detik, attacker bisa mendapatkan eksekusi perintah di server, biasanya dilanjutkan dengan drop web shell untuk persistensi.
Dampaknya langsung berada pada level kompromi penuh. Begitu RCE tercapai, batas antara aplikasi dan sistem operasi praktis hilang. Database dapat diakses, konfigurasi dapat diubah, dan sistem bisa dijadikan pivot ke jaringan internal. Dalam konteks yang lebih luas, ini bukan saja bug aplikasi, tetapi juga potensi titik masuk untuk serangan supply chain jika CMS digunakan secara luas oleh banyak situs.
Baca Juga Tentang: Remote Code Exceution (RCE)
Yang menarik dari kasus ini adalah bagaimana lapisan cache berubah menjadi attack surface. Banyak sistem menganggap cache sebagai komponen pasif, padahal ketika cache disimpan sebagai file ".php" dan di-include kembali, ia secara efektif menjadi bagian dari runtime execution. Ditambah lagi, endpoint seperti webhook sering diasumsikan “trusted” sehingga jarang mendapat validasi ketat, padahal justru menjadi pintu masuk tanpa autentikasi.
Mitigasi yang efektif harus langsung memutus rantai eksploitasi ini. Validasi input perlu berbasis whitelist dan menolak karakter traversal sejak awal. Lebih penting lagi, mekanisme cache seharusnya tidak pernah menggunakan format executable seperti ".php;" menyimpannya sebagai data (misalnya JSON) sudah cukup untuk kebutuhan caching tanpa membuka risiko eksekusi. Di sisi lain, penggunaan dynamic include berbasis input harus dihindari sepenuhnya. Patch dari vendor memang wajib diterapkan, tetapi tanpa perubahan pola desain seperti ini, risiko serupa akan terus muncul di tempat lain.
Bagi praktisi keamanan, ini contoh jelas bahwa kerentanan kritis sering bukan berasal dari satu bug besar, melainkan dari interaksi beberapa komponen kecil yang masing-masing terlihat “normal”. Ketika boundary antar layer tidak dijaga dengan ketat, sistem akan menciptakan jalur eksekusi yang bahkan tidak disadari oleh developernya sendiri.
Benediktus Sava – Security Researcher
Sumber:
