CVE-2026-119618 Celah RCE pada Apache HTTP Server dan Mitigasinya

Software terdampak	Apache HTTP Server mod_http2; HTTP/2 aktif (h2/h2c).
Versi terdampak	Apache httpd 2.4.55–2.4.70; mod_h2 standalone 2.0.8–2.0.42.
Severity	Critical menurut Apache. Penilaian CVSS dan tingkat risiko build distro dapat berbeda.
Perbaikan	Apache HTTP Server 2.4.71 atau patch backport vendor. Mitigasi sementara: nonaktifkan HTTP/2.
Status riset	Lab: perbedaan header, memory corruption, dan crash. RCE belum direproduksi Ethic Ninja.

 

Ringkasan temuan

• Apache merilis perbaikan CVE-2026-119618 pada 11 November 2026. Kerentanan ini berada di modul mod_http2 pada Apache HTTP Server 2.4.55–2.4.70. Apache mengklasifikasikannya sebagai Critical karena berpotensi menyebabkan heap corruption hingga remote code execution (RCE). Perbaikan tersedia pada versi 2.4.71.
• Masalahnya berawal dari fungsi assign_headers(). Ketika request HTTP/2 tidak memiliki body tetapi menyertakan Content-Type tanpa Content-Length, Apache mencoba menambahkan Content-Length: 0. Sayangnya, header tersebut ditulis ke tabel milik koneksi yang dipakai bersama, bukan ke salinan header milik request.
• Penulisan itu dilakukan oleh worker thread pada saat connection thread juga dapat mengakses memory pool yang sama. Karena aksesnya tidak tersinkronisasi, terjadi race condition yang dapat berujung pada memory corruption.
• Dalam lab terisolasi, tim Ethic Ninja membandingkan Apache 2.4.70 dengan 2.4.71. Pada versi rentan kami mengamati perbedaan header yang diterima handler, disusul crash berulang saat pengujian concurrency. Dengan pola pengujian yang sama, versi patched tidak menunjukkan crash.
• Hal penting: yang berhasil kami buktikan adalah bug pemrosesan header, memory corruption, dan denial-of-service (DoS). RCE merupakan dampak yang dijelaskan advisory Apache dan riset eksternal, tetapi belum kami reproduksi secara independen.

Mengapa modul HTTP/2 bisa terdampak?

HTTP/2 memungkinkan banyak request berjalan bersamaan melalui satu koneksi. Pada Apache, mod_http2 membagi pekerjaan antara connection thread yang menangani komunikasi jaringan dan worker thread yang memproses request. Keduanya harus menggunakan area memory sesuai batas kepemilikannya.

Secara normal, worker menggunakan data dan memory pool milik request-nya sendiri. Masalah muncul ketika satu operasi di assign_headers() justru menulis ke struktur yang dimiliki koneksi utama. Jika dua thread mengubah struktur tersebut dalam waktu berdekatan, data internal Apache dapat rusak.

Risiko ini relevan pada deployment yang mengaktifkan HTTP/2 melalui h2 atau h2c. Namun, memakai Apache versi terdampak saja belum cukup untuk memastikan setiap server dapat dieksploitasi; konfigurasi modul, build vendor, dan jalur request tetap perlu diperiksa.

Root cause: header ditulis ke tabel yang salah

Dalam h2_request.c, fungsi assign_headers() sudah membuat salinan header khusus untuk request melalui r->headers_in. Sebagian besar operasi kemudian menggunakan salinan tersebut. Namun, pada satu kondisi, Content-Length: 0 justru ditambahkan ke req->headers, yaitu tabel yang masih terkait dengan koneksi.

cl = apr_table_get(req->headers, "Content-Length");
if (no_body) {
    if (!cl && apr_table_get(req->headers, "Content-Type")) {
        /* request tanpa body: tegaskan panjang nol */
        apr_table_setn(req->headers, "Content-Length", "0");
        /*                   ^^^ SALAH: tabel SHARED koneksi,
                        harusnya r->headers_in (klon privat) */
    }
}

Patch Apache memperbaiki bagian ini dengan mengalihkan penulisan dari req->headers ke r->headers_in. Perubahan terlihat sederhana—hanya mengganti tujuan penulisan—tetapi penting untuk menjaga agar worker tidak memodifikasi data bersama di luar kendalinya. Perbandingan kode dapat dilihat pada Gambar 8.

Kesalahan tersebut menimbulkan dua gejala. Pertama, handler bisa tidak menerima Content-Length: 0 yang seharusnya ditambahkan. Kedua, pada kondisi concurrency tertentu, perubahan tabel header dapat memicu alokasi memory dari pool yang sedang dipakai thread lain, lalu menyebabkan corruption dan crash.

Bagaimana kerentanan ini dipicu?

Jalur masalah dimulai dari request HTTP/2 tanpa body dengan kombinasi header tertentu. Saat Apache menambahkan Content-Length secara otomatis, versi rentan dapat menulisnya ke tabel yang salah. Dalam pengujian sederhana, hal ini terlihat sebagai perbedaan nilai header yang diterima handler.

