Pada 5 Agustus 2026, para peneliti dari Novee yang dipimpin Lidor Ben Shitrit mempresentasikan riset di Black Hat USA yang mengungkap dua belas kerentanan di empat platform Java enterprise, termasuk dua rantai kritis yang memungkinkan eksekusi kode di server tanpa login sama sekali, yaitu di platform alur kerja Bonita BPM dan di Apache OFBiz, ERP open source. Pelajaran praktis bagi setiap pemilik bisnis: sistem yang Anda anggap terlindungi karena bersifat internal dapat dijangkau dengan dua permintaan browser jika sistem itu terekspos dan belum di-patch. Perlindungan yang sesungguhnya dimulai dengan inventarisasi apa yang Anda jalankan dan rutinitas patching, bukan dengan kepercayaan pada batas jaringan.

Apa yang sebenarnya ditemukan para peneliti

Riset ini tidak dibangun di atas satu bug yang spektakuler. Riset ini dibangun dengan menggabungkan kesalahan middleware yang kecil dan umum: perbedaan cara URL diurai, perlindungan yang tidak lengkap di lapisan penanganan permintaan, kunci kriptografi yang ditanam langsung (hardcoded) di kode sumber, dan evaluasi template yang tidak aman. Secara terpisah, tidak satu pun terlihat berbahaya, dan justru itulah sebabnya kesalahan-kesalahan ini lolos dari tinjauan kode dan dicatat sebagai prioritas rendah. Jika dirangkai, semuanya menghasilkan jalur lengkap dari pengunjung anonim hingga eksekusi perintah di server. Dari dua belas kerentanan tersebut, empat bekerja sebelum autentikasi dan satu menembus isolasi di dalam sandbox eksekusi.

Rantai BadBonita: tiga titik lemah menghasilkan satu pembobolan penuh

Rantai pertama memengaruhi Bonita BPM versi 10.4.3. Rantai ini dimulai dengan bypass autentikasi yang dibangun dari tiga kelemahan yang saling terkait: path traversal menggunakan notasi ..;, filter keamanan yang mencocokkan berdasarkan substring alih-alih path lengkap, dan logika penerusan permintaan internal. Hasilnya, sebuah permintaan mencapai API internal yang seharusnya tidak pernah terlihat oleh siapa pun dari luar. API tersebut menerima XML yang tidak tepercaya dan meneruskannya langsung ke pustaka XStream, yang melakukan deserialisasi, dan melalui rantai gadget Commons Collections yang sudah dikenal luas, jalur ini berakhir dengan perintah Groovy yang berjalan di server.

Perhatikan bahwa tidak satu pun langkah ini memerlukan kata sandi yang bocor, rekayasa sosial, atau akses sebelumnya. Yang dibutuhkan penyerang hanyalah sistem yang dapat dijangkau melalui jaringan.

OFBiz: kunci penandatanganan yang dipublikasikan di repositori terbuka

Masalah kedua, yang dilacak sebagai CVE-2026-31986 dan dinilai kritis, memengaruhi Apache OFBiz versi 24.09.05 ketika single sign-on diaktifkan. Masalahnya, kunci penandatanganan bawaan berada di kode sumber yang dipublikasikan secara terbuka, dan karena banyak instalasi membiarkan pengaturan bawaan tanpa diubah, penyerang dapat memalsukan token SSO yang sah atas nama akun administrator. Dari sana, permintaan melewati daftar larangan (denylist) yang mencoba memblokir kata-kata seperti java, process, dan import, tetapi daftar itu peka huruf besar-kecil dan hanya memeriksa pola tertentu, sehingga mengubah huruf besar-kecil satu huruf atau menggunakan nama kelas alternatif yang diimpor otomatis sudah cukup untuk lolos. Hasil akhirnya: dua permintaan GET tanpa autentikasi sudah cukup untuk mencapai eksekusi kode di instalasi mana pun yang menjalankan SSO.

Mengapa ini penting khususnya bagi Anda

Karena keduanya bukan alat pinggiran. OFBiz adalah ERP open source yang digunakan banyak perusahaan untuk menjalankan inventaris, pengadaan, dan penagihan, sedangkan Bonita adalah mesin alur kerja yang menggerakkan persetujuan dan prosedur internal. Siapa pun yang mencapai kedua tempat itu tidak sekadar membaca data, ia berdiri di tengah siklus operasional Anda: pesanan pembelian, harga pemasok, catatan karyawan, riwayat pelanggan. Para peneliti melaporkan bahwa kedua vendor merilis versi perbaikan dalam jangka waktu pengungkapan standar sembilan puluh hari, yang berarti pembaruannya sudah ada dan tanggung jawab kini berada pada pihak yang mengoperasikan sistem, bukan pihak yang membangunnya.

