Tim peneliti dari TrendAI Zero Day Initiative baru saja mengungkapkan salah satu kerentanan paling kritis yang pernah ditemukan di stack jaringan Windows. CVE-2026-47291 adalah kerentanan Remote Code Execution (RCE) di HTTP.sys, driver HTTP mode-kernel yang menjadi fondasi Internet Information Services (IIS) dan semua aplikasi Windows lainnya yang mendaftarkan URL prefix. Kerentanan ini disebabkan oleh sebuah integer overflow sederhana pada field 16-bit yang memungkinkan penyerang melakukan kernel pool heap overflow sebesar lebih dari 500 kilobyte tanpa autentikasi apapun. Microsoft telah merilis patch dalam siklus Patch Tuesday Juni 2026, namun dampak dari kerentanan ini sangat luas karena menyebar ke seluruh server Windows yang menjalankan layanan HTTP.
Yang membuat CVE-2026-47291 sangat istimewa dari sudut pandang riset keamanan adalah betapa sederhananya akar penyebabnya: satu baris kode yang melakukan penambahan angka 16-bit tanpa pengecekan overflow. Dalam dunia pemrograman kernel, kesalahan sekecil ini bisa memiliki konsekuensi yang sangat besar karena kode berjalan dengan privilege tertinggi di sistem operasi. Penulis kerentanan menunjukkan bahwa serangan ini bisa mencapai reliable kernel code execution melalui urutan TLS record yang terstruktur, memanfaatkan cara SChannel memproses data terenkripsi secara individual untuk menciptakan pemetaan satu-ke-satu antara TLS record dan buffer reference di parser HTTP.
Apa yang Terjadi? Memahami HTTP.sys dan Perannya
Untuk memahami mengapa kerentanan ini begitu berbahaya, perlu dipahami terlebih dahulu peran HTTP.sys dalam ekosistem Windows. HTTP.sys adalah driver mode-kernel yang menangani seluruh lifecycle permintaan HTTP masuk, mulai dari parsing request, caching response, hingga SSL/TLS termination. Driver ini mendengarkan di port TCP 80 (HTTP) dan 443 (HTTPS) secara default, dan memproses request HTTP/1.x serta HTTP/2 sepenuhnya di level kernel. Artinya, kerentanan di driver ini memberikan akses langsung ke kernel, bukan sekadar ke proses user-space seperti IIS worker process.
Ketika beroperasi di atas HTTPS, HTTP.sys mendelegasikan pemrosesan TLS ke Windows Secure Channel (SChannel) provider. Data TCP masuk didekripsi secara per-rekaman: setiap rekaman TLS adalah unit enkripsi independen yang didekripsi secara terpisah oleh SChannel dan disampaikan ke HTTP.sys sebagai buffer plaintext yang terpisah. Satu rekaman TLS 1.3 application data memiliki struktur yang mencakup ContentType, ProtocolVersion, panjang payload terenkripsi, dan payload terenkripsi itu sendiri. Yang krusial adalah bahwa payload yang sudah didekripsi dari setiap rekaman TLS disampaikan secara independen ke parser HTTP melalui fungsi UlHttpBufferReceiveEvent(), tanpa mempedulikan berapa banyak rekaman TLS yang ditumpuk oleh stack TCP menjadi satu segmen TCP.
Akar Penyebab: Integer Overflow pada 16-bit Capacity
Parser HTTP memelihara objek state per-request yang berisi buffer reference array yang tumbuh secara dinamis. Ada tiga field yang mengatur struktur ini: capacity (total slot yang dialokasikan, disimpan sebagai unsigned integer 16-bit pada offset 0x640), count (jumlah slot yang sedang digunakan, unsigned integer 16-bit pada offset 0x642), dan ref_array_ptr (pointer ke array buffer reference 8-byte yang dialokasikan di heap, pada offset 0x648). Integer overflow terletak di dalam routine buffer reference inline yang dipanggil oleh UlpParseNextRequest() setiap kali buffer receive baru dikonsumsi selama parsing header HTTP/1.x.
Ketika count mencapai capacity, routine menumbuhkan array dengan mengalokasikan buffer baru dengan lima slot tambahan. Ukuran alokasi baru dihitung sebagai 0x28 + capacity * 8; isi array lama disalin via memmove menggunakan count * 8 byte; dan capacity kemudian ditambah 5 sebagai unsigned integer 16-bit tanpa pengecekan overflow. Setelah 13.107 kejadian pertumbuhan, capacity mencapai 0xFFFB. Penambahan berikutnya menghasilkan 0x10000 yang terpotong menjadi 0x0000 dalam field 16-bit. Pada buffer reference berikutnya, count (sekarang 65.536 atau lebih) melampaui capacity nol, memicu pertumbuhan lagi. Perhitungan ukuran alokasi 0x28 + 0 * 8 menghasilkan alokasi 40 byte, tetapi memmove menyalin count * 8 byte, yaitu sekitar 524.256 byte, dari buffer lama ke alokasi 40 byte. Inilah kernel pool heap overflow sebesar lebih dari 500 KB.
Peran TLS sebagai Enabler Kritis
Salah satu aspek paling menarik dari kerentanan ini adalah bahwa TLS adalah syarat mutlak agar exploit bisa dilakukan. Ketika HTTP berjalan dalam mode plaintext tanpa enkripsi, stack TCP dan fungsi UlpMergeBuffers() menggabungkan beberapa indikasi receive sebelum data mencapai HTTP.sys. Akibatnya, setiap buffer reference mungkin mencakup banyak baris header, sehingga jumlah reference yang terakumulasi per request jauh lebih kecil dari yang diperlukan untuk mencapai overflow. Namun atas TLS, setiap rekaman didekripsi secara independen oleh SChannel dan disampaikan melalui UlHttpBufferReceiveEvent() ke UlpCopyIndicatedData(). Jika setiap rekaman TLS membawa tepat satu baris header lengkap (dihentikan oleh CRLF), parser HTTP mengkonsumsi buffer sepenuhnya tanpa menandai flag parse parsial, menyebabkan UlpAdjustBuffers() maju melalui jalur non-merge, yang berarti satu buffer reference terakumulasi per rekaman TLS yang dikirim.
Syarat Exploitasi dan Parameter Serangan
Untuk mengeksploitasi kerentanan ini, penyerang perlu mengirim sekitar 65.536 baris header HTTP/1.x yang masing-masing dikapsulasi dalam rekaman TLS 1.3 application data tersendiri, di atas koneksi HTTPS yang berkelanjutan. Dengan laju pengiriman 10 milidetik per rekaman, serangan membutuhkan waktu sekitar 11 menit untuk memicu overflow. Nilai registry MaxRequestBytes default (16.384 byte) mencegah eksploitasi pada sistem yang tidak dimodifikasi karena membatasi request hingga sekitar 4.000 baris header, yang jauh di bawah 65.536 yang diperlukan. Namun, server mana pun yang telah menaikkan batas ini ke 262.144 byte atau lebih akan terpapar. Microsoft memperbarui MaxRequestBytes default ke 65.535 pada Patch Tuesday Juni 2026 sebagai mitigasi tambahan.
Setiap baris header memiliki ukuran minimal sekitar 4 byte. Mengingat diperlukan 65.536 buffer reference untuk mencapai overflow, total ukuran request sekitar 262.144 byte. Ini berarti MaxRequestBytes harus dikonfigurasi minimal 262.144 byte agar server menerima request sebesar ini. Nilai registry default 16.384 byte membatasi request ke sekitar 4.000 baris header, yang tidak cukup untuk mencapai overflow. Mempertahankan MaxRequestBytes di bawah 65.535 byte adalah mitigasi paling konservatif yang tersedia pada sistem yang belum di-patch.
Dampak: Dari Blue Screen hingga Kernel Code Execution
Dampak minimum dari eksploitasi ini adalah Blue Screen of Death (BSoD) akibat akses memori yang tidak valid di context kernel. Namun, di bawah kondisi layout heap yang tepat, eksekusi kode kernel yang arbitrer dapat dicapai. Artinya penyerang bisa menjalankan kode apapun dengan privilege kernel, yang memberikan kendali penuh atas seluruh sistem operasi. Dalam konteks server Windows yang menjalankan IIS, ini berarti penyerang bisa membaca semua data yang diproses oleh server, memasang persistence mechanism, atau menggunakan server yang sudah dikompromikan sebagai pivot untuk serangan lateral ke seluruh jaringan organisasi.
Kerentanan ini hanya bisa dicapai melalui parsing header HTTP/1.x di atas koneksi TLS. HTTP/2 dan HTTP/3 menggunakan jalur parser berbeda yang tidak berinteraksi dengan buffer reference array. Parsing body data (Content-Length atau chunked transfer encoding) tidak menambah entri ke buffer reference array. Hanya parsing header yang memicu pertumbuhan buffer reference. Ini berarti server yang dikonfigurasi untuk menerima hanya HTTP/2 atau HTTP/3 tidak terpengaruh oleh kerentanan ini, meskipun mereka tetap harus di-patch sebagai langkah pencegahan.
Panduan Deteksi Serangan
Untuk mendeteksi serangan yang mengeksploitasi kerentanan ini, perangkat deteksi harus memantau dan meng-parse lalu lintas di port TCP 443. Karena seluruh lalu lintas di port ini terenkripsi TLS, perangkat harus mampu mendekripsi sesi sebelum menerapkan metode deteksi utama. Metode deteksi yang paling akurat memerlukan kemampuan untuk mendekripsi lalu lintas TLS, misalnya melalui TLS inspection, proxy dekripsi, atau memiliki kunci privat server. Metode ini mengamati indikator serangan secara langsung dan menghasilkan false positive serta false negative yang rendah.
Jika dekripsi tidak tersedia, perangkat harus menginspeksi pola rekaman TLS application data dalam sesi terenkripsi. Jika setiap rekaman TLS berisi payload pendek dan jumlah total rekaman semacam itu pada satu koneksi melebihi 1.000, lalu lintas harus dianggap mencurigakan. Heuristik ini beroperasi pada lalu lintas terenkripsi tanpa memerlukan dekripsi, namun lebih rentan terhadap false positive dan false negative. Sebagai pelengkap, monitoring durasi koneksi juga bisa digunakan sebagai heuristik pendukung karena serangan membutuhkan sekitar 11 menit koneksi berkelanjutan untuk mengakumulasi jumlah header yang cukup.
Dampak terhadap Infrastruktur Indonesia
Di Indonesia, ribuan server Windows menjalankan IIS dan berbagai layanan HTTP berbasis HTTP.sys. Sektor perbankan, pemerintahan, telekomunikasi, dan e-commerce sangat bergantung pada stack teknologi Windows untuk layanan web mereka. Banyak dari server ini telah menyesuaikan MaxRequestBytes untuk mengakomodasi request yang lebih besar demi performa, yangironisnya justru membuat mereka rentan terhadap kerentanan ini. Patch Microsoft Juni 2026 harus menjadi prioritas utama bagi setiap organisasi yang menjalankan Windows Server, terutama mereka yang mengekspos layanan HTTPS ke internet.
Selain itu, banyak organisasi Indonesia yang menjalankan multiple Windows Server di belakang load balancer atau CDN mungkin tidak menyadari bahwa seluruh server di belakang mereka berpotensi terpengaruh. Satu server yang belum di-patch bisa menjadi titik masuk bagi penyerang untuk mendapatkan akses kernel, yang kemudian bisa digunakan untuk kompromi seluruh cluster. Audit menyeluruh pada semua instance Windows Server yang mengekspos HTTP/HTTPS harus dilakukan segera, termasuk memeriksa nilai MaxRequestBytes di registry setiap server.
Rekomendasi Pertahanan
Langkah pertama dan paling kritis adalah menerapkan patch Microsoft Juni 2026 pada semua Windows Server yang terpengaruh. Ini adalah satu-satunya remediasi yang benar-benar lengkap. Semua mitigasi lainnya mengurangi paparan tetapi tidak menghilangkan kerentanan mendasar. Audit nilai MaxRequestBytes di semua host IIS dan HTTP.sys. Periksa HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters. Jika nilainya 65.536 atau lebih tinggi, sistem yang belum di-patch rentan terhadap serangan.
Deploy TLS inspection di perimeter jaringan. Metode deteksi paling andal memerlukan lalu lintas HTTP/1.x yang sudah didekripsi. Perangkat TLS inspection atau proxy dekripsi memungkinkan aturan header-count yang akurat, yaitu memblokir atau mengalert setiap request HTTP/1.x yang melebihi 1.000 baris header. Tempatkan instance IIS di belakang reverse proxy atau WAF yang memberlakukan batasan ukuran request dan jumlah header sebelum lalu lintas mencapai driver kernel. Pertimbangkan untuk menonaktifkan HTTP/1.x jika tidak diperlukan, karena jalur kode HTTP/2 dan HTTP/3 tidak terpengaruh oleh kerentanan ini.
Analisa Retasan
Kerentanan ini menjadi pengingat yang sangat keras bahwa pilihan tipe data di level kernel memiliki konsekuensi keamanan yang sangat serius. Satu missing overflow check pada field 16-bit di Windows HTTP.sys membuka jalan bagi penyerang remote tanpa autentikasi untuk merusak lebih dari 500 KB memori kernel pool melalui urutan rekaman TLS yang sederhana namun terstruktur. Yang paling ironis adalah bahwa konfigurasi default Windows sebenarnya aman, tetapi banyak administrator Windows yang menaikkan
MaxRequestBytesuntuk meningkatkan performa server tanpa menyadari bahwa mereka justru membuka pintu serangan.Dari perspektif keamanan siber Indonesia, temuan ini harus menjadi alarm bagi seluruh organisasi yang mengoperasikan Windows Server. Kerentanan di level kernel jauh lebih berbahaya daripada kerentanan di level aplikasi karena memberikan akses ke seluruh sistem operasi tanpa batasan. Tim keamanan harus memastikan bahwa patch management process berjalan efektif dan tidak ada server yang tertinggal. Selain itu, setiap perubahan konfigurasi performa harus dievaluasi dari sudut pandang keamanan sebelum diterapkan ke production. Sebuah tuning yang tampak tidak berbahaya seperti menaikkan batas request bisa menjadi perbedaan antara server yang aman dan server yang rentan terhadap kompromi total.
Sumber: core-jmp.org – CVE-2026-47291 | Penulis: Yazhi Wang dan Jonathan Lein, TrendAI Zero Day Initiative
