Docker Engine 29.9.3: Empat CVE dan BuildKit 0.34.2

Docker Engine 29.9.3 dirilis 3 November 2026 pukul 22:37 UTC dengan empat CVE yang ditutup di inti Engine dan SwarmKit, ditambah pembaruan BuildKit ke 0.34.2. Rilis ini adalah patch keamanan ketiga dalam tiga minggu: 29.9.1 keluar 14 Oktober 2026, 29.9.2 keluar 20 Oktober 2026, dan 29.9.3 menutup rangkaian tersebut. Semua nomor CVE dan tautan di bawah diambil dari catatan rilis resmi di repositori moby/moby, bukan dari ringkasan pihak ketiga.

TL;DR

• Docker Engine 29.9.3 terbit 3 November 2026 dan menutup empat CVE: 2026-116587, 2026-116591, 2026-115538, serta 2026-115539 di SwarmKit.
• CVE-2026-115538 menyangkut hilangnya proteksi enkripsi dan anti-spoofing pada overlay network Swarm setelah firewalld membersihkan aturan iptables Docker.
• BuildKit naik ke 0.34.2 untuk menambal crash daemon lewat resolver cache poisoning pada build yang membaca referensi Git yang sama dua kali.
• Dua rilis sebelumnya membawa isu berbeda: 29.9.1 memperbarui containerd ke v2.4.2, 29.9.2 memblokir delapan intermediate eMudhra yang kuncinya dikompromikan.
• Arti praktisnya: host yang menjalankan Swarm atau firewalld perlu diprioritaskan, sementara host dengan pembangunan image rutin perlu memeriksa versi BuildKit.

Yang membuat rilis ini menarik bukan jumlah CVE-nya, melainkan kombinasi subsistem yang tersentuh. Satu isu ada di parsing kunci RSA, satu di dekompresi data, satu di jaringan overlay Swarm, dan satu di penerbitan sertifikat antar node. Empat area berbeda dalam satu patch biasanya menandakan bahwa temuan datang dari beberapa jalur audit sekaligus, bukan dari satu laporan tunggal.

CVE apa saja yang ditutup Docker Engine 29.9.3?

Ada empat CVE di inti rilis ini. CVE-2026-116587 memperbaiki kemungkinan pemakaian CPU berlebihan saat memproses kunci RSA yang dibuat khusus, CVE-2026-116591 memperbaiki kemungkinan panic saat mendekompresi data zstd, CVE-2026-115538 memperbaiki hilangnya proteksi enkripsi dan anti-spoofing overlay Swarm, dan CVE-2026-115539 memperbaiki celah di SwarmKit yang memungkinkan pemegang sertifikat worker yang sah memperoleh sertifikat manager.

Dua CVE pertama bersifat lokal: dampaknya terbatas pada proses yang memproses masukan berbahaya, dan gejalanya berupa beban CPU naik atau daemon berhenti. Dua CVE terakhir lebih serius karena menyangkut isolasi jaringan dan otorisasi antar node. Pada CVE-2026-115538, pemicunya adalah firewalld yang membersihkan aturan iptables milik Docker. Setelah aturan itu hilang, proteksi enkripsi dan anti-spoofing pada overlay network tidak lagi berjalan sebagaimana mestinya.

Kombinasi firewalld dan Docker memang dikenal rawan konflik karena keduanya mengelola aturan iptables. Catatan rilis menyebut skenario ini secara eksplisit, dan itu penting: host yang memakai firewalld bersama Swarm adalah kandidat pertama untuk di-upgrade, bukan karena konfigurasinya salah, tetapi karena interaksi dua pengelola aturan itu sendiri yang menjadi pemicu.

CVE-2026-115539 berada di SwarmKit. Celahnya memungkinkan penyerang yang sudah memegang sertifikat dan kunci privat worker yang sah untuk mendapatkan sertifikat manager sesaat setelah pergantian leader di cluster Swarm. Ini bukan celah untuk penyerang tanpa akses, tetapi tetap berbahaya karena memindahkan batas kepercayaan dari worker ke manager, dan manager memegang kendali seluruh cluster.

