Tim CodeIgniter merilis update CodeIgniter 4.7.5 pada 9 Oktober 2026 sebagai rilis pemeliharaan seri 4.7 yang menutup enam advisori keamanan sekaligus memperbaiki puluhan bug. Bila aplikasi Anda masih di 4.7.0–4.7.4, rencanakan upgrade lewat staging — jangan menunggu gejala serangan muncul di log.
Nomor versi naik, tetapi perilaku runtime ikut berubah: View Parser memproses data berbeda, validator unggahan file lebih ketat, dan client HTTP membersihkan opsi setelah request gagal. Berikut ringkasan enam celah yang ditutup, nuansa yang sering disalahpahami, serta urutan uji regression sebelum deploy ke production.
Highlight
Enam GHSA, breaking behavior, dan checklist upgrade
- 4.7.5 menutup enam GHSA (dua di View Parser); tim framework menyarankan semua pengguna 4.7 naik versi segera.
- Substituted value Parser tidak diparse ulang — output template yang mengandalkan nested placeholder bisa berubah menjadi teks literal.
Config\View::$restrictParserConditionalsdefault false; conditional{if ...}tetap dievaluasi sebagai PHP sampai Anda opt-in.- Validasi upload menolak nama seperti
shell.php.gifdan bisa menolak nama polos sepertilogo.php.gif— rename file, jangan bypass rule. - CURLRequest dengan
shareOptions=falsemembersihkan opsi per-request setelah exception; retry wajib set ulang auth/body/form/JSON.
Kapan Patch Keamanan 4.7.5 Wajib Diterapkan
Prioritas upgrade naik apabila production memakai View Parser dengan data pengguna, form multi-file upload, atau wrapper API yang me-reuse instance CURLRequest setelah error jaringan. Enam perbaikan keamanan menargetkan pola aplikasi nyata: stored XSS lewat sintaks Parser, eksekusi kode lewat key data view, polyglot upload, validasi file yang terlewat, kebocoran kredensial antar-request, serta conditional Parser yang mengeksekusi PHP.
Menurut tim CodeIgniter, 4.7.5 adalah rilis keamanan dan pemeliharaan, bukan major rewrite. Namun label “maintenance” tetap bisa mengubah output halaman atau menolak file yang dulu lolos validator. Tim DevOps yang sudah terbiasa checklist patch CMS bisa membandingkan ritme yang sama pada artikel WordPress 7.1.3: checklist update keamanan, meski stack PHP-nya berbeda.
Enam Advisori Keamanan yang Ditutup 4.7.5
Changelog resmi mengelompokkan perbaikan di bawah enam advisory GitHub. Ringkasan berikut fokus pada siapa yang terdampak dan apa yang berubah setelah patch — bukan skenario exploit sensasional.
1. View Parser stored XSS (GHSA-vgrf-mv2j-gp8w). Nilai substituted yang masih berisi sintaks Parser (contoh {text|raw}) pernah masuk pass berikutnya; akibatnya auto-escaping pseudo-variable lain bisa terlewat. Sejak 4.7.5, substituted value dan output plugin bawaan hanya data mentah — Parser tidak memprosesnya lagi.
2. Eksekusi kode lewat key data view (GHSA-c29x-ffjj-8r7x). Key data seperti template, view, atau foundView pada cell bisa menimpa variabel internal renderer pada kondisi tertentu. Exploit butuh aplikasi yang meneruskan data kurang tepercaya di key tersebut; risikonya serius, walau bukan “semua view otomatis rentan”.
3. Ekstensi handler PHP pada nama file upload (GHSA-4hwf-v4mp-hf6c). Rule is_image, mime_in, dan ext_in kini menolak nama dengan ekstensi handler PHP sebelum ekstensi akhir (contoh shell.php.gif). Nama polos seperti logo.php.gif ikut tertolak; rename file lebih aman daripada mematikan validasi.
4. Validasi multi-upload opsional (GHSA-cwxp-v62r-xwx2). Entri UPLOAD_ERR_NO_FILE dulu bisa membuat validator melewatkan file berikutnya untuk max_size, dimensi, atau mime. Sekarang setiap file non-kosong dalam unggahan multiple ikut Anda verifikasi.
5. Kebocoran opsi CURLRequest (GHSA-9g9v-xgwj-697h). Jika shareOptions false dan request melempar exception, header/body/kredensial spesifik request bisa tertinggal saat client dipakai ulang. Opsi konstruktor tetap; framework me-reset per-request baseURI dan delay.
6. Conditional Parser mengeksekusi PHP (GHSA-4q58-jw8x-8cm7). Tag {if ...} / {elseif ...} tetap mengevaluasi PHP secara default. 4.7.5 menambahkan restricted conditionals sebagai mitigasi opt-in, bukan default.
Detail teknis dan tautan GHSA lengkap ada di changelog resmi CodeIgniter 4.7.5.
Perubahan View Parser Pasca-Patch 4.7.5
Dua advisori pertama plus conditional execution menjadikan Parser area uji paling panjang. Setelah patch, placeholder yang sengaja berisi sintaks Parser di dalam data user akan tampil literal — perilaku yang Anda inginkan untuk mencegah XSS, namun bisa “memecah” template lama yang mengandalkan nested substitution.
Upgrade guide resmi memperingatkan migrasi ini; salin contoh hanya dari dokumen upgrade, jangan mengasumsikan pola lama tetap valid. Kemudian jalankan regression test pada halaman email, invoice, atau CMS internal yang memakai Parser dengan field bebas.
Untuk conditional: jangan menulis bahwa sekadar naik ke 4.7.5 menutup risiko editor template yang tidak tepercaya. Aktifkan restricted mode hanya bila Anda memang butuh mitigasi dan sudah membaca batasannya.
// app/Config/View.php — opt-in, default tetap false di instalasi lama
public bool $restrictParserConditionals = true;Render per-request juga bisa memakai opsi restrictConditionals bila Anda tidak ingin mengubah config global. Restricted conditional membatasi jalur evaluasi PHP di tag kondisi; fitur Parser lain tetap butuh disiplin ACL pada siapa yang boleh mengedit template.
Validasi Upload dan CURLRequest yang Berubah
Tim yang mengelola portal dengan unggahan gambar profil atau dokumen multi-file perlu skenario uji eksplisit: file kosong di entri pertama, file valid di entri berikutnya, nama dengan substring .php., dan polyglot lama yang pernah lolos. Changelog menyarankan nama file generated atau folder upload tanpa eksekusi script — prinsip yang selaras dengan lapisan pertahanan di edge seperti konfigurasi Cloudflare WAF, meski patch framework tetap wajib.
Pada HTTP client, audit kode retry: setelah exception, panggil ulang setAuth(), setBody(), setForm(), atau setJSON() sebelum request berikutnya, atau pass ulang array opsi ke method request. Integration test yang mock timeout lalu retry adalah cara murah menangkap regresi auth header.
Upgrade lewat Composer dan Checklist Staging
Alur yang disarankan mengikuti panduan upgrade 4.7.4 → 4.7.5 dan forum rilis resmi: backup database dan writable/, snapshot branch, update dependency di staging, lalu deploy setelah uji.
- Commit atau tag state production saat ini; export env dan versi PHP (CI4 4.7.x mensyaratkan PHP 8.1+ sesuai seri Anda).
- Di staging:
composer update codeigniter4/framework --with-dependencies(sesuaikan constraintcomposer.jsonproyek). - Buka
app/Config/View.php; putuskan apakahrestrictParserConditionalsperlu true untuk template yang diedit role non-admin. - Jalankan test otomatis (
phpunit, static analysis bila ada) plus smoke test route kritis. - Manual: Parser pages, form upload, outbound API dengan retry, dan cell/view yang menerima array data dari request.
- Review log PHP dan application log 24 jam pasca-deploy; pantau 4xx/5xx pada endpoint upload dan webhook.
Lantaran Parser atau upload sering jadi tulang punggung bisnis, jangan dorong langsung ke production tanpa staging. Klaim “tanpa breaking change” untuk 4.7.5 tidak akurat menurut dokumentasi upgrade — rencanakan waktu QA khusus untuk diff HTML Parser dan respons API retry.
Sebelum cutover, catat versi composer.lock, hash commit, dan environment variable yang memengaruhi upload path atau base URL HTTP client. Dokumen itu mempercepat rollback bila regression muncul di jam sibuk.
Verifikasi Pasca-Update dan Konteks Risiko
Setelah deploy, bandingkan snapshot HTML halaman Parser-heavy dengan baseline pre-upgrade; diff yang hanya menampilkan literal {...} kerap berarti Anda perlu refactor template, bukan rollback patch keamanan. Untuk upload, siapkan daftar nama file bisnis yang valid walau mengandung .php. di tengah nama agar tim support tahu alasan penolakan.
Memahami vektor serangan web lebih luas — backdoor, spam SEO, credential stuffing — membantu prioritas patch framework versus hardening server. Bacaan bagaimana website bisa diretas melengkapi konteks; bila insiden sudah terjadi, urutan pemulihan di tutorial pemulihan website kena hacking tetap relevan meski root cause-nya bukan CI4 saja.
Patch 4.7.5 tidak menggantikan audit kode custom, rotasi secret, atau WAF — tetapi menutup celah yang sudah dipublikasikan dengan nomor advisory jelas. Akhirnya, tandai upgrade ini sebagai pekerjaan maintenance wajib Q4 2026, dokumentasikan hasil uji Parser/upload/CURLRequest, baru klaim environment 4.7 “patched” dengan bukti regression, bukan hanya angka versi di composer.lock.
