Caddy 2.11.9 Rilis: Enam Perbaikan Keamanan FastCGI dan PHP

Caddy 2.11.9 dirilis 5 November 2026 sebagai patch cepat di atas 2.11.8, membawa enam butir perbaikan keamanan di bagian Security fixes catatan rilis resmi. Patch ini menutup celah pada transport FastCGI, memperbaiki regresi direktori PHP yang membuat halaman seperti /wp-admin/ berakhir 404, dan menegakkan beberapa perilaku yang kini dihitung breaking change. Siapa pun yang menjalankan 2.11.8 dan menyajikan PHP lewat php_fastcgi disarankan pindah ke versi ini.

TL;DR

• Caddy 2.11.9 keluar 5 November 2026, satu hari setelah 2.11.8, isinya penambalan regresi dan keamanan.
• Enam butir Security fixes, empat di antaranya menyentuh transport FastCGI.
• Regresi 2.11.8: direktori dengan garis miring di akhir tidak lagi diarahkan ke index.php, sehingga WordPress admin 404.
• env pada FastCGI sekarang menang atas header permintaan, klien tidak bisa lagi memalsukan variabel HTTP_*.
• Konfigurasi client_auth yang bertentangan kini jadi error, bukan diabaikan diam-diam.

Kenapa Caddy 2.11.9 disebut patch darurat?

Karena jaraknya hanya satu hari dari rilis sebelumnya, dan isinya bukan fitur baru melainkan penambalan. Versi 2.11.8 terbit 4 November 2026, lalu 2.11.9 menyusul 5 November 2026. Catatan rilis menyebut versi ini sebagai tindak lanjut cepat untuk memperbaiki regresi yang diperkenalkan 2.11.8 dan sejumlah masalah keamanan, sebagian besar di FastCGI. Semua perubahan di dalamnya adalah backport dari branch master, ditambah beberapa tambahan kecil.

Regresi yang dimaksud ada di try_files. Pada 2.11.8, permintaan ke sebuah direktori dengan garis miring di akhir, misalnya /wp-admin/, dicocokkan ke direktori itu sendiri, bukan ke index.php di dalamnya. Akibatnya permintaan tidak pernah sampai ke PHP dan umumnya berakhir 404. Perbaikan di 2.11.9 membuat pola try_files hanya cocok dengan direktori kalau polanya diakhiri garis miring, seperti dirangkum pada pull request nomor 8352.

Efek praktisnya sempit tapi menyakitkan: panel admin WordPress, serta aplikasi lain yang menyajikan index.php lewat URL bergaris miring di akhir. Kalau Anda sempat naik ke 2.11.8 dan melihat halaman admin mendadak hilang tanpa pesan error di log PHP, ini penyebabnya, bukan masalah konfigurasi database atau plugin.

Selain regresi itu, ada satu perubahan kecil yang berguna: opsi plain_time_format untuk file_server browse. Opsi ini mengatur format waktu pada daftar direktori versi teks biasa, yaitu respons untuk permintaan dengan header Accept: text/plain. Perubahannya masuk lewat pull request 8084 dan sifatnya aditif, tidak mengubah tampilan daftar direktori HTML yang sudah ada.

Celah FastCGI apa saja yang ditutup di versi ini?

Ada empat butir yang menyentuh FastCGI, ditambah satu di lapisan adapter Caddyfile dan satu pembaruan dependensi. Yang paling relevan untuk aplikasi PHP adalah perebutan variabel HTTP_*: pada versi lama, klien bisa menimpa nilai yang Anda set lewat subdirektif env hanya dengan mengirim header permintaan bernama sama. Contoh nyatanya, header yang mengaku sebagai user bisa menggeser nilai yang dilihat aplikasi di HTTP_X_AUTH_USER.

Sejak 2.11.9, nilai yang dikonfigurasi menang. Perbaikan ini tercatat sebagai GHSA-q34h-28rj-5hjm dan masuk lewat pull request 8358. Bagi aplikasi yang selama ini bergantung pada perilaku lama, misalnya meneruskan identitas pengguna dari header ke env, urutan prioritasnya sekarang terbalik dan perlu diuji ulang sebelum dipasang di produksi.

Butir kedua menyangkut Windows: nama pendek gaya 8.3 seperti ADMINI~1 dan alternate data stream NTFS bisa dipakai menjalankan skrip yang seharusnya ditolak aturan path. Perbaikannya melanjutkan pekerjaan di 2.11.8 dan tercatat sebagai GHSA-9cr8-wmhh-39pm. Butir ketiga menutup celah garis miring terenkode dan segmen titik: path yang lolos matcher berbasis persen bisa memilih skrip berbeda dari yang benar-benar dieksekusi.

