CVE-2026-61500: Kunci Penandatangan Sesi yang Dapat Diprediksi di Rejetto HFS

Rejetto HFS 3.0.0–3.2.0 menggunakan nilai turunan Math.random() untuk penandatanganan sesi dan login. Horizon3 menyatakan kebocoran memungkinkan pemalsuan sesi; VulnCheck menyebut aktivitas eksploitasi teramati sejak 1 Oktober. Tingkatkan ke 3.2.1 atau lebih baru; kompromi terhadap korban tertentu belum dikonfirmasi.^{[1], [4], [5]}

💡 Penjelasan Sederhana (ELI5)

Tanda tangan cookie seperti segel lilin pada kartu akses administrator. HFS membuat rahasia segel dari urutan angka yang dapat diprediksi, sementara proses masuk memperlihatkan angka lain dari urutan yang sama. Jika rahasianya dapat ditebak, segel bisa dipalsukan. Patch beralih ke keacakan kriptografis Node.js.^{[1], [3]}

Konsep Kunci & Istilah

Kunci penandatangan sesi: Rahasia yang digunakan Koa untuk menandatangani cookie sesi agar perubahan dapat terdeteksi.^{[1], [3]}
Math.random(): API pseudorandom umum yang tidak cocok untuk membuat rahasia kriptografis.^{[6], [4]}
CWE-338: Penggunaan generator angka pseudorandom yang lemah secara kriptografis; kelemahan yang dipetakan dalam catatan CVE.^{[1], [6]}
Status PRNG: Status internal yang menentukan keluaran pseudorandom berikutnya. Jika generator yang sama digunakan untuk rahasia dan nilai yang dapat diamati, hubungan di antaranya dapat terungkap.^[4]
Konteks penemuan: Horizon3 menyatakan bahwa sistem riset multiagen yang dibantu Mythos menemukan dan memvalidasi rantai kerentanan HFS ini. Ini menjelaskan cara peneliti menemukannya; ini bukan kerentanan pada Mythos atau bukti serangan AI otonom terhadap instalasi HFS nyata.^[4]

Pemetaan kerangka kerja

Referensi CWE untuk kelemahan yang dijelaskan dalam panduan ini: CWE-338

Analisis Akar Masalah (Root Cause)

Catatan CVE menyebut HFS 3.0.0 hingga 3.2.0 dan memetakan CWE-338. Pada commit upstream 59472e5, kode rentan memberikan [randomId(30)] kepada Koa; randomId() menggunakan Math.random(). Perbaikannya mengganti nilai itu dengan [randomBytes(32).toString('base64url')] dari node:crypto. Commit yang sama juga mengganti ID jabat tangan masuk publik dari Math.random() menjadi randomUUID(). Horizon3 melaporkan bahwa respons masuk yang dapat diakses tanpa autentikasi membocorkan cukup banyak keluaran terkait untuk memulihkan status PRNG V8 dan memperoleh kunci penandatangan cookie. Sesi administrator palsu dapat mencapai fungsi administrasi bawaan HFS dan berujung pada eksekusi kode di server. Artikel ini menjelaskan rantai tersebut secara umum tanpa solver, permintaan, atau payload. VulnCheck menyatakan Canary Intelligence mulai mengamati aktivitas eksploitasi pada 1 Oktober 2026, sebagaimana dilaporkan pada 2 Oktober; telemetri ini tidak mengidentifikasi instalasi HFS yang disusupi.^{[1], [3], [4], [5]}

Alur Serangan Langkah demi Langkah

Langkah 1

Versi HFS yang rentan dapat dijangkau

Rentang yang terdampak adalah HFS 3.0.0 hingga 3.2.0. Metrik CVSS menunjukkan akses jaringan tanpa hak istimewa sebelumnya.^{[1], [2]}

Langkah 2

Satu urutan acak lemah memiliki dua fungsi

HFS menurunkan kunci penandatangan dari Math.random(), sementara alur masuk membocorkan keluaran terkait. Rahasia kriptografis tidak boleh berasal dari PRNG umum yang dapat diprediksi atau diamati.^{[1], [3]}

