Update Apache 2.4.69: 20 Kerentanan Web Server yang Tidak Seindah Judulnya

Sebuah toko kecil di Bekasi punya website di hosting cPanel, hosting yang dipakai bersama dengan 13 website lain. Pagi itu pemiliknya dapat pesan WhatsApp dari pelanggan: “Bang, kok website-nya berubah jadi situs judi?”

Tadi malam ia sudah melakukan hal yang sama seperti yang hampir semua orang lakukan. Masuk File Manager, cari file yang mencurigakan, hapus, logout. Homepage terlihat bersih. Pagi berikutnya file itu muncul lagi.

Yang tidak disadarinya, masalahnya bukan satu file. Di akun hosting yang sama ada 13 website lain. Kalau satu sudah ditembus, besar kemungkinan website lain ikut, karena ada shared memory yang sama dengan file.

Pada 1 Oktober 2026, Apache Software Foundation rilis Apache HTTP Server 2.4.69. Rilis ini menutup 20 kerentanan sekaligus. Dan ini bertepatan dengan pola yang saya lihat berulang di website UMKM: bukan satu komponen yang gagal, tapi beberapa lapisan yang tidak pernah ikut diperbarui.

Saya akan jelaskan dulu apa yang sebenarnya keluar di 2.4.69, karena di sini banyak berita online salah besar.

Fakta lebih dulu: tidak semua kerentanan itu serius

Ini bagian yang paling sering hilang di berita berbahasa Indonesia. Rilis 2.4.69 berisi 20 kerentanan, dan dalam advisory resmi Apache, kelimanya diberi label “moderate” dan lima belas lagi diberi label “low”. Tidak ada satu pun yang diberi label “critical” atau “important” di advisory ini.

Bandingkan dengan Mei 2026, ketika Apache 2.4.66 keluar dengan CVE-2026-23918 di mod_http2 yang diberi label “important” dan diberi skor CVSS 8.8. Itu kelas yang berbeda.

Jadi kalau Anda membaca judul berita “Apache Rilis Update untuk 20 Kerentanan” lalu langsung panik, itu reaksi yang berlebihan. Tidak ada laporan serangan aktif terhadap kerentanan ini. Yang perlu Anda lakukan adalah memperbarui, bukan panik.

Dua kerentanan yang punya jalur ke eksekusi kode

Dari 20 itu, dua yang paling layak diperhatikan karena keduanya punya jalur menuju eksekusi kode, meskipun dengan syarat yang sangat spesifik.

Yang pertama adalah CVE-2026-63292, di modul mod_vhost_alias. Ini overflow pada stack. Penyerang bisa memicu kerentanan ini dengan mengirim header Host yang panjangnya lebih dari 8.192 byte. Konsekuensinya bisa server crash, atau dalam kondisi tertentu, eksekusi kode.

Tapi syaratnya penting. VirtualDocumentRoot harus memakai format hostname, dan LimitRequestFieldSize harus dinaikkan di atas nilai bawaannya. Dua-duanya adalah konfigurasi yang tidak umum dipakai di shared hosting. Jadi kalau website Anda di cPanel atau LiteSpeed, kemungkinan besar Anda tidak punya konfigurasi yang rentan ini.

Yang kedua adalah CVE-2026-42356, soal penanganan CGI setelah internal redirect. File hasil redirect bisa dieksekusi sebagai CGI kalau sudah ada di folder yang mengaktifkan CGI dan tidak punya ekstensi yang dikenali mod_mime. Versi yang terdampak mulai 2.4.60 sampai 2.4.68. Ini diberi label low oleh Apache sendiri, karena syaratnya sangat sempit.

Kerentanan yang paling mungkin kena di website Anda

Kalau harus menebak mana yang paling mungkin relevan untuk website UMKM di Indonesia, saya akan memilih tiga hal.

