Satu akun dengan izin "cuma" bikin atau ubah workflow — level akses yang di banyak tim dipegang siapa saja yang pernah disuruh menyambungkan dua aplikasi — ternyata cukup untuk menjalankan perintah sistem operasi langsung di server yang menjalankan n8n. Tidak perlu bug di plugin pihak ketiga, tidak perlu kredensial admin curian. Cukup expression JavaScript yang dirangkai dengan cara tertentu di dalam workflow editor bawaan platform itu sendiri (GitHub Security Advisory).
Yang bikin kasus ini menarik bukan cuma soal RCE-nya, tapi cara ia ditemukan: peneliti dari Security Joes justru sedang menguji ulang tambalan Februari 2026 untuk celah lama (CVE-2026-27577) — mencari tahu apakah perbaikan itu benar-benar menutup pintunya atau cuma memindah lubangnya. Ternyata yang kedua (The Hacker News).
Bagaimana Sandbox yang Sudah "Diperbaiki" Bisa Ditembus Lagi
n8n menjalankan expression pengguna — kode kecil yang dipakai untuk memetakan data antar-node workflow — di dalam sandbox JavaScript agar tidak bisa menyentuh sistem file atau proses di baliknya. Celah GHSA-gv7g-jm28-cr3m memanfaatkan cara sandbox itu menangani isi body fungsi arrow: dengan menyusun expression secara spesifik, penyerang bisa keluar dari batas sandbox dan mengeksekusi kode di luar konteks yang seharusnya diisolasi, sampai ke command level OS tempat proses n8n berjalan.
Ini bukan kegagalan sandbox yang berdiri sendiri. GitHub Advisory Database mencatat sederet advisory sandbox-escape terpisah untuk n8n dalam setahun terakhir — mencakup expression engine, Python sandbox, sampai JavaScript task runner-nya — dan CVE-2026-27577 yang ditambal Februari itu adalah salah satunya. Security Joes justru mengetes ulang tambalan itu, bukan mengasumsikan bahwa "sudah dipatch" berarti "sudah aman", dan menemukan bahwa variasi arrow-function tertentu masih lolos dari pemeriksaan sandbox yang baru. Pola berulang seperti ini biasanya menandakan tambalan sebelumnya menutup gejala yang dilaporkan pada saat itu, bukan kelas kerentanannya secara menyeluruh.
Dampaknya Lebih dari Sekadar "Server Bisa Diperintah"
Security Joes menyoroti satu detail yang membuat celah ini lebih berbahaya dari sandbox escape biasa: begitu penyerang bisa menjalankan perintah OS, mereka bisa membaca variabel lingkungan N8N_ENCRYPTION_KEY — kunci yang dipakai n8n untuk mengenkripsi seluruh kredensial yang tersimpan di platformnya. Artinya satu langkah eksploitasi ini berpotensi membuka jalan ke setiap API key, token OAuth, dan password database yang pernah dihubungkan tim ke workflow otomatisasi mereka, bukan cuma akses ke satu server.
Syarat eksploitasinya juga rendah: cukup akun yang punya izin membuat atau mengubah workflow, tidak perlu peran admin, dan tidak butuh interaksi dari pengguna lain sama sekali — beda dari banyak celah RCE yang butuh korban mengklik sesuatu. Kombinasi CVSS v4 8,7 dengan syarat akses serendah itu yang membuat sejumlah outlet keamanan langsung menandai advisory ini sebagai risiko kompromi server penuh, bukan sekadar bug tingkat menengah (SecurityWeek).
Versi yang terdampak: semua rilis di bawah 2.31.5, plus rentang sempit 2.32.0 sampai sebelum 2.32.1 — celah yang sama sempat masuk lagi ke rilis minor yang lebih baru sebelum akhirnya ditambal permanen di 2.31.5 dan 2.32.1.
Kenapa Alat Otomatisasi Workflow Jadi Target Berulang
n8n bukan sekadar tool internal niche — ia dipakai luas sebagai alternatif open-source Zapier, sering di-self-host oleh tim yang justru ingin lebih mengontrol keamanan datanya sendiri dibanding memakai SaaS pihak ketiga. Ironisnya, model itu membuat kelas bug seperti ini lebih berisiko: sandbox ekspresi adalah fitur inti yang memang dirancang untuk menjalankan kode yang ditulis pengguna, bukan cacat samping yang bisa dimatikan. Setiap kali sandbox-nya perlu diperkuat, permukaan serangnya (semua sintaks JavaScript valid yang harus tetap "aman" dijalankan) nyaris sama luasnya dengan bahasanya sendiri.
Rekomendasi mitigasi dari advisory itu sendiri pun jujur soal keterbatasannya: membatasi siapa yang punya izin membuat/mengubah workflow ke pengguna tepercaya memang mengurangi risiko, tapi tidak menghilangkannya — karena definisi "tepercaya" itulah yang justru dieksploitasi celah ini. Satu-satunya mitigasi yang benar-benar menutup jalur ini adalah upgrade ke versi yang sudah ditambal, bukan sekadar mengetatkan siapa yang dikasih izin.
Ini juga bukan masalah unik n8n. Platform low-code/no-code lain yang menawarkan "expression builder" atau formula custom — dari alat otomatisasi sampai form builder — menghadapi trade-off yang sama persis: makin fleksibel bahasa ekspresi yang diizinkan pengguna, makin sulit memastikan sandbox-nya benar-benar kedap terhadap setiap kombinasi sintaks yang valid.
Takeaway
Yang penting dari kasus ini bukan cuma satu CVE baru, tapi konfirmasi bahwa tambalan Februari yang dianggap menutup celah RCE ternyata masih meninggalkan jalur arrow-function yang belum tercakup — dan baru ketahuan karena ada peneliti yang repot-repot menguji ulang, bukan karena n8n menemukannya sendiri. Kalau tim kamu menjalankan n8n self-hosted, cek versi sekarang: harus 2.31.5 atau 2.32.1 ke atas. Dan karena celah ini berpotensi membongkar N8N_ENCRYPTION_KEY, upgrade versi saja belum selesai — rotasi semua kredensial yang tersimpan di instance itu juga layak dipertimbangkan kalau ada kemungkinan akun dengan izin workflow sempat disusupi sebelum patch naik.
---
Sumber gambar: Adi Goldstein di Unsplash Sumber gambar: Chris Ried di Unsplash Sumber gambar: Christopher Gower di Unsplash
The conversation 0
No comments yet. Start the conversation.