CERT mengungkap CVE untuk 6 kerentanan keamanan kritis di dnsmasq

• CERT pada 11 Mei 2026 mengungkap sekumpulan CVE untuk 6 kerentanan keamanan kritis di dnsmasq
• Semua kerentanan ini merupakan bug lama, dan memengaruhi hampir semua versi dnsmasq kecuali versi yang sangat lama
• CVE tersebut telah diungkap lebih dulu kepada vendor, dan tiap vendor perlu mendistribusikan versi patch paket dnsmasq tepat waktu
• 2.92rel2, yaitu 2.92 dengan patch yang diterapkan pada rilis stabil dnsmasq, telah dibuat dan dapat diunduh dari lokasi unduhan yang sama seperti sebelumnya
• Tag dnsmasq-2.93rc1 akan segera dibuat, dan setelah pengujian ditargetkan rilis 2.93 dalam sekitar satu minggu

---

Pengungkapan kerentanan dan patch dnsmasq

• CERT pada 11 Mei 2026 mengungkap sekumpulan CVE untuk 6 kerentanan keamanan kritis di dnsmasq
• Semua kerentanan tersebut adalah bug lama, dan berlaku pada hampir semua versi dnsmasq kecuali versi yang sangat lama
• CVE telah diungkap lebih dulu kepada vendor, dan tiap vendor perlu mendistribusikan versi patch paket dnsmasq tepat waktu
• Detail dan patch dapat dilihat di https://thekelleys.org.uk/dnsmasq/CVE/
• 2.92rel2, yaitu rilis stabil dnsmasq 2.92 yang telah diberi patch, telah dibuat dan dapat diunduh dari lokasi unduhan yang sama seperti sebelumnya
• Commit perbaikan juga akan diunggah ke development tree pada waktu yang sama; sebagian menggunakan patch yang sama seperti backport, dan sebagian lainnya merupakan penulisan ulang yang lebih menyeluruh yang menangani akar penyebab

Peningkatan laporan berbasis AI dan rencana 2.93

• Dalam beberapa bulan terakhir, laporan bug dari riset keamanan berbasis AI meningkat tajam, sehingga banyak waktu tersita untuk deduplikasi dan klasifikasi bug
• Bug dibagi menjadi item yang memerlukan pengungkapan awal kepada vendor dan item yang lebih baik langsung diperbaiki setelah dipublikasikan, dan pembedaan ini tak terhindarkan bersifat subjektif
• Karena bug yang sama berulang kali ditemukan oleh banyak “good guys”, ada kemungkinan “bad guys” juga bisa menemukannya, sehingga embargo panjang dinilai tidak terlalu efektif
• Koordinasi embargo dan penyediaan backport membutuhkan banyak waktu dan upaya dari semua pihak yang terlibat
• Sebagian besar bug akan diperbaiki di rilis mendatang, dengan prioritas menjadikan rilis dnsmasq baru sebisa mungkin bebas bug
• Banyak commit perbaikan keamanan yang telah masuk ke repositori git dalam beberapa minggu sebelum pengumuman juga sejalan dengan arah ini
• Tag dnsmasq-2.93rc1 akan segera dibuat, dan targetnya adalah merilis versi stabil 2.93 secepat mungkin
• Pengujian release candidate sangat penting, jadi pengguna yang memungkinkan perlu mengujinya secepat mungkin
• Jika semuanya berjalan lancar, 2.93 bisa dirilis dalam sekitar satu minggu
• “Tsunami” laporan bug yang dihasilkan AI belum menunjukkan tanda-tanda akan berhenti, sehingga ada kemungkinan proses yang sama segera terulang lagi
• Ada ketegangan antara memasukkan sebanyak mungkin arus bug yang sedang berlangsung ke 2.93 dan merilisnya tepat waktu, dan prioritasnya ada pada rilis yang tepat waktu

[GN⁺]

Komentar Hacker News