Kesenjangan nyata di pasar bukanlah ketiadaan patch, melainkan ketiadaan inventaris. Banyak organisasi tidak memiliki daftar terkini tentang apa yang sebenarnya mereka jalankan, di versi berapa, dan di domain mana. Akibatnya, salinan staging lama tetap tergantung di subdomain yang terlupakan selama dua tahun dan menjadi pintu yang tidak pernah terpikirkan oleh siapa pun.

Apa yang harus dilakukan minggu ini

  • Inventarisasi sistem Anda: daftar tertulis setiap sistem yang Anda jalankan, versinya, apakah terekspos ke internet, dan siapa penanggung jawabnya berdasarkan nama.
  • Perbarui Bonita dan OFBiz ke rilis yang sudah diperbaiki segera jika Anda menjalankan salah satunya, dan baca halaman keamanan resmi Apache sebelum melakukan upgrade.
  • Ganti setiap kunci enkripsi atau penandatanganan bawaan yang disertakan dengan produk. Nilai apa pun yang tercetak di dokumentasi bukanlah rahasia.
  • Tutup gerbang admin dari internet terbuka dan akses melalui jaringan privat atau daftar izin alamat yang singkat.
  • Nonaktifkan salinan staging lama dan subdomain yang tidak digunakan. Keduanya adalah sasaran termudah dan paling jarang dipantau.
  • Aktifkan pencatatan akses (access logging) dan simpan log-nya. Tanpa log, Anda tidak akan bisa menjawab di kemudian hari apakah ada orang yang masuk sama sekali.

Pelajaran rekayasa: jaringan internal bukanlah batas keamanan

Rekomendasi terpenting yang lahir dari riset ini adalah bahwa perutean internal harus diperlakukan dengan kontrol setingkat internet. Gagasan lama bahwa apa pun di balik firewall itu aman telah gagal dalam praktik: satu celah bypass autentikasi mengubah setiap endpoint internal menjadi publik. Dari sini lahir tiga aturan rekayasa, dan aturan ini layak masuk ke standar pengembangan Anda:

Jangan pernah mengandalkan daftar larangan untuk melindungi operasi yang berbahaya. Jika evaluasi ekspresi tidak diperlukan di suatu jalur kode, hapus sepenuhnya alih-alih mencoba menyaringnya.

Aturan kedua adalah jangan pernah menggantungkan operasi sensitif pada flag pengaturan atau preferensi pengguna yang dapat diubah dari dalam sistem. Aturan ketiga adalah mengaudit logika filter autentikasi untuk setiap pencocokan substring, karena itulah kesalahan yang paling sering berulang dan paling mudah dieksploitasi di kelas ini. Ketika kami membangun sistem bisnis baru di Origami, kami menerapkannya secara bawaan: otorisasi eksplisit di setiap endpoint, dan tidak ada kepercayaan yang diturunkan dari posisi permintaan di jaringan.

Sisi regulasi di Arab Saudi

Jika sistem yang dibobol menyimpan data pribadi individu di dalam Kerajaan, ini bukan lagi sekadar masalah teknis. Undang-Undang Pelindungan Data Pribadi (PDPL) mewajibkan pengendali untuk mengambil langkah yang diperlukan guna melindungi data tersebut dan melaporkan insiden yang memengaruhi privasinya. Otoritas Keamanan Siber Nasional (NCA) menerbitkan kontrol esensial yang mencakup manajemen kerentanan, patching, dan manajemen aset, yang justru merupakan kontrol yang akan menghentikan rantai ini. Menjalankan versi lama suatu produk dengan kerentanan yang sudah diketahui dan sudah di-patch adalah posisi yang sulit dipertahankan dalam audit apa pun.

Aturan sederhananya: perlakukan pembaruan keamanan sebagai komitmen operasional bulanan dengan penanggung jawab dan tanggal, bukan sebagai tugas darurat yang dilakukan setelah insiden.

Sumber

  • Help Net Security — rincian rantai RCE tanpa autentikasi dan CVE-2026-31986: helpnetsecurity.com
  • Halaman keamanan resmi Apache OFBiz: ofbiz.apache.org/security.html
  • Otoritas Keamanan Siber Nasional (NCA) — kontrol dan kerangka regulasi: nca.gov.sa
  • Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA) — Undang-Undang Pelindungan Data Pribadi (PDPL): sdaia.gov.sa