Pengelola server dan jaringan di instansi pemerintah punya agenda baru minggu ini. Pada 22 Oktober 2026, proyek TianoCore mengumumkan celah keamanan kritis di EDK II, basis kode sumber terbuka yang dipakai hampir semua vendor firmware UEFI. Celah dengan nomor CVE-2026-97631 ini diberi skor keparahan 9,5 dari 10. Yang diserang bukan Windows, bukan Linux, dan bukan aplikasi di dalamnya, melainkan firmware yang berjalan sebelum sistem operasi menyala.

Apa yang sebenarnya bocor

Masalahnya ada di driver PXE Base Code (NetworkPkg/UefiPxeBcDxe), komponen yang membuat server, perangkat penyimpanan, dan komputer bisa boot dari jaringan. Celah ini bukan kode baru: menurut laporan Ars Technica, ini buffer overflow berusia 16 tahun. Saat proses network boot berjalan, driver tersebut membuka permintaan penerimaan pesan error ICMP dan menyalin setiap pesan yang masuk ke sebuah kolom tetap berukuran 504 byte bernama Mode.IcmpError.

Pengelolaan batas salinan itulah yang salah, baik pada penangan IPv4 (PxeBcIcmpErrorDpcHandle) maupun IPv6 (PxeBcIcmp6ErrorDpcHandle). Pesan yang lebih panjang dari 504 byte tetap disalin, dan penunjuk tujuan maju berdasarkan panjang kumulatif, bukan panjang per fragmen. Akibatnya pesan berukuran besar menulis byte yang dikendalikan penyerang ke luar kolom tersebut, menimpa memori di sekitarnya. Tidak ada bagian lain di jalur penerimaan yang membatasi panjang pesan.

Siapa yang benar-benar berisiko

Kabar baiknya, cakupannya tidak seluas judul berita di luar negeri. Celah ini hanya relevan untuk perangkat yang memakai firmware berbasis EDK2 dan melakukan boot dari jaringan lewat PXE. Komputer, laptop, atau server yang selalu boot dari disk tidak terdampak. PC kerja di kantor desa, laptop guru, dan komputer administrasi yang menyala dari SSD-nya sendiri bukan sasaran celah ini.

Yang perlu waspada adalah organisasi yang memakai PXE untuk instalasi massal atau imaging: laboratorium komputer sekolah, ruang server, dan tim TI yang rutin men-deploy ulang puluhan perangkat. Perlu dicatat, fungsi PXE umumnya aktif secara default di banyak motherboard dan server. Vendor firmware besar seperti AMI, Insyde, dan Phoenix memakai EDK2 secara ekstensif, dan Project Mu, varian EDK2 buatan Microsoft, juga memakai komponen yang rentan. Intel menyatakan tidak ada produk komersialnya yang masih dalam dukungan keamanan yang diketahui terdampak, tetapi Intel juga mengingatkan bahwa fungsi EDK2 bisa diintegrasikan oleh vendor motherboard atau produsen sistem. Artinya, status aman atau tidak ditentukan oleh firmware yang dipasang pabrikan perangkat Anda, bukan oleh merek prosesornya.

Mengapa skornya tinggi

Kode berbahaya dijalankan pada tahap DXE, jauh sebelum sistem operasi mengambil alih, dan pada level hak paling tinggi di prosesor (ring 0). Pada titik itu, Secure Boot dan measured boot belum sempat memeriksa komponen sistem operasi. Payload akhir dari serangan ini memang tidak persisten, hanya berjalan sekali, tetapi cukup untuk menanam payload lain yang ikut berjalan setiap kali perangkat dinyalakan.

Serangan juga bisa berujung sederhana namun mengganggu: proses boot dibuat menggantung alias denial of service. Menurut advisory TianoCore, pemicunya cukup satu pesan error ICMP terarah (unicast) yang dikirim ke alamat IP perangkat sasaran saat perangkat sedang dalam proses PXE boot. Jadi pelakunya harus sudah punya jalur ke jaringan lokal tempat perangkat itu boot, misalnya penyusup di jaringan kantor, bukan sembarang orang dari internet.

Status perbaikan: tunggu vendor, bukan update OS

Perbaikan kode sudah diusulkan di repositori edk2 melalui pull request, dan advisory resmi TianoCore sudah dipublikasikan. Namun laporan menyebut advisory tersebut belum mencantumkan versi firmware yang sudah dipatch. Inilah bagian yang sering disalahpahami: memperbarui Windows, Linux, atau panel hosting tidak menambal celah ini, karena kodenya berada di firmware. Patch harus datang dari vendor firmware atau OEM perangkat Anda, dan itulah yang membuat pemulihannya lambat: jumlah perangkatnya jutaan dan tersebar di ribuan produsen.

Langkah mitigasi yang bisa dijalankan sekarang

1. Buat daftar perangkat yang memakai PXE. Periksa pengaturan boot di UEFI/BIOS setiap server dan PC. Catat mana yang urutan boot-nya mengaktifkan Network Boot atau PXE IPv4/IPv6.
2. Matikan network boot bila tidak dipakai. Nonaktifkan PXE di UEFI, taruh disk sebagai urutan pertama, lalu kunci pengaturan BIOS dengan password. Ini menutup jalur serangan sepenuhnya untuk perangkat tersebut.
3. Kalau PXE wajib, pisahkan jaringannya. Tempatkan server PXE dan perangkat yang di-imaging di VLAN khusus, batasi siapa saja yang boleh berada di segmen itu, dan jangan sambungkan segmen tersebut langsung ke jaringan pengguna umum atau internet. Aktifkan DHCP snooping dan port security di switch.
4. Ajukan ke vendor firmware. Siapkan merek, model, dan versi firmware tiap perangkat, lalu tanyakan status CVE-2026-97631 dan ketersediaan update. Uji update pada satu unit lebih dulu sebelum menyapu seluruh ruang server.
5. Jangan matikan Secure Boot dan TPM. Keduanya tidak menahan serangan ini karena kode berjalan lebih dulu, tetapi tetap lapisan pertahanan penting untuk ancaman lain. Matikan justru memperbesar risiko.
6. Pantau dan persempit. Awasi log DHCP/PXE dan tandai proses boot dari jaringan di luar jadwal imaging. Pembatasan ICMP di router bisa jadi pelengkap, tetapi bukan solusi utama karena penyerang yang sudah berada di jaringan lokal tetap punya banyak cara lain.

Artinya untuk instansi, desa, dan sekolah

Untuk sebagian besar instansi, dampak praktisnya kecil: komputer yang menyala dari disk sendiri tidak terpengaruh. Prioritas sebenarnya ada di dua tempat, yaitu ruang server yang memakai PXE untuk provisioning, dan laboratorium komputer yang rutin di-imaging massal. Kebiasaan yang paling sehat adalah menjadikan PXE sebagai fitur yang dinyalakan saat dibutuhkan, bukan fitur yang menyala terus tanpa pernah dipakai.

Celah ini juga pengingat yang lebih luas: firmware termasuk aset TI yang harus masuk inventaris. Selama ini audit biasanya berhenti di sistem operasi dan aplikasi, padahal firmware punya hak akses paling tinggi dan paling jarang diperbarui. Mulai sekarang, masukkan versi BIOS/UEFI ke dalam daftar aset bersama versi OS dan daftar plugin.

Sumber: Ars Technica — Code-execution flaw in UEFI firmware affects most servers on planet Earth (27 Oktober 2026); Advisory TianoCore EDK2 GHSA-99cj-7hg9-mp4m; Pull request perbaikan edk2 #13200.