Update Keamanan Go Oktober 2026: 16 CVE di Go 1.27.3 dan 1.26.10, dan Kenapa Semua Binary Harus Di-build Ulang

Tim Go merilis dua update keamanan sepanjang Oktober 2026. Go 1.27.2 dan 1.26.9 keluar pada 8 Oktober dengan lima belas perbaikan, sebagian besar di net/http dan implementasi HTTP/2-nya. Go 1.27.3 dan 1.26.10 menyusul pada 19 Oktober dengan satu perubahan di crypto/x509 sebagai respons atas bocornya sertifikat eMudhra. Belum ada laporan celah-celah ini dieksploitasi, tetapi beberapa di antaranya memungkinkan klien tanpa autentikasi membuat server HTTP Go crash atau melambat. Ada juga satu hal yang membuat Go berbeda dari PHP atau Java: memasang versi Go terbaru di server tidak memperbaiki apa pun dengan sendirinya.

Update Go Saja Tidak Cukup: Build Ulang Semua Binary

Program Go membawa salinan standard library-nya sendiri. Saat sebuah layanan di-build, net/http, crypto/tls, dan semua package lain yang dipakai ikut dikompilasi ke dalam binary. Server yang menjalankan binary hasil build Go 1.26.8 akan tetap memakai kode net/http versi lama, tidak peduli versi Go apa yang terpasang di mesin itu, dan update sistem operasi juga tidak akan mengubahnya. Perbaikan baru sampai ke production setelah setiap layanan di-build ulang dengan toolchain baru lalu di-deploy.

Hal yang sama berlaku untuk tool yang bukan buatan tim Anda. Banyak software infrastruktur ditulis dengan Go, mulai dari container registry, reverse proxy, agent monitoring, sampai berbagai command line tool. Masing-masing baru aman setelah pengelolanya merilis build yang dibuat dengan toolchain yang sudah ditambal. Contoh nyata bulan ini: image Docker distribution registry masih di-build dengan Go 1.26.8 setelah rilis keamanan keluar, karena versi Go-nya dikunci di Dockerfile.

Untuk mengetahui versi Go yang dipakai saat sebuah binary di-build, jalankan go version diikuti path file-nya. Perintah go version -m juga menampilkan daftar module yang ikut dikompilasi. Untuk pengecekan yang lebih lengkap, govulncheck -mode=binary memindai binary yang sudah jadi dan melaporkan celah mana saja yang benar-benar bisa dijangkau oleh kodenya.

Versi yang Perlu Dipakai

Go hanya mendukung dua versi mayor terbaru. Sejak Go 1.27 keluar pada Agustus, Go 1.25 tidak lagi mendapat perbaikan keamanan. Layanan yang masih di-build dengan versi itu sebaiknya dipindahkan ke 1.26 atau 1.27. Untuk sebagian besar kode, ini cukup dengan mengganti toolchain, bukan menulis ulang aplikasi.

Lima Celah di Server HTTP/2

Kelompok perbaikan terbesar ada di HTTP/2. Server HTTP Go otomatis mengaktifkan HTTP/2 ketika melayani TLS, jadi semua layanan Go yang menangani HTTPS sendiri ikut terdampak. Layanan yang berada di belakang Nginx atau load balancer cloud dan hanya menerima HTTP/1.1 biasa sebagian besar terlindung dari celah-celah ini, walaupun tetap membutuhkan perbaikan lainnya.

Celah crash pada CVE-2026-97032 paling perlu diwaspadai. Celah ini tidak butuh autentikasi maupun endpoint khusus. Koneksi HTTP/2 apa pun sudah cukup, dan proses yang crash akan ikut menggugurkan semua request yang sedang diproses.

Kode yang meng-import golang.org/x/net/http2 secara langsung, bukan memakai salinan yang ada di dalam net/http, perlu update terpisah. Perbaikan yang sama tersedia di golang.org/x/net v0.60.0, jadi jalankan go get golang.org/x/net@v0.60.0 atau versi yang lebih baru, lalu build ulang.

HTTP/1, Form, dan TLS