Yang pertama, CVE-2026-57941 di mod_http2. Ini use-after-free dan memory write pada buffer bersama. Yang membuat ini penting bukan karena skornya, tapi karena HTTP/2 itu dipakai hampir semua website modern. Kalau Anda memakai CDN, kemungkinan besar website Anda sudah memakai HTTP/2 di depan. Saya akan jadi kandidat nomor satu yang perlu Anda perbarui.

Yang kedua, dua kerentanan WebDAV. Yang satu membuat proses anak server crash karena overflow pada shared lock. Yang satu lagi, CVE-2026-93546, lebih serius dari sisi data: klien yang punya akses tulis bisa mengirim permintaan PROPPATCH dengan banyak namespace XML, dan itu merusak database properti folder secara permanen.

WebDAV sendiri tidak umum dipakai di website UMKM. Tapi kalau Anda menyimpan file desain lewat WebDAV atau pernah memakainya untuk sinkronisasi, ini perlu diketahui.

Yang ketiga, CVE-2026-79768 di mod_userdir. Ini kebocoran informasi lewat ekuivalensi path. Modul ini dipakai untuk hosting banyak user di satu server, jadi di sini relevansinya tinggi untuk shared hosting.

Tabel singkat ini akan membantu Anda memutuskan mana yang perlu diperiksa lebih dulu:

Yang perlu Anda lakukan, tergantung Anda pegang hosting atau bukan

Ini bagian yang paling menentukan, dan tidak boleh dilewat: siapa yang sebenarnya bisa memasang versi 2.4.69 di website Anda.

Kalau Anda cuma pemilik hosting shared

Kabar baiknya, sebagian besar penyedia hosting sudah tangani ini di sisi mereka. Kalau Anda di cPanel, biasanya update sudah tersedia di EasyApache 4 dan sering sudah dijalankan otomatis. Yang perlu Anda lakukan biasanya bukan menjalankan update sendiri, tapi memastikan Anda tidak tertahan oleh kebijakan versi lama.

Yang bisa Anda lakukan sendiri tanpa akses server:

• Login ke panel hosting, cek bagian Updates atau Software. Kalau ada Apache atau EasyApache di sana, biarkan sistem yang menangani.
• Pastikan tidak ada batas update yang sudah lama aktif. Kadang akun shared hosting sengaja ditahan di versi lama, dan itu sering tidak disadari pemiliknya.
• Kirim tiket ke penyedia hosting dengan kalimat yang spesifik: minta konfirmasi versi Apache yang sedang dipakai akun Anda, dan apakah sudah di atas 2.4.69. Pertanyaan ini wajar, dan penyedia yang baik akan menjawab dengan nomor versinya.

Jangan accepting jawaban “sudah update” tanpa nomor versi. Itu jawaban yang tidak bisa Anda verifikasi.

Kalau Anda punya VPS sendiri

Di sini Anda memegang kendali penuh, dan langkah-langkahnya jelas.

Pertama, cek versi sekarang:

“ apache2ctl -v “

Kalau hasilnya masih 2.4.68 atau lebih rendah, proceed ke update sesuai distribusi yang Anda pakai. Untuk Ubuntu dan Debian:

“ sudo apt update sudo apt install --only-upgrade apache2 “

Untuk CentOS, AlmaLinux, atau Rocky Linux:

“ sudo dnf update httpd “

Kedua, setelah update, restart dan cek:

“ sudo systemctl restart apache2 apache2ctl -v “

Yang penting: setelah restart, pastikan website Anda masih hidup. Jika ada website di server itu yang memakai konfigurasi tidak biasa, restart bisa gagal. Karena itu, sebelum restart, jalankan tes konfigurasi lebih dulu:

“ sudo apache2ctl configtest “

Kalau hasilnya “Syntax OK”, aman untuk restart.

Kalau Anda tidak punya akses sama sekali

Ada kondisi ketiga yang sering terjadi: Anda cuma punya akun hosting, tanpa SSH dan tanpa izin update. Untuk kondisi ini, langkah yang bisa Anda lakukan terbatas tapi tidak nol.