Butir keempat menyentuh HTTP/2. Field host yang dikirim bersama :authority bisa membuat aplikasi melihat host berbeda dari host yang dipakai Caddy untuk merutekan permintaan. Sejak versi ini, HTTP_HOST diambil dari host hasil routing saja. Terakhir, dependensi go-jose dinaikkan dari 4.1.5 ke 4.1.6 untuk GHSA-mgcc-cww5-fp2q.

Celah	Dampak sebelum 2.11.9	Perilaku setelah patch
env FastCGI lawan header klien	Klien bisa menimpa HTTP_* yang diset admin	Nilai dari konfigurasi selalu menang
Nama pendek 8.3 di Windows	Skrip terlarang bisa dijalankan lewat alias	Path dengan komponen 8.3 atau titik dua ditolak
Garis miring terenkode	Matcher menyetujui satu skrip, skrip lain jalan	Permintaan ambigu dapat 400
Field host di HTTP/2	HTTP_HOST bisa berbeda dari host routing	Host diambil dari hasil routing
client_auth bertentangan	Kebijakan ketat dibuang diam-diam	Adapter Caddyfile menolak konfigurasi

Apakah patch keamanan ini bisa merusak konfigurasi yang sudah jalan?

Bisa, untuk tiga pola konfigurasi tertentu. Catatan rilis menyebutnya sendiri sebagai perubahan yang berpotensi breaking kalau aplikasi Anda bergantung pada perilaku yang justru sedang diperbaiki. Jadi kalau konfigurasi Anda memanfaatkan salah satu dari tiga pola di bawah ini, uji dulu di staging sebelum menyentuh server produksi.

Pertama, dua blok situs yang berbagi kebijakan koneksi TLS untuk hostname yang sama tetapi memasang client_auth berbeda. Dulu adapter Caddyfile menyimpan yang pertama dan membuang yang kedua tanpa suara, yang artinya syarat mTLS yang lebih ketat bisa hilang tanpa jejak. Sekarang kombinasi itu ditolak, jadi Anda akan menerima error saat memuat konfigurasi, bukan sesudah trafik berjalan.

Kedua, permintaan FastCGI yang ambigu soal skrip mana yang dijalankan. Ada dua kasus: ketika path terenkode dan path terdekode memilih skrip berbeda, dan di Windows ketika path mengandung nama pendek 8.3 atau titik dua. Keduanya sekarang dijawab dengan status 400. Kalau aplikasi Anda menerima path aneh dari klien dan selama ini tetap jalan karena kebetulan cocok, permintaan semacam itu akan gagal setelah upgrade.

Ketiga, prioritas env terhadap header. Kalau aplikasi Anda selama ini mengandalkan klien untuk mengirim nilai tertentu lewat header dan nilai itu dipakai sebagai HTTP_* di PHP, sekarang nilai dari konfigurasi yang berlaku. Solusinya bukan menambal Caddy, tapi memindahkan logika itu ke lapisan aplikasi atau menyesuaikan nilai env sesuai kebutuhan.

Cara upgrade dan memastikan versinya benar-benar jalan

Ambil biner dari halaman rilis resmi, ganti biner lama, lalu periksa dua hal: versi yang dilaporkan dan validitas konfigurasi. Rilis ini juga tersedia sebagai paket distribusi resmi, jadi kalau Caddy Anda dipasang lewat manajer paket, ikuti kanal paket itu dan jangan mencampur biner manual dengan unit layanan dari paket.

Langkah minimal yang bisa dijalankan siapa saja: unduh aset sesuai arsitektur, letakkan di lokasi biner yang dipakai unit layanan, lalu jalankan caddy version untuk memastikan keluaran menyebut 2.11.9. Sesudah itu jalankan caddy validate --config /etc/caddy/Caddyfile. Langkah validasi ini yang menangkap perubahan breaking di atas sebelum layanan dimuat ulang, jadi jangan dilewati.

Untuk memastikan regresi PHP benar-benar hilang, uji satu URL direktori yang diakhiri garis miring dan satu URL berkas PHP langsung. Kalau keduanya mengembalikan 200 dan log PHP mencatat eksekusinya, berarti jalur FastCGI sudah benar. Perhatikan juga header Accept: text/plain pada daftar direktori kalau Anda memakai opsi plain_time_format yang baru.

Satu catatan untuk penulis plugin Caddy: pengelola dependensi mungkin memberi peringatan untuk menaikkan Caddy di go.mod plugin Anda. Catatan rilis meminta hal itu hanya dilakukan kalau ada perubahan API ekspor yang benar-benar dipakai plugin tersebut. Menaikkan versi tanpa alasan bisa memaksa Anda menyesuaikan kode yang sebenarnya tidak perlu disentuh.

Siapa yang perlu buru-buru pindah ke 2.11.9?