Untuk menjaga pengujian tetap aman, kami membandingkan respons sebuah endpoint diagnostik milik lab pada build sebelum dan sesudah patch. Pada 2.4.70, Content-Length sintetik tidak sampai ke handler; pada 2.4.71, handler menerimanya dengan nilai 0. Ini merupakan indikasi perilaku kode yang berbeda, bukan pembuktian RCE.

Crash memerlukan kondisi concurrency tambahan. Dalam lab, kami mengamati bahwa peluang munculnya race condition berkaitan dengan perubahan ukuran tabel header dan aktivitas alokasi memory ketika beberapa stream diproses bersamaan.

• Ketika tabel header membutuhkan alokasi memory tambahan, operasi pada worker thread dapat bertabrakan dengan aktivitas connection thread. Kondisi ini menjelaskan mengapa request biasa tidak selalu menyebabkan crash meskipun kode rentannya tetap ada.
• Pola request dan timing memengaruhi apakah jalur kode rentan terlewati. Karena sifatnya race condition, pengujian perlu memakai pembanding yang jelas, bukan menyimpulkan server aman hanya karena satu atau dua request tidak menyebabkan crash.
• Untuk artikel publik ini, rincian kombinasi frame, jumlah header, dan pengaturan traffic yang digunakan untuk meningkatkan peluang crash tidak disertakan. Fokus kami adalah menjelaskan root cause dan bukti hasil lab.

Dengan demikian, masalahnya bukan pada shellcode di request body. Akar kerentanannya berada pada cara Apache memproses header dan mengelola memory saat sejumlah stream HTTP/2 berjalan bersamaan.

Lingkungan dan metode pengujian

Lab dijalankan pada Apple Silicon menggunakan dua container Apache: httpd 2.4.70 sebagai target rentan dan 2.4.71 sebagai kontrol patched. Keduanya memakai konfigurasi HTTP/2 yang sebanding, dengan endpoint diagnostik sederhana untuk memeriksa Content-Length. Pengujian selanjutnya mengamati stabilitas proses dalam kondisi concurrent request.

Gambar 2. Banner kedua server. Catatan penting: banner modul tetap v2.0.42 di keduanya — versi modul bukan penanda patch untuk build 2.4.x.

Bukti 1 — perbedaan Content-Length sebelum dan sesudah patch

Pada Apache 2.4.70, endpoint diagnostik tidak menerima Content-Length: 0 yang seharusnya ditambahkan oleh modul HTTP/2. Sebaliknya, pada 2.4.71 nilai tersebut terlihat. Hasil tiga percobaan yang konsisten dapat dilihat pada Gambar 3. Temuan ini mendukung analisis bahwa penulisan header sebelumnya menuju tabel yang salah.

Gambar 3. Oracle curl di kedua server: CL=[unset] vs CL=[0], konsisten 3 percobaan.

Bukti 2 — crash berulang pada versi rentan

Saat pengujian concurrency berlangsung selama 30 detik, Apache 2.4.70 mencatat 74 crash pada child process, termasuk SIGSEGV dan SIGABRT. Pada sesi pengujian terpisah, jumlah crash tercatat 129 dan 133. Angka tersebut merupakan observasi pada konfigurasi lab kami, bukan estimasi tingkat keberhasilan pada server produksi.

Gambar 4. Run 30 detik di 2.4.70: 74 crash anak + SIGABRT. Blok bawah: efek sekunder yang ikut kami amati — mod_cgid pada 2.4.70 mencari body hantu karena CL:0 tidak pernah sampai ke handler.

Bukti 3 — pengujian kontrol pada versi patched

Dengan pola pengujian sebanding dan volume traffic lebih besar, Apache 2.4.71 tidak menunjukkan crash maupun koneksi rusak dalam sesi tersebut. Hasil ini mendukung efektivitas patch terhadap skenario yang diuji, meskipun tidak membuktikan bahwa seluruh kemungkinan kerentanan telah hilang.

Gambar 5. Kontrol A di 2.4.71: 0 crash.

Kontrol kedua dilakukan pada Apache 2.4.70 dengan salah satu kondisi pemicu dihilangkan. Hasilnya tidak ditemukan crash. Perbandingan ini memperkuat dugaan bahwa masalah berkaitan dengan jalur assign_headers(), bukan semata-mata karena tingginya traffic.

Gambar 6. Kontrol B di 2.4.70 tanpa Content-Type: 0 crash dari 62 580 stream.

Bukti 4 — anomali HTTP/2 dari sisi client

Sebelum sejumlah child process berhenti, client mencatat error protokol seperti Incomplete Huffman string dan cannot receive data before headers. Ini konsisten dengan kemungkinan respons yang terkorupsi selama proses server bermasalah. Namun, pesan client saja tidak cukup untuk memastikan exploitability RCE.

Gambar 7. Tanda koneksi terkorupsi dari sisi klien pada run 2.4.70.

Patch resmi: perubahan kecil, dampak besar

Gambar 8. Commit 824beab: satu token berubah, req->headers menjadi r->headers_in.