Yang pertama, minta ke penyedia hosting lewat tiket. Cara Anda menulis menentukan kecepatan dibalas, jadi sebutkan tanggal rilis 1 Oktober 2026 dan minta konfirmasi nomor versi yang sedang dipakai.

Yang kedua, kalau Anda memang tidak bisa memastikan server sudah diperbarui, pindahkan lapisan keamanan ke tempat yang memang bisa Anda kendalikan. Firewall aplikasi web dari luar, seperti Cloudflare mode free, akan memblokir sebagian besar percobaan serangan sebelum mencapai server. Ini bukan pengganti update, tapi mengurangi risiko sementara Anda menunggu.

Yang bisa Anda lakukan selagi menunggu: matikan modul yang tidak dipakai

Ada langkah yang jarang disebut di berita, tapi berguna dan gratis. Mematikan modul yang tidak Anda pakai mengurangi permukaan serangan yang tidak perlu ada.

Sebelum mematikan modul, cek dulu. Di terminal server, jalankan:

“ sudo apache2ctl -M “

Itu akan menampilkan semua modul yang aktif. Sekarang bandingkan dengan yang benar-benar Anda pakai.

Kalau Anda tidak memakai WebDAV, mod_dav dan mod_dav_fs tidak perlu aktif. Kalau Anda tidak memproxy aplikasi Python, mod_proxy_uwsgi tidak perlu. Kalau Anda tidak memakai FTP sebagai proxy, mod_proxy_ftp juga tidak. Kalau Digest authentication sudah diganti Basic auth atau Forms auth di cPanel, mod_auth_digest juga bisa dimatikan.

Setiap modul yang dimatikan mengurangi satu permukaan serangan. Dan ini tidak menunggu update.

Satu hal yang perlu saya terus terang-terang sampaikan

Saya tidak bisa memberi tahu versi Apache di website Anda tanpa melihat server Anda secara langsung. Yang bisa saya pastikan dari sisi blog ini: antond.net sendiri berjalan di hosting Hostinger dengan PHP 7.4.33, dan Hostinger tidak menampilkan nomor versi Apache di header respons publik. Jadi ketika berita seperti ini datang, jangan pernah mengira versi server Anda pasti salah. Yang bisa dilakukan adalah memastikan lewat panel hosting atau tiket dukungan.

Penutup

Rilis Apache 2.4.69 adalah contoh klasik dari berita keamanan yang judulnya lebih menakutkan daripada isinya. Dua puluh kerentanan terdengar seperti angka yang besar, tapi menurut advisory resminya sendiri, tidak satu pun berlabel critical, dan tidak ada laporan serangan aktif.

Tapi “tidak kritis” bukan berarti “boleh diabaikan”. Ada dua alasan kenapa Anda tetap perlu memperbarui.

Pertama, ada banyak website di internet. Kalau website Anda salah satu dari ribuan yang target kompromi pada waktu yang sama, Anda jadi bagian dari statistik yang tidak Anda inginkan. Tidak ada gunanya jadi satu-satunya yang belum update di antara yang lain sudah aman.

Kedua, memperbarui Apache itu sendiri murah. Satu perintah, beberapa menit, dan tidak ada konsekuensi kalau Anda sudah tes konfigurasi lebih dulu. Bandingkan dengan biaya website yang tiba-tiba berubah jadi situs judi karena satu file dari theme yang sudah dua tahun tidak pernah diperbarui.

Kalau Anda tidak yakin posisi server Anda, langkah paling murah hari ini adalah mengirim satu tiket ke penyedia hosting dan meminta nomor versi Apache yang dipakai akun Anda. Balasan apa pun yang mereka beri, tapi pertanyaannya sendiri sudah bernilai, karena sering kali jawabannya menunjukkan update sudah lama tertahan tanpa ada yang menyadari.