Langkah 3

Kelemahan melewati batas kepercayaan sesi

Menurut Horizon3, keluaran tersebut memungkinkan pemulihan status PRNG sehingga tanda tangan sesi dapat dipalsukan untuk memperoleh akses administrator. Prosedur pemulihan terperinci tidak disertakan.^[4]

Langkah 4

Akses administrator dapat menuju eksekusi kode server

Horizon3 menjelaskan rantai dari sesi palsu ke fitur server_code HFS. VulnCheck menyatakan Canary Intelligence mulai mengamati aktivitas eksploitasi pada 1 Oktober 2026 dalam laporan 2 Oktober; telemetri tersebut tidak membuktikan kompromi pada instalasi tertentu.^{[4], [5]}

Kode Sumber: Rentan vs Aman

Cuplikan ini sesuai dengan commit upstream yang sebenarnya. randomBytes(32) menyediakan 256 bit dari modul kriptografi Node.js untuk kunci; randomUUID() mengganti sumber ID masuk publik. Rahasia untuk mengautentikasi sesi harus berasal dari sumber kriptografis dan tidak bergantung pada keluaran PRNG aplikasi yang dapat diamati. Perbarui ke HFS 3.2.1 atau versi dukungan yang lebih baru; cuplikan ini menjelaskan perubahan, bukan patch mandiri. Ini hanya mengamankan nilai fallback yang dibuat otomatis: jika COOKIE_SIGN_KEYS dikonfigurasi, setiap kunci yang diberikan juga harus dibuat secara terpisah dengan randomness kriptografis, disimpan sebagai rahasia, dan dirotasi jika terekspos.^{[3], [1]}

Cuplikan sumber: src/index.ts (kunci penandatangan cookie) dan src/api.auth.ts (ID handshake login, commit upstream 59472e5)

IMPLEMENTASI RENTAN

import { httpStream, randomId } from './misc'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
  || [randomId(30)]
export const app = new Koa({ keys })

const sid = Math.random()

PERBAIKAN AMAN & KUAT

import { randomBytes, randomUUID } from 'node:crypto'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
  || [randomBytes(32).toString('base64url')]
export const app = new Koa({ keys })

const sid = randomUUID()

Daftar Periksa Penguatan Sistem Rekayasa

✓Perbarui HFS 3.0.0–3.2.0 ke 3.2.1 atau lebih baru; utamakan rilis stabil terbaru yang masih didukung.^{[2], [1]}
✓Inventarisasi semua instance HFS, termasuk host Windows, kontainer, server uji, dan berbagi berkas yang terbuka ke internet; catat versi dan eksposurnya.^[4]
✓Jika belum dapat segera memperbarui, batasi akses ke jaringan tepercaya dan hilangkan akses publik sambil menyiapkan pembaruan. Langkah ini mengurangi eksposur, tetapi tidak memperbaiki pembuatan kunci yang lemah.^[4]
✓Setelah memperbarui instance yang dapat diakses publik saat masih rentan, batalkan semua sesi yang ada dan rotasi COOKIE_SIGN_KEYS yang dikonfigurasi; jika investigasi menemukan aktivitas admin tanpa izin, rotasi juga kredensial admin. Simpan log untuk ditinjau.^{[1], [4]}
✓Anggap pemindaian yang teramati sebagai alasan untuk menyelidiki, bukan bukti kompromi. Simpan log dan cari perubahan konfigurasi atau eksekusi kode yang tidak sah.^{[5], [4]}
✓Untuk aplikasi Node.js, pastikan setiap nilai COOKIE_SIGN_KEYS yang dikonfigurasi dibuat secara terpisah dengan randomness kriptografis, dijaga kerahasiaannya, dan dirotasi jika terekspos; fallback aman tidak memvalidasi nilai override. Untuk rahasia lain, gunakan API node:crypto seperti randomBytes(). Jangan membuat kunci penandatanganan, token reset, atau nilai otorisasi dari Math.random().^{[3], [6]}