Dampak, prasyarat, dan batasannya

• Eksploitasi berpotensi dilakukan dari jaringan tanpa autentikasi apabila layanan Apache menjalankan versi dan konfigurasi mod_http2 yang terdampak. HTTP/2 harus aktif dan jalur pemrosesan header rentan perlu tercapai. Tidak semua deployment Apache memiliki risiko yang sama.
• Pengujian Ethic Ninja membuktikan perbedaan penanganan header, crash child process, dan indikasi memory corruption. Kami belum membuktikan pengambilalihan server atau menjalankan perintah melalui CVE ini. Status RCE dalam artikel merujuk pada penilaian Apache dan riset keamanan eksternal.
• Pada sistem produksi, proxy atau CDN dapat mengubah maupun membatasi request sebelum mencapai Apache. Hal ini bisa memengaruhi exploitability, tetapi tidak boleh dianggap sebagai pengganti patch. Batas header yang diterapkan di edge juga perlu dievaluasi.
• Severity dapat berbeda antarproduk. Apache menilai kerentanan ini Critical, sedangkan Red Hat memberi penilaian Important untuk lingkungan tertentu berdasarkan karakteristik packaging dan alokasi memory. Administrator perlu mengikuti advisory distribusi yang digunakan.
• Saat penyusunan artikel pada 13 November 2026, kami belum memiliki konfirmasi eksploitasi aktif di dunia nyata atau pencantuman di CISA KEV. PoC publik telah dilaporkan tersedia, tetapi keberadaan PoC bukan bukti serangan aktif.

Mitigasi dan langkah pemeriksaan

• Langkah utama adalah upgrade ke Apache HTTP Server 2.4.71 atau paket distro yang sudah menyertakan backport perbaikan. Bila patch belum dapat diterapkan, nonaktifkan sementara h2/h2c dan gunakan HTTP/1.1 sesuai kebutuhan layanan. Uji perubahan ini di staging karena bisa memengaruhi performa dan kompatibilitas client.
• Pantau error_log untuk crash child process seperti SIGSEGV atau SIGABRT, terutama jika disertai lonjakan error HTTP/2 atau respons protokol yang tidak normal. Gejala ini bukan bukti pasti eksploitasi, tetapi cukup untuk memicu investigasi.
• Untuk memastikan status patch, identifikasi versi httpd dan paket vendor yang digunakan. Perbedaan perilaku Content-Length yang kami tunjukkan di lab dapat membantu analisis pada endpoint milik sendiri, tetapi jangan dijadikan satu-satunya indikator kerentanan pada server produksi. Hindari stress test di sistem aktif.
• Jika server sebelumnya terekspos, telaah log crash, restart berulang, aktivitas child process, koneksi keluar yang tidak biasa, dan perubahan file yang tidak dikenal. Investigasi perlu mempertimbangkan bahwa crash tidak otomatis berarti RCE telah terjadi.

Pelajaran dari pengujian

• Kerentanan ini menunjukkan bahwa kesalahan kecil dalam memilih struktur data dapat menimbulkan dampak besar pada aplikasi multithreaded. Menulis ke tabel header milik koneksi, alih-alih salinan milik request, membuka risiko akses memory secara bersamaan.
• Pengujian kontrol sangat membantu menentukan akar masalah. Perbedaan sebelum/sesudah patch, ditambah penghilangan salah satu kondisi pemicu, menghasilkan bukti yang lebih kuat daripada hanya menunjukkan server crash.
• Pada lab, kami juga menemukan gejala pada mod_cgid ketika handler tidak menerima Content-Length yang semestinya. Temuan tambahan ini memperlihatkan bahwa satu bug dapat muncul sebagai beberapa gejala berbeda.
• Banner versi mod_http2 tidak selalu mencerminkan status patch pada build Apache yang dibundel distribusi. Karena itu, pemeriksaan harus mengutamakan versi paket dan advisory vendor, bukan hanya banner modul.
• Pelajaran terpenting bagi administrator adalah memadukan patch management dengan observasi perilaku aplikasi. Bagi peneliti, reproduksi yang baik perlu menjelaskan perbedaan antara anomali protokol, DoS yang teramati, dan RCE yang masih merupakan kemungkinan.

Referensi

• https://httpd.apache.org/security/vulnerabilities_24.html — advisory resmi + commit 824beab
•        https://www.cve.org/CVERecord?id=CVE-2026-119618 — record CVE (CNA Apache, CWE-362)
• https://www.wiz.io/blog/cve-2026-119618-rce-apache-http-server-vulnerability 
• https://github.com/googlesky/CVE-2026-119618 — PoC publik + lab TSan/ASan 
• https://access.redhat.com/security/cve/cve-2026-119618 — penilaian Red Hat (Important, allocator per-stream)

 

Pengujian dilakukan pada lab terisolasi Ethic Ninja. Screenshot menunjukkan hasil observasi lab; verifikasi independen menyeluruh atas raw log dan seluruh skenario eksploitasi berada di luar cakupan artikel publik ini.