Konteks pergantian leader itulah yang membuat celah ini layak diperhatikan. Pergantian leader pada cluster Swarm bukan peristiwa yang jarang: ia terjadi saat node manager berhenti, saat pemeliharaan dilakukan, atau saat cluster tumbuh. Jendela waktunya singkat, tetapi celah yang hanya terbuka pada jendela singkat tetap bisa dieksploitasi jika penyerang sudah berada di dalam jaringan dan bisa menunggu. Karena itu, cluster yang memiliki node worker dari pihak lain, misalnya tim berbeda atau mitra, berada pada risiko yang lebih tinggi dibanding cluster yang seluruh node-nya dikelola satu tim.

Pada implementasinya, perbaikan dirilis lewat pembaruan SwarmKit yang dipaketkan bersama rilis Engine. Artinya, menaikkan versi Engine ke 29.9.3 sudah mencakup perbaikan ini, tanpa langkah tambahan yang terpisah. Yang perlu diperiksa justru kebiasaan operasional: apakah semua node manager benar-benar ikut di-upgrade, karena satu manager yang tertinggal pada versi lama bisa membuat perbaikan pada siklus pergantian leader tidak berlaku sepenuhnya.

Apa yang berubah pada BuildKit dan containerd?

BuildKit diperbarui ke 0.34.2 dan menambal dua advisory, salah satunya GHSA-2fqp-xg6f-v7gj yang menyangkut crash daemon akibat resolver cache poisoning. Pemicunya spesifik: sebuah build yang membaca metadata untuk referensi sumber Git yang sama dua kali dapat membuat daemon berhenti.

Masalah pada resolver cache ini menarik karena sumbernya bukan masukan dari luar, melainkan urutan operasi di dalam build itu sendiri. Build yang membaca referensi Git yang sama dua kali bukan pola langka, terutama pada pipeline yang memakai monorepo atau yang melakukan beberapa tahap build dari repositori yang sama. Karena itu, memperbarui BuildKit relevan bagi tim yang membangun image secara rutin, bukan hanya bagi yang menjalankan Swarm.

Pada rilis 29.9.1 sebelumnya, containerd diperbarui ke v2.4.2 untuk menutup CVE-2026-95839 dan dua advisory lain. Satu di antaranya menyangkut kemungkinan containerd berhenti ketika menarik atau mengimpor image lewat transfer service jika descriptor anak memuat anotasi tertentu dengan digest yang cacat. Advisory lain menyangkut header Content-Length yang dibuat khusus dan dapat membuat containerd berhenti ketika pengambilan layer paralel diaktifkan. Yang ketiga menyangkut habisnya ruang disk host karena containerd tidak membatasi data layer sesuai ukuran yang dideklarasikan sebelum validasi.

Isu disk itu yang paling mudah diremehkan. Registry jahat atau image yang dimodifikasi bisa membuat host kehabisan ruang penyimpanan, dan pada host yang menjalankan banyak container, ruang habis berarti semua layanan di atasnya ikut berhenti. Pembaruan containerd bukan sekadar soal kestabilan daemon, tetapi soal menjaga host tetap bisa menulis ke disk.

Kenapa rilis 29.9.2 penting untuk registry dan TLS?

Karena 29.9.2 memblokir delapan intermediate certificate eMudhra yang kuncinya dikompromikan, dan pemblokiran itu membuat pull atau push image gagal jika rantai sertifikat registry bergantung pada salah satu intermediate tersebut. Nomor CVE-nya 2026-111943, dan perbaikannya masuk lewat pembaruan runtime Go ke 1.26.10.

Daftar intermediate yang diblokir mencakup tiga kategori validasi: domain-validated TLS pada EM DV TLS CA G3B dan G3C, organization-validated TLS pada EM OV TLS CA G3B dan G3C, extended-validation TLS pada EM EV TLS CA G3B dan G3C, serta code signing pada EM OV CS CA G3B dan G3C. Intermediate G3B berada di bawah eMudhra BV, sedangkan G3C di bawah eMudhra Inc.

Konsekuensinya perlu dipahami dengan benar. Pembaruan ini bukan bug yang membuat pull tiba-tiba gagal tanpa sebab, melainkan penolakan yang disengaja terhadap rantai sertifikat yang kuncinya sudah tidak bisa dipercaya. Registry yang masih memakai rantai tersebut harus mengganti sertifikatnya. Bagi operator, langkah praktisnya adalah memeriksa rantai sertifikat registry internal sebelum menjadwalkan upgrade, supaya kegagalan tarik image tidak muncul bersamaan dengan jendela pemeliharaan.

Berikut perbandingan tiga rilis terakhir dalam seri 29.9:

Versi	Tanggal	Fokus utama	Dampak operasional
29.9.1	2026-10-14	containerd v2.4.2, tiga advisory termasuk CVE-2026-95839	Pull image paralel dan batas ukuran layer
29.9.2	2026-10-20	Go 1.26.10, CVE-2026-111943 blokir delapan intermediate eMudhra	Registry dengan rantai sertifikat lama berhenti melayani
29.9.3	2026-11-03	Empat CVE Engine dan SwarmKit, BuildKit 0.34.2	Host Swarm dengan firewalld paling terpengaruh

Bagaimana urutan upgrade yang masuk akal?

Urutan yang masuk akal dimulai dari inventaris: catat host mana yang menjalankan Swarm, mana yang memakai firewalld, dan mana yang membangun image sendiri. Tanpa inventaris, upgrade cenderung berubah menjadi penggantian versi serentak yang sulit dilacak jika ada layanan berhenti.

Setelah inventaris terkumpul, prioritas pertama adalah host Swarm yang juga memakai firewalld, karena dua CVE pada rilis ini menyentuh area tersebut. Prioritas kedua adalah host yang menjalankan build image rutin, karena BuildKit ikut diperbarui. Prioritas ketiga adalah host yang hanya menjalankan container biasa, yang dampaknya lebih kecil tetapi tetap perlu naik versi untuk menutup isu parsing RSA dan dekompresi zstd.

Satu hal yang sering terlewat: memperbarui paket Engine belum tentu memperbarui BuildKit yang dipakai. Pada banyak instalasi, BuildKit berjalan sebagai komponen terpisah, dan versinya perlu diperiksa sendiri. Kalau pipeline build memakai builder container, image builder itulah yang harus dinaikkan, bukan hanya paket di host.

Untuk verifikasi, dua pemeriksaan sudah cukup informatif: versi Engine yang benar-benar berjalan dan versi BuildKit yang dipakai oleh builder aktif. Mencatat keduanya sebelum dan sesudah upgrade memberi jejak yang jelas ketika ada perubahan perilaku, misalnya build yang tadinya berhasil menjadi gagal karena penolakan sertifikat atau karena perubahan pada resolver.

Pada host yang menjalankan Swarm, verifikasi perlu ditambah satu langkah: pastikan seluruh node manager melaporkan versi yang sama. Cluster Swarm dengan manager bercampur versi bisa tetap berjalan, tetapi keputusan pada siklus pergantian leader diambil oleh node yang sedang memegang peran, sehingga node yang tertinggal pada versi lama tidak selalu menampakkan gejalanya sampai ada pergantian.

Untuk host yang tidak menjalankan Swarm, pemeriksaan cukup pada daemon dan builder. Yang perlu dijaga adalah kebiasaan mencatat: perubahan versi tanpa catatan awal membuat laporan masalah di kemudian hari kehilangan titik pembanding, dan tanpa titik pembanding setiap dugaan penyebab harus diuji dari nol.

FAQ

Apakah Docker Engine 29.9.3 wajib dipasang segera?

Untuk host yang menjalankan Swarm, terutama bersama firewalld, prioritasnya tinggi karena dua CVE menyentuh isolasi jaringan dan otorisasi node. Untuk host yang hanya menjalankan container tunggal, upgrade tetap disarankan tetapi bisa mengikuti jendela pemeliharaan biasa.

Apakah CVE-2026-115538 berarti konfigurasi firewalld saya salah?

Bukan. Pemicunya adalah firewalld yang membersihkan aturan iptables milik Docker, sehingga proteksi overlay network hilang. Perbaikannya ada di sisi Docker Engine, jadi upgrade adalah jalan keluarnya, bukan mengubah konfigurasi firewall menjadi lebih longgar.

Kenapa pull image tiba-tiba gagal setelah naik ke 29.9.2?

Kemungkinan besar registry memakai rantai sertifikat yang memuat salah satu dari delapan intermediate eMudhra yang diblokir karena kuncinya dikompromikan. Solusinya adalah mengganti rantai sertifikat di registry, bukan menurunkan versi Docker Engine.

Apakah BuildKit selalu ikut naik saat Engine diperbarui?

Tidak selalu. BuildKit sering berjalan sebagai komponen atau builder container terpisah, sehingga versinya perlu diperiksa sendiri. Jika pipeline memakai builder container, image builder itulah yang harus diperbarui agar perbaikan 0.34.2 benar-benar berlaku.