• CVE-2026-94439: ketika handler menjawab request CONNECT HTTP/1 dengan status 2xx lalu selesai tanpa melakukan hijack koneksi, server tetap membaca request HTTP dari koneksi yang seharusnya sudah menjadi tunnel. Jika ada proxy di depannya, kondisi ini bisa berujung request smuggling.
• CVE-2026-56866: di sisi klien, http.Transport bisa meninggalkan koneksi di pool dalam keadaan tidak sinkron setelah request CONNECT yang membawa body ditolak, sehingga request berikutnya di koneksi itu membaca respons yang salah.
• CVE-2026-78667: header Range yang berisi banyak rentang kecil membuat FileServer, ServeContent, dan ServeFile memakan CPU berlebihan. Yang terdampak adalah layanan yang menyajikan file atau unduhan langsung dari Go.
• CVE-2026-94440: parsing multipart form bisa membaca satu baris yang sangat panjang ke memori dan melewati batas memori yang sudah ditetapkan. Semua endpoint yang menerima upload file atau multipart form berpotensi terdampak.
• CVE-2026-97031: klien TLS bisa mengirim referensi outer extension Encrypted Client Hello berulang kali dan membuat pemakaian memori proses server membengkak.

Template, Windows, dan Perintah go

Dua perbaikan di html/template membenahi escaping di dalam JavaScript. Yang pertama me-reset pelacakan konteks di antara ekspresi berurutan dalam template literal (CVE-2026-94448), yang kedua mengenali keyword yield sebelum regular expression (CVE-2026-97030). Keduanya bisa membuat sebuah nilai lolos tanpa escape di dalam blok script, celah yang biasanya berujung cross-site scripting. Di Windows, os.Root.Mkdir dan MkdirAll bisa mengikuti junction dan membuat folder di luar root (CVE-2026-56857). Dua perbaikan di perintah go menutup celah bypass checksum untuk golang.org/fips140 dan golang.org/toolchain (CVE-2026-94444 dan CVE-2026-94447). Eksploitasinya membutuhkan developer yang bekerja di dalam project berbahaya sekaligus memakai module proxy yang berbahaya.

Daftar Blokir Sertifikat eMudhra

Go 1.27.3 dan 1.26.10 hanya berisi satu perubahan, CVE-2026-111943. Di sebagian besar platform, Go memakai trust store milik sistem operasi, sehingga update paket ca-certificates sudah mencabut kepercayaan terhadap sertifikat intermediate eMudhra yang bocor. Namun ada kasus di mana trust store sistem tidak ikut diperbarui tanpa langkah tambahan, misalnya image container minimalis yang menyalin bundle sertifikat saat build. Untuk kasus seperti itu, crypto/x509 kini membawa daftar blokir, dan fungsi Verify akan mengembalikan error untuk sertifikat intermediate yang sudah diketahui bocor. Tidak ada pengaturan untuk mematikannya. Sama seperti perbaikan lain, perubahan ini baru berlaku setelah aplikasi di-build ulang.

Langkah Penerapan

1. 1Data semua binary Go yang berjalan di production, termasuk layanan buatan sendiri, scheduled job, CLI tool di pipeline CI, dan software pihak ketiga yang dibuat dengan Go.
2. 2Jalankan go version atau govulncheck -mode=binary pada setiap binary untuk melihat toolchain yang dipakai saat build dan celah mana yang bisa dijangkau.
3. 3Naikkan versi Go di semua tempat yang menguncinya: baris toolchain di go.mod (misalnya dengan go get toolchain@go1.27.3), base image golang di setiap Dockerfile, dan versi setup-go di workflow CI.
4. 4Update golang.org/x/net ke v0.60.0 atau lebih baru jika module Anda memakainya, lalu jalankan go mod tidy dan seluruh test.
5. 5Build ulang semua image, deploy ulang, lalu pastikan dengan go version -m bahwa binary yang berjalan sudah menampilkan go1.27.3 atau go1.26.10.
6. 6Untuk tool pihak ketiga, upgrade ke rilis yang di-build dengan toolchain yang sudah ditambal, atau tanyakan ke vendornya kapan rilis tersebut tersedia.

Tim yang sudah menjalankan govulncheck di pipeline CI umumnya langsung mendapat peringatan dalam sehari setelah rilis. Jika pipeline Anda belum melakukannya, sekarang saat yang tepat untuk menambahkannya, sekaligus menjadwalkan build ulang base image secara rutin. Dengan begitu, rilis keamanan Go berikutnya cukup ditangani lewat satu pull request biasa, bukan perburuan binary di semua server. Jika Anda butuh bantuan mengaudit atau membangun ulang layanan Go di infrastruktur Anda, tim managed service kami siap membantu, dan pelatihan Golang kami membahas praktik ini untuk tim internal.