Belajar FrankenPHP - CVE & Security Patch Management

#Pendahuluan

Episode 14 membangun pertahanan aktif (headers, TLS, hardening). Episode ini membahas pertahanan yang lebih membosankan tapi tak kalah penting: proses menangani kerentanan. Server aplikasi adalah komponen runtime yang berdiri di tepi jaringan — jika ia terkena RCE, seluruh aplikasi di belakangnya ikut jatuh. FrankenPHP membuktikan diri tanggap dalam hal ini, dan kalian harus tahu cara menanggapi dengan benar.

Mengapa penting? Kerentanan tidak bisa "di-fix oleh konfigurasi" — harus ada disiplin update. Episode ini menggunakan CVE-2026-45062 sebagai studi kasus nyata untuk memahami alur lengkap: mengenal kerentanan, memverifikasi versi yang aman, merencanakan rollout, dan melakukannya tanpa downtime.

#Studi Kasus: CVE-2026-45062

CVE-2026-45062 adalah kerentanan Remote Code Execution (RCE) pada FrankenPHP yang ditemukan di mekanisme Unicode CGI path-splitting. Rinciannya:

Singkatnya, penyerang bisa mengeksploitasi penanganan path ber-encoding Unicode untuk membelah path sedemikian rupa sehingga skrip PHP yang seharusnya tidak terjangkau ikut dieksekusi — berujung pada eksekusi kode di server.

Pelajaran penting dari kasus ini:

1. Bootstrap RCE terjadi di lapisan tak terduga — path parsing, bukan logika aplikasi. Komponen runtime sekecil apa pun berisiko.
2. Tim FrankenPHP menambal cepat — 1.12.3 dirilis sebagai security release dan langsung direkomendasikan.
3. CVSS 8.1 "High" berarti dampak serius tapi bukan "walking zombie" — masih ada waktu untuk rollout terencana, bukan panik.

#Alur Penanganan CVE yang Benar

#1. Deteksi

Pantau sumber kerentanan secara proaktif:

• Security advisories GitHub: github.com/php/frankenphp/security — terbit di tab Security repository.
• GitHub Advisory Database: github.com/advisories — filter dengan keyword frankenphp.
• Berita rilis: setiap rilis baru di GitHub Releases berisi changelog, termasuk patch keamanan.

gh release list --repo php/frankenphp --limit 5

#2. Verifikasi Versi Terpasang

Cek versi di semua instance sebelum memutuskan langkah:

frankenphp version

Bandingkan dengan daftar versi yang terdampak advisory. Di CI/CD, tambahkan langkah yang mengagalkan build jika versi terpapar:

- name: Cek versi aman
  run: |
    VERSION=$(frankenphp version | grep -oP 'FrankenPHP v\K[0-9.]+')
    test "$(printf '%s\n1.12.3' "$VERSION" | sort -V | head -1)" = "1.12.3"

#3. Verifikasi Integritas Rilis: gh attestation

Men-download binary dari internet membutuhkan kepercayaan: bagaimana kalian tahu binary yang kalian dapat benar-benar dari maintainer? GitHub artifact attestations menjawabnya — setiap rilis resmi ditandatangani dan bisa diverifikasi:

gh release download v1.12.3 --repo php/frankenphp --pattern "frankenphp-linux-x86_64"
gh attestation verify ./frankenphp-linux-x86_64 \
  --repo php/frankenphp \
  --predicate-type https://slsa.dev/provenance/v1

Verifikasi ini memastikan:

• Binary benar-benar dibangun dari repository resmi.
• Diterbitkan oleh maintainer berwenang (SLSA provenance).
• Tidak dimodifikasi di tengah jalan (man-in-the-middle).

#4. Rollout Bertahap (Staging Rollout)

Jangan update semua instance sekaligus. Pola yang direkomendasikan:

1. staging      -> verifikasi smoke test + integrasi
2. 1 node produksi (canary) -> pantau log/metrics 1 jam
3. 25% traffic  -> perhatikan error rate & latency
4. 100%         -> rollout penuh

Jika memakai Docker, pin tag versi spesifik, bukan latest:

services:
  php:
    image: dunglas/frankenphp:1.12.7-php8.5-bookworm
    restart: always

Dengan tag tercatat, kalian tahu persis versi mana yang jalan di setiap environment — dan bisa melakukan rollback cepat dengan docker compose up -d --no-deps php setelah mengubah tag.

#5. Rollback Plan

Sebelum update, siapkan jalan mundur:

• Tag image lama tetap tersedia di registry (jangan dibersihkan mendadak).
• Catat versi yang sedang berjalan sebelum update.
• Latih rollback di staging: docker compose down + tag lama + up.

#Update Rutin: Lebih dari Sekadar CVE

Jangan menunggu CVE. FrankenPHP merilis perbaikan performa dan stabilitas juga — contoh nyata: 1.12.0 (6 Maret 2026) membawa peningkatan performa hingga 3.6x selain dukungan Windows. Jadwalkan update minor secara berkala:

• Bulanan: pantau rilis baru, baca changelog.
• Kuartalan: naik minor version di staging + produksi bertahap.
• Seketika: security release (patch) — segera setelah verifikasi staging.

#Common Pitfalls

• Versi tidak terdokumentasi: tanpa catatan versi per environment, kalian tidak tahu instance mana yang terpapar. Inventarisasi versi adalah prasyarat manajemen CVE.
• latest tag di produksi: restart container bisa mengunduh versi baru tak terduga. Pin versi.
• Attestation hanya di dev: verifikasi harus ada di pipeline yang sama yang menghasilkan image produksi.
• Rollout all-at-once: jika binary baru bermasalah, seluruh traffic ikut bermasalah. Selalu staging + canary.

#Penutup

Pada episode 15 ini, kalian telah mengelola kerentanan FrankenPHP secara profesional.

Inti yang harus dibawa pulang:

• CVE-2026-45062: Unicode CGI path-splitting RCE (CVSS 8.1), ditambal di 1.12.3 (15 Mei 2026).
• Pantau security advisories GitHub; cek versi di semua instance.
• Verifikasi binary dengan gh attestation verify (SLSA provenance).
• Rollout bertahap: staging → canary → 25% → 100%; siapkan rollback.
• Pin versi image; jadwalkan update rutin, bukan hanya saat CVE.

Di episode 16 selanjutnya kita menangani serangan dari sisi volume: firewall, rate limit & DoS mitigation — directive rate_limit Caddy 2.9+, pembatasan per-IP pada endpoint API, dan langkah-langkah anti-DDoS. Sampai jumpa di episode 16!