Prioritas pertama adalah siapa pun yang menyajikan PHP melalui Caddy, terutama WordPress, karena dua alasan sekaligus: regresi direktori dan celah FastCGI. Kalau situs Anda punya area admin yang dilindungi mTLS, Anda masuk prioritas berikutnya, sebab kebijakan client_auth yang bertentangan kini jadi error dan sebaiknya diperbaiki sebelum trafik berjalan.

Prioritas ketiga adalah instalasi di Windows, karena perbaikan nama pendek 8.3 hanya relevan di sana, tetapi tetap penting kalau direktori web Anda dapat ditulisi pengguna lain. Bagi yang hanya memakai Caddy sebagai reverse proxy statis tanpa PHP dan tanpa FastCGI, dampaknya kecil, meski tetap tidak ada alasan menunda karena isinya hanya perbaikan.

Untuk tim yang mengelola banyak situs, urutan pemeriksaan yang masuk akal: inventarisasi blok yang memakai php_fastcgi, cari subdirektif env di dalamnya, lalu cari blok dengan client_auth pada hostname yang sama. Ketiga daftar itu adalah seluruh permukaan risiko upgrade ini. Sisanya hanya penambahan opsi dan pengurangan alokasi memori di jalur panas.

Checklist upgrade untuk tim operasi

Patch keamanan yang menyentuh jalur autentikasi biasanya berjalan mulus, tetapi tetap butuh urutan kerja yang jelas supaya tidak ada situs yang tertinggal di versi lama. Urutan berikut bisa dipakai apa adanya untuk satu server maupun untuk armada kecil dengan beberapa belas situs di belakang Caddy.

• Catat versi yang berjalan sekarang dengan caddy version dan simpan keluarannya di tiket perubahan.
• Cari semua blok yang memakai php_fastcgi, lalu tandai blok yang punya subdirektif env di dalamnya.
• Cari blok dengan client_auth pada hostname yang sama. Kalau ada dua nilai berbeda, satukan dulu sebelum upgrade.
• Jalankan caddy validate pada konfigurasi hasil perubahan, bukan hanya pada konfigurasi lama.
• Uji satu URL direktori bergaris miring, satu berkas PHP, dan satu endpoint yang bergantung pada header identitas.
• Setelah trafik normal, periksa log untuk status 400 pada FastCGI. Kemunculannya berarti ada permintaan ambigu yang dulu diterima.

Untuk lambat-laun, ada satu kebiasaan yang layak dipertahankan: simpan berkas konfigurasi di repositori, dan jalankan validasi di pipeline sebelum biner baru dipasang. Dengan begitu perubahan breaking seperti penolakan client_auth bertentangan ketahuan di tahap review, bukan saat layanan dimuat ulang di jam sibuk. Dua perintah yang perlu ada di pipeline hanyalah caddy fmt untuk memeriksa format dan caddy validate untuk memeriksa kesahihan konfigurasi.

Kalau Anda memakai Caddy di dalam kontainer, perhatikan bahwa biner di dalam image juga harus naik. Mengganti biner di host tidak menyentuh image yang dipakai kontainer, jadi pastikan tag image ikut diperbarui dan bukan hanya berkas konfigurasi yang dipasang ulang. Ini sumber kebingungan yang sering muncul saat audit: konfigurasi sudah benar, tetapi proses yang melayani trafik masih versi lama.

FAQ

Apakah Caddy 2.11.9 wajib dipasang kalau saya masih di 2.11.7?

Tidak wajib, tetapi disarankan. Versi 2.11.8 dan 2.11.9 berisi perbaikan keamanan FastCGI yang saling melengkapi, jadi melompat langsung ke 2.11.9 lebih aman daripada berhenti di 2.11.8 yang masih punya regresi direktori.

Apa yang terjadi pada situs WordPress saya setelah upgrade?

Halaman admin yang sebelumnya 404 karena regresi 2.11.8 kembali normal, karena pola try_files lagi-lagi mengarahkan permintaan direktori bergaris miring ke index.php. Tidak ada perubahan konfigurasi yang dibutuhkan untuk perbaikan ini.

Apakah ada fitur baru di rilis ini?

Hanya satu yang menonjol, yaitu plain_time_format untuk file_server browse, plus helper IsNamedRoute() untuk penulis plugin. Selebihnya perbaikan dan pengurangan alokasi pada pembersihan path, penulisan ulang header, serta pemilihan weighted_round_robin.

Di mana saya bisa membaca detail setiap perubahannya?

Catatan rilis lengkap ada di halaman rilis v2.11.9, termasuk tautan tiap pull request. Untuk perilaku direktif, lihat dokumentasi php_fastcgi dan file_server. Detail celah FastCGI ada di advisory GHSA-q34h-28rj-5hjm.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API, dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.