• Sepertinya ini titik balik yang membuat migrasi kode yang ditulis dalam C ke bahasa yang aman terhadap memori menjadi makin mendesak
  Sebagian besar kerentanan yang ditemukan belakangan ini berkaitan langsung dengan bahasa yang tidak aman terhadap memori, dan tampaknya sangat sulit membenarkan bahwa server DNS/DHCP tidak bisa ditulis dalam Rust atau Go, kalau bisa tanpa unsafe

  • https://news.ycombinator.com/item?id=47943499 — ada kasus saat mencoba mengganti coreutils dengan implementasi Rust baru malah muncul 44 CVE. Tidak ada makan siang gratis
  • Masalahnya bukan bahasa, melainkan kurangnya talenta yang mau mengerjakan ini
    Para peneliti keamanan AI setidaknya memang melakukan sesuatu. Kalau menulis ulang semuanya dalam Rust semudah itu, seharusnya sehari setelah insiden seperti ini langsung muncul pengganti Rust yang kokoh
    Itu tidak terjadi karena pekerjaan seperti ini sulit mendapatkan bintang GitHub
  • Mungkin masalahnya adalah cara kita memandang memori dinamis
    Saya ragu apakah pendekatan “karena ukuran maksimumnya tidak diketahui, berarti semuanya harus dinamis” itu benar. Program mendeklarasikan ukuran maksimum input yang bisa diterima, lalu jika melewati batas mengembalikan error atau memakai ring buffer, bukanlah akhir dunia
    Jika ukurannya bisa diketahui, kita bisa merancang sesuai itu. RAM itu terbatas, jadi aneh rasanya semua lapisan di dalamnya dirancang seolah-olah tak terbatas
    Beralih ke Rust terlihat seperti pemborosan waktu yang sangat besar, dan tidak menyelesaikan masalah mendasar bahwa program tidak dimodelkan sesuai realitas sumber daya sistem yang terbatas. Ini juga bukan cuma soal memori. Kasus Chrome menaruh model 4GB di perangkat pengguna juga mirip
  • Saya tidak setuju. Perlindungan jelas membaik berkat agen AI yang mencari potensi kerentanan

• https://xchglabs.com/blog/dnsmasq-five-cves.html

• Saya penasaran apakah OpenWRT sudah merilis build baru, dan jawabannya belum, masih dikerjakan
  https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • DD-WRT juga sedang menangani ini
    https://github.com/mirror/dd-wrt/issues/465
    https://svn.dd-wrt.com/changeset/64944
    https://svn.dd-wrt.com/changeset/64905
    Rilisnya katanya “coming soon”

• MaraDNS saya telah diaudit cukup luas saat memasuki era audit keamanan berbantuan AI
  Sejak 2023, tidak ditemukan satu pun bug keamanan serius [1]
  Yang ditemukan auditor hanyalah hal-hal seperti “Deadwood butuh waktu lebih lama dari biasanya untuk membebaskan resource saat menerima paket aneh dalam mode rekursif penuh” [2], atau “utilitas pendamping yang disertakan dalam MaraDNS bahkan tidak bisa dikompilasi sejak 2022, tetapi memiliki buffer overflow hanya ketika $HOME melebihi 50 karakter” [3]
  Secara pribadi saya sangat puas bahwa MaraDNS tampak cukup aman sekarang karena mendapat audit keamanan yang benar-benar mendalam
  [1] https://samboy.github.io/MaraDNS/webpage/security.html
  [2] https://github.com/samboy/MaraDNS/discussions/136
  [3] https://github.com/samboy/MaraDNS/pull/137

  • Jika Lua 5.1 dijadikan library lalu dibundel dengan Lunacy alih-alih dimuat, dan itu pun versi 2012, kemungkinan besar juga terdampak oleh CVE-2014-5461 dan lainnya
    Lua juga bukan tidak pernah punya perbaikan keamanan
  • Meski begitu, MaraDNS jauh kurang populer daripada dnsmasq
    Saya juga punya beberapa library yang saya tulis sendiri, dan sejak 1991 tidak ada satu pun bug keamanan serius yang ditemukan. Tentu saja tidak ada yang memakai library saya
    Bukan untuk meremehkan pencapaian itu, tapi klaim seperti ini penting diberi konteks bersama seperti apa basis penggunanya
  • Dulu saat menyiapkan server DNS, saya senang menemukan MaraDNS alih-alih pendekatan dnsmasq yang “melakukan semuanya”, dan yang lebih penting, sejak itu saya tidak perlu memikirkannya lagi
  • Saya penasaran, tapi tidak paham apa yang ingin disampaikan di sini. Apakah maksudnya ada alternatif selain dnsmasq, atau perangkat lunak Anda entah bagaimana “lebih baik”?
    Promosi ini hampir tidak memberi nilai pada diskusi dnsmasq
    Semakin banyak perangkat lunak dipakai, semakin banyak pula ia ditinjau, dan semakin banyak bug serta kasus tepi yang ditemukan
  • Kerja bagus. Tapi tetap mengejutkan bahwa pada 2026 kita masih terus menulis tool jaringan inti dengan bahasa yang rapuh seperti C

• Untungnya software ini tidak dipakai di jutaan perangkat yang nyaris tidak pernah menerima pembaruan

  • Ketika vendor berkata “kami tidak bisa membiarkan Anda memakainya sesuka Anda”, bisa mengendalikan hardware sendiri memang hal yang baik
  • Sedikit melegakan bahwa dalam kebanyakan kasus ini berjalan di perangkat yang tidak akan mengirim paket sebelum klien terlebih dahulu mengautentikasi ke Wi-Fi atau terhubung secara fisik ke port Ethernet
  • Y2K26?

• Cukup serius
  “Penyerang jarak jauh yang dapat membuat kueri DNS atau memberikan respons DNS dapat menyebabkan penulisan di luar batas besar pada heap”
  Respons DNS yang salah dapat “menyebabkan loop tak terbatas sehingga dnsmasq tidak merespons kueri apa pun”
  Permintaan DHCP berbahaya dapat menyebabkan buffer overflow

• Tidak semua proyek mengalami tsunami laporan bug AI. Seperti disebut di atas, MaraDNS tidak mengalaminya
  Saya kira djbdns dan tinydns juga tidak. Kalau ada, pasti akan dipublikasikan besar-besaran
  Saya tidak pernah benar-benar paham mengapa beberapa proyek menjadi sangat populer sementara yang lain tidak
  Rasanya seperti alat yang “terlalu berbahaya untuk dipublikasikan” itu memindai semua proyek, tetapi hanya menghubungi secara selektif tempat yang memang bermasalah. Dengan begitu mereka tidak perlu mengakui bahwa alat mereka tidak menemukan apa-apa

  • Hal seperti itu memang terjadi pada proyek populer

• Saya tidak pernah suka memakai dnsmasq. Rasanya terlalu banyak hal dimasukkan ke dalam satu tool
  Saya selalu lebih suka mengonfigurasi resolver cache lokal, server DHCP, dan konfigurasi boot TFTP/PXE secara terpisah

  • Ada beberapa fitur dnsmasq yang bagi sebagian orang sulit digantikan
    Misalnya meneruskan kueri *.example.com ke server upstream tertentu, mengembalikan NXDOMAIN untuk situs phishing, atau menambahkan semua IP yang di-resolve dari *.example.org ke ipset untuk policy routing
    Fitur terakhir ini bahkan berjalan di FreeBSD meskipun BSD tidak punya ipset. Daftar *.example_xyz.com bisa sangat besar, dan dnsmasq belakangan ini dikenal menanganinya secara efisien
  • Pemikiran seperti itulah yang membuat saya lama dulu memakai MaraDNS untuk hosting DNS
    Nilainya 10 dari 10, tidak menyesal, dan layak direkomendasikan
  • Setuju. Ini juga terasa bertentangan dengan cara Linux “seharusnya” bekerja
    Misalnya Opnsense hanya memakai bagian DHCP dari dnsmasq dan memakai unbound untuk DNS, dan ini terasa agak “aneh”
  • Itu memang sampai tingkat tertentu adalah tujuannya. dnsmasq adalah paket aplikasi “menjalankan satu router kecil” dalam satu kotak
    DHCP dan DNS memang saling terhubung, dan PXE membutuhkan entri DHCP. Untuk membuat konfigurasi sederhana, kalau tidak begitu Anda harus merangkai setidaknya 3 daemon dengan sintaks konfigurasi yang berbeda-beda

• Ini pertanyaan pemula untuk orang yang lebih berpengalaman di bidang ini, tapi saya penasaran kenapa software di area ini tidak lebih banyak ditulis dengan runtime bahasa seperti Erlang yang punya garbage collection dan konkurensi

  • Rilis pertama dnsmasq adalah pada 2001. Pada masa itu daftar bahasa yang realistis untuk server jaringan berperforma tinggi tidak terlalu panjang, dan Erlang tidak termasuk di dalamnya
    Penalti performanya terlalu besar, runtime-nya terasa seperti kotak hitam yang sulit dinilai kestabilannya saat itu, kontributornya sedikit, dan jejak dependensinya juga besar karena tidak terpasang di kebanyakan sistem
    Bahkan ketika sekitar 2015 saya memakai Erlang di sistem produksi, masih ada bagian-bagian kasar kalau sedikit keluar dari use case yang memang dimaksudkan. Ini bukan kritik khusus terhadap Erlang, banyak bahasa dan runtime lain juga mirip
    Cukup banyak sistem yang akan terus terpukul selama beberapa minggu atau bulan ke depan juga punya latar belakang serupa. Untuk kernel Linux, alternatif potensial yang bisa dipilih saat itu paling banter C++. OpenSSL yang sering jadi langganan masalah keamanan dimulai pada 1998
    Saya sangat setuju dengan pernyataan “jangan menulis proyek baru yang punya akses jaringan dalam C”, tetapi kalau kembali ke 1998 sulit mengatakan pilihan lain apa yang benar-benar realistis
    Bahasa yang lebih aman memang ada, tetapi komunitasnya jauh lebih kecil daripada komunitas C dan lebih sulit memberi jaminan kestabilan. Java sudah ada, tetapi saya tidak tahu persis kapan ia menjadi kandidat serius untuk server jaringan, mungkin sekitar akhir 2000-an. Java yang saya lihat pada 1999 belum sampai ke sana
    Misalnya pada 2011 saya pernah menjalankan server jaringan Haskell untuk penggunaan yang relatif tidak penting, dan itu tumbang dalam kondisi yang untuk jaringan produksi sebenarnya tidak terlalu ekstrem. Ketika pada 2013 saya memakai ulang basis kode yang sama tanpa perubahan pada loop eksekusi intinya, hasilnya membaik sekitar 90%, jadi menurut saya itu lebih masalah di sisi Haskell daripada kode saya
    Itu tetap belum cukup baik untuk benar-benar dipakai di produksi, tetapi setidaknya menunjukkan bahwa yang gagal bukan kode saya. Artinya, walaupun Haskell sudah ada pada 2000-an, sulit melihatnya sebagai pilihan realistis untuk server jaringan pada masa itu
    Sekarang pilihannya jauh lebih banyak daripada dulu
  • Dalam C, biasanya cukup mudah karena struct bisa langsung dipetakan ke paket jaringan
    Dalam bahasa lain, sering kali tidak sesederhana itu
    Tentu saja, ada juga soal lebih lambat dan lebih besar