Panduan Praktis

Server Vite terbuka sedang dipindai—rahasia .env ikut menjadi sasaran

|Penulis: Tim Redaksi QUASA|5 mnt baca
Server Vite terbuka sedang dipindai—rahasia .env ikut menjadi sasaran

Peringatan CSA Singapore bertanggal 17 September 2026 menyatakan bahwa CVE-2026-39364 sedang dieksploitasi untuk mengambil berkas sistem dan konfigurasi melalui Vite development server. Peringatan itu mencantumkan Vite 7.1.0–7.3.1 dan 8.0.0–8.0.4 sebagai versi terdampak serta meminta pengguna segera memperbarui perangkat lunak.

Ancaman tersebut tidak terbatas pada percobaan acak terhadap satu berkas. Dalam telemetri Agustus 2026, F5 Labs mengidentifikasi 807 kelompok serangan dan sekitar 32.000 peristiwa mentah dalam kampanye otomatis yang memburu berkas lingkungan, kunci AWS, token Azure, dan state Infrastructure as Code pada endpoint Vite yang terekspos.

Server harus dapat dijangkau dari jaringan

Keberadaan Vite dalam package.json tidak dengan sendirinya berarti proyek dapat dieksploitasi. Advisori keamanan resmi Vite menetapkan tiga syarat: development server dibuka ke jaringan melalui --host atau server.host, berkas sasaran berada di direktori yang diizinkan oleh server.fs.allow, dan berkas itu seharusnya ditolak oleh pola server.fs.deny. Advisori tersebut menetapkan versi perbaikan 7.3.2 untuk lini 7 dan 8.0.5 untuk lini 8.

Secara bawaan, development server Vite terikat ke localhost. Jalur serangan baru terbentuk bila layanan dapat dicapai dari jaringan yang tidak dipercaya, misalnya karena antarmuka host dibuka, porta container dipublikasikan, atau reverse proxy, ingress, dan tunnel meneruskan lalu lintas ke server pengembangan.

Karena itu, pemeriksaan tidak cukup dilakukan pada versi dependensi saat ini. Tim perlu mengetahui versi yang benar-benar berjalan selama periode eksposur, alamat yang dapat mengaksesnya, dan apakah konfigurasi jaringan memberi jalur menuju layanan tersebut. Server rentan yang hanya pernah dapat dijangkau dari localhost memiliki profil risiko berbeda dari instance yang sempat tersedia di internet.

Permintaan /@fs/ menjadi jejak teknis utama

Celah ini memungkinkan berkas yang seharusnya diblokir oleh server.fs.deny dikembalikan melalui rute internal /@fs/. Parameter kueri seperti ?raw, ?import&raw, atau ?import&url&inline dapat membuat pemeriksaan daftar penolakan tidak diterapkan sebagaimana mestinya dan menghasilkan respons HTTP 200.

Log Vite, reverse proxy, ingress, load balancer, WAF, dan penyedia cloud perlu ditelusuri untuk permintaan /@fs/. Pencarian juga perlu mencakup path traversal, path yang dikodekan berulang, parameter raw, import, url atau inline, serta rangkaian permintaan ke banyak nama berkas. Respons berhasil lebih mengkhawatirkan daripada probe yang ditolak, tetapi ketiadaan satu variasi sintaks tidak membuktikan bahwa tidak ada akses lain.

User-Agent bukan dasar yang cukup untuk menganggap permintaan sah. Kampanye yang teramati menggunakan identitas crawler dan bot populer yang dipalsukan, disertai nilai X-Forwarded-For atau X-Real-IP palsu. Penilaian perlu menggabungkan asal koneksi, path, waktu, status respons, ukuran respons, dan catatan dari beberapa lapisan jaringan.

Pemindai memburu rahasia cloud dan state infrastruktur

Daftar sasaran mencakup .env, .env.local, .env.production, .env.development, dan .env.staging. Pemindai juga meminta kredensial AWS di berbagai direktori pengguna, .azure/credentials, .azure/accessTokens.json, terraform.tfstate, terraform.tfvars, serverless.yml, serta state Serverless.

Permintaan ke /proc/self/environ, /proc/1/environ, dan /proc/self/cwd/.env berusaha memperoleh variabel lingkungan proses atau menemukan konfigurasi aplikasi tanpa mengetahui lokasi absolut proyek. Jika respons berhasil, satu berkas dapat membuka akses ke basis data, penyimpanan objek, API pihak ketiga, registry paket, webhook, sistem sesi, atau akun cloud—bergantung pada isi dan hak akses rahasia tersebut.

State Terraform tetap perlu diperlakukan sebagai data sensitif meskipun tidak selalu menyimpan kredensial yang langsung dapat digunakan. Berkas itu dapat berisi atribut resource, endpoint, identifier, output modul, dan nilai rahasia. Namun, kemunculan nama berkas dalam log hanya membuktikan adanya permintaan; keberhasilan pengambilan harus dinilai dari status dan isi respons, ketersediaan berkas, serta bukti penggunaan kredensial setelahnya.

Patch menutup celah, tetapi tidak mencabut rahasia

Pembaruan menghentikan eksploitasi CVE-2026-39364 melalui permintaan berikutnya, tetapi tidak membatalkan kredensial yang mungkin sudah tersalin. Bila server rentan pernah terekspos, rahasia dalam direktori yang dapat dilayani sebaiknya diperlakukan sebagai berpotensi terbaca sampai log dan bukti lain mempersempit cakupan insiden.

  1. Hentikan eksposur development server, pertahankan log yang tersedia, lalu pasang rilis perbaikan atau versi yang lebih baru pada lini yang digunakan.
  2. Petakan periode dan jalur eksposur, termasuk alamat publik, reverse proxy, ingress, tunnel, pemetaan porta container, firewall, dan cloud security group.
  3. Cari permintaan /@fs/, parameter bypass, path terenkode, nama berkas sasaran, serta respons berhasil pada seluruh lapisan log.
  4. Inventarisasi secret dalam .env dan environment proses: kata sandi basis data, API key, session secret, token CI/CD, webhook secret, kredensial registry, dan kunci layanan cloud.
  5. Rotasi kunci atau token AWS dan Azure yang mungkin terbaca, cabut nilai lama, akhiri sesi bila didukung, lalu periksa audit log untuk penggunaan yang tidak dikenal.
  6. Tinjau state Terraform dan berkas Infrastructure as Code terkait; rotasi nilai rahasia di dalamnya dan periksa perubahan resource yang tidak diotorisasi.

Kredensial berhak tinggi dan berumur panjang patut diprioritaskan, tetapi rotasi tetap harus memperhitungkan ketergantungan layanan. Membuat kunci baru tanpa mencabut kunci lama tidak menghilangkan akses dari salinan yang mungkin telah bocor.

Status insiden tidak dapat ditentukan dari versi saja

Bukti terbuka mengonfirmasi pemindaian otomatis terhadap endpoint Vite yang terekspos, eksploitasi aktif, rentang versi terdampak, dan tersedianya pembaruan. Bukti itu tidak berarti setiap instalasi Vite dapat dijangkau atau setiap probe berhasil mengambil rahasia.

Bagi tim yang tidak pernah membuka development server ke jaringan yang tidak dipercaya, pembaruan dan verifikasi pembatasan jaringan dapat menjadi respons yang memadai. Bagi tim yang pernah mengekspos versi rentan, status insiden baru dapat dipersempit melalui log permintaan, daftar berkas yang mungkin dilayani, inventarisasi secret, serta audit pemakaian kredensial pada layanan cloud dan sistem terkait.

Baca juga:

Bagikan:

Berlangganan buletin kami

Dapatkan berita Web3, AI, dan kripto terbaru langsung di kotak masuk Anda.

0