Gangguan Cloudflare pada 5 Desember 2025

• Pada 5 Desember 2025 pukul 08:47 UTC, sebagian jaringan Cloudflare mengalami gangguan serius, dan pulih sepenuhnya pada 09:12, sekitar 25 menit kemudian
• Sekitar 28% dari total trafik HTTP terdampak, dan hanya pelanggan yang memenuhi kondisi tertentu yang mengalami gangguan
• Penyebabnya adalah perubahan WAF (logika parsing body) yang dilakukan saat menangani kerentanan React Server Components (CVE-2025-55182), dan tidak terkait dengan serangan siber
• Karena bug kode pada proxy FL1, terjadi error HTTP 500, sementara bug yang sama tidak muncul pada proxy FL2 berbasis Rust yang baru
• Cloudflare mengakui bahwa masalah serupa kembali terulang setelah gangguan 18 November, dan kini menjalankan proyek penguatan keamanan deployment dan resiliensi sebagai prioritas tertinggi

---

Ringkasan gangguan

• Pada 5 Desember 2025 pukul 08:47 UTC, terjadi gangguan pada sebagian jaringan Cloudflare
  • Semua layanan pulih pada 09:12, dengan total dampak selama 25 menit
  • Sekitar 28% dari total trafik HTTP terdampak
• Gangguan ini tidak terkait dengan serangan siber atau tindakan berbahaya, melainkan terjadi saat perubahan konfigurasi internal
• Penyebabnya adalah modifikasi logika parsing body pada WAF untuk merespons kerentanan baru di React Server Components

Penyebab gangguan dan latar belakang teknis

• WAF Cloudflare melakukan buffering body request HTTP ke memori untuk mendeteksi payload berbahaya
  • Ukuran buffer yang ada sedang diperluas dari 128KB menjadi 1MB
• Karena alat pengujian internal tidak mendukung ukuran buffer baru, dilakukan perubahan kedua untuk menonaktifkan alat pengujian tersebut
  • Perubahan ini langsung disebarkan ke seluruh server melalui sistem konfigurasi global
• Pada proxy FL1, perubahan ini memicu kondisi error, sehingga menghasilkan respons HTTP 500
  • Pesan error: attempt to index field 'execute' (a nil value)
• Masalah segera diidentifikasi, dan perubahan dibatalkan pada 09:12

Cakupan dampak

• Hanya pelanggan yang menggunakan proxy FL1 dan menerapkan Cloudflare Managed Ruleset yang terdampak
  • Semua request ke situs tersebut mengembalikan error HTTP 500
  • Beberapa endpoint pengujian seperti /cdn-cgi/trace menjadi pengecualian
• Jaringan di Tiongkok dan pelanggan dengan konfigurasi lain tidak terdampak

Detail error runtime

• Sistem rulesets Cloudflare mengevaluasi aturan pada setiap request
  • Aturan terdiri dari filter dan action, dan action execute memanggil kumpulan aturan lain
• Sistem logging internal menggunakan execute untuk mengevaluasi aturan pengujian
• Sistem killswitch dirancang untuk menonaktifkan aturan yang bermasalah, namun
  • Ini adalah pertama kalinya killswitch diterapkan pada aturan yang berisi action execute
• Terjadi error Lua karena sistem mencoba mengakses saat objek execute tidak ada
• Error ini adalah bug kode sederhana yang telah ada selama bertahun-tahun namun tidak terdeteksi
  • Bug yang sama tidak terjadi pada proxy FL2 yang ditulis dengan Rust

Perkembangan perbaikan setelah gangguan 18 November

• Pada 18 November juga terjadi gangguan luas akibat deployment global yang serupa
• Saat itu, Cloudflare berkomunikasi langsung dengan ratusan pelanggan dan membagikan rencana untuk mencegah satu update menyebar penuh ke seluruh sistem
• Pekerjaan perbaikan tersebut belum selesai, sehingga ikut memengaruhi gangguan kali ini
• Cloudflare menetapkannya sebagai prioritas tertinggi di seluruh organisasi

Proyek penguatan resiliensi yang sedang berjalan

• Enhanced Rollouts & Versioning
  • Menerapkan deployment bertahap, verifikasi kesehatan, dan rollback cepat juga pada perubahan data serta konfigurasi untuk respons ancaman
• Streamlined Break Glass Capabilities
  • Menjamin kemampuan intervensi darurat bahkan saat terjadi interaksi antara layanan internal dan control plane
• Fail-Open error handling
  • Saat terjadi error pada file konfigurasi, request tidak diblokir, melainkan dialihkan ke kondisi normal dasar atau trafik dibiarkan lewat
  • Beberapa layanan direncanakan akan menyediakan opsi fail-open/fail-closed
• Detail seluruh proyek resiliensi akan diumumkan dalam minggu depan
• Sampai saat itu, perubahan pada jaringan akan tetap dihentikan sepenuhnya (lockdown)

Timeline (UTC)

• 08:47 – Deployment perubahan konfigurasi dan mulai propagasi ke jaringan
• 08:48 – Dampak penuh terjadi
• 08:50 – Insiden dinyatakan melalui peringatan otomatis
• 09:11 – Mulai rollback perubahan
• 09:12 – Pemulihan selesai, seluruh trafik kembali normal

Kesimpulan

• Cloudflare mengakui keseriusan dua gangguan beruntun dan meminta maaf kepada pelanggan serta internet secara keseluruhan
• Ke depan, perusahaan berencana mencegah insiden serupa melalui penguatan keamanan deployment, toleransi error, dan resiliensi

[GN⁺]

Komentar Hacker News

• Insiden Cloudflare kali ini bukan sekadar bug Lua sederhana, tetapi kejadian yang menyingkap masalah arsitektur yang mendasar
  Struktur web terdistribusi yang asli sebenarnya jauh lebih tangguh terhadap gangguan global seperti ini. Sebaliknya, sistem terpusat yang homogen seperti Cloudflare bisa membuat layanan di seluruh dunia berhenti serentak hanya karena satu kesalahan. Ditulis dengan Rust pun manusia tetap bisa salah. Pada akhirnya, yang penting adalah desain yang kokoh

  • Pada akhirnya ini berarti semakin kita bergantung pada penyedia raksasa seperti Cloudflare atau AWS, semakin menurun stabilitas web
  • Seperti analogi “1.000 tawon vs 1 anjing”, baik gangguan global maupun gangguan lokal hanya berbeda bentuk rasa sakitnya. Jika Cloudflare berhenti, ratusan insinyur langsung merespons, tetapi jika server saya mati, penanggung jawabnya bisa saja sedang berada di vila pegunungan
  • Mengesampingkan perdebatan soal monopoli itu buruk, jika melihat uptime jangka panjang Cloudflare, saya justru menilai ini lebih baik daripada setiap situs mengelola infrastrukturnya sendiri. Logikanya, dari sudut pandang pengguna, semua layanan berhenti 1 jam secara bersamaan lebih baik daripada masing-masing berhenti 1 jam di waktu yang berbeda. Namun jika stabilitas Cloudflare turun ke bawah rata-rata, nilai itu pun hilang
  • Pada skala yang menangani 80 juta request per detik, saya rasa masalahnya justru terletak pada struktur yang membiarkan satu produk membesar seperti ini
  • Cloudflare tetap salah satu perusahaan yang paling cepat memulihkan infrastruktur global di mana pun di dunia. Kali ini pun mereka menyelesaikan gangguan jaringan 28% dalam 25 menit, dan secara objektif downtime-nya lebih sedikit dibanding cloud lain

• Tadi malam saya melihat error 500 Cloudflare di beberapa situs. Namun di halaman status tidak ada penyebutan apa pun, hanya pengumuman maintenance terjadwal

  • Seperti kebanyakan halaman status, butuh waktu sampai masalah yang sebenarnya dikenali dan diperbarui. Sampai semuanya benar-benar otomatis, Cloudflare pun bukan pengecualian. Yang lebih mengkhawatirkan adalah belakangan ini AWS, Azure, dan Cloudflare tumbang beruntun. Intuisi saya, ini akibat gabungan meningkatnya penggunaan LLM, kekurangan tenaga kerja, dampak pandemi, dan ketidakstabilan politik
  • Masalah halaman status seperti ini sepertinya hanya akan membaik lewat kritik terbuka. Perlu makin banyak umpan balik seperti “Cloudflare bahkan tidak bisa mendeteksi gangguannya dengan benar”

• Tampaknya rekayasa kualitas di Cloudflare tidak mampu mengejar kecepatan produksi. Dulu saya dengar di industri pertahanan tim kualitas selalu lebih berpengalaman, tetapi di industri perangkat lunak sepertinya justru kebalikannya

  • Ini mengingatkan saya pada kisah di industri pertahanan yang tetap mengabaikan memory leak dengan alasan “tidak masalah selama masih dalam durasi penggunaan”
  • Hal seperti ini terjadi dua kali dalam sebulan, jadi jelas bukan sesuatu yang “pantas dipuji”. Kalau berulang, tidak ada alasan pembenaran

• Arsitektur packet switching internet memang sejak awal dirancang untuk bertahan terhadap gangguan global seperti ini.
  Di era Perang Dingin, jaringan DARPA bertujuan menjaga rantai komando tetap berjalan bahkan saat terjadi serangan nuklir.
  Sekarang justru saatnya kembali ke paradigma internet local-first

  • Referensi: The Real Internet Architecture
  • Referensi: Local-first software

• Belakangan saya merasa Cloudflare membuat internet menjadi lebih lambat dan merepotkan. Prosedur seperti “buktikan bahwa Anda manusia” makin sering muncul, dan pemuatan halaman juga melambat.
  Tampaknya ini bukan untuk melindungi situs, melainkan karena kebijakan penagihan crawling AI (pengenalan Pay-per-crawl)

  • Prosedur verifikasi manusia seperti ini tidak kompatibel dengan browser lama, sehingga ada situs yang bahkan sama sekali tidak bisa diakses
  • Namun pengambilan konten oleh AI tanpa izin juga memang masalah. Cloudflare pada dasarnya memberi pemilik situs opsi perlindungan konten, dan jika tidak mau, itu bisa dimatikan
  • Ada juga sinisme seperti, “Sekarang mereka bahkan tidak bisa lagi diam-diam mengawasi kita”

• Sistem konfigurasi global Cloudflare berbahaya karena perubahan menyebar ke seluruh jaringan dalam hitungan detik tanpa rollout bertahap.
  Perlu ada sistem yang bisa segera mengenali korelasi saat perubahan konfigurasi menimbulkan error

  • Masalahnya adalah alarm berbunyi terlalu lambat. Notifikasi datang dalam 2 menit, padahal seharusnya terdeteksi dalam hitungan detik.
    Penanggung jawab deployment seharusnya melihat metrik real-time dan segera menekan tombol rollback.
    Bahkan sampai baris kode pun tercatat jelas di log, tetapi tampaknya ada keterputusan antara tim deployment dan tim yang memahami kode tersebut
  • Mereka melihat sinyal peringatan dan mencoba rollback, tetapi proses itu justru tampaknya memicu masalah
  • Tool internal sering kali memiliki banyak false positive, dan kadang malah rusak sendiri
  • Ini terdengar seperti lelucon, “Lampu peringatan mesin terus menyala, jadi saya cabut saja bohlamnya”

• Uptime Cloudflare sudah turun ke bawah 99,9%. Itu bahkan lebih buruk daripada PC rumah saya

  • AWS juga sama. Alasan keberadaan cloud adalah “ketersediaan yang lebih tinggi”, jadi kalau mahal dan tidak stabil, ada cukup alasan untuk hosting sendiri
  • Tetapi pada self-hosting, jika perangkat keras rusak atau backup gagal, pemulihannya bisa makan waktu berhari-hari
  • Di tempat yang sering mengalami pemadaman listrik, bertahan hanya dengan laptop dan baterai pun sulit. Kadang orang jadi memimpikan infrastruktur mandiri
  • Saya penasaran di mana kita bisa melihat statistik uptime Cloudflare yang akurat saat ini
  • Meski begitu, membandingkan PC pribadi dengan Cloudflare secara langsung adalah analogi yang tidak berarti

• Pada skala Cloudflare, seharusnya wajib ada lingkungan pengujian.
  Semua perubahan harus disimulasikan lebih dulu dalam lingkungan model yang terisolasi lalu dirilis bertahap.
  Yang lebih penting daripada sistem tipe yang kuat adalah pengaman prosedural

  • Perusahaan kami memakai sistem deployment tiga tahap: pengembangan → integrasi internal → produksi.
    Tim yang sering membuat kesalahan diperlambat, sedangkan tim yang lebih tepercaya bergerak lebih cepat.
    Pada akhirnya kecepatan teknis adalah soal pilihan. Jika SLA terancam, kecepatan harus dikurangi dan pengujian diperkuat
  • Menjadikan pengguna gratis sebagai test bed, lalu memberi versi stabil kepada pelanggan berbayar juga bisa menjadi cara
  • Ucapan “sistem tipe yang kuat tidak akan menyelamatkanmu” berarti bahwa di hadapan kegagalan prosedural, bahasa pemrograman tidak berdaya

• Tampaknya kualitas perangkat lunak Cloudflare sedang goyah.
  Bahkan pernah ada bug di mana verifikasi akses untuk fitur khusus enterprise hanya dilakukan pada tahap terakhir

  • Saya juga pernah mengalami pengaturan yang tidak bisa di-rollback di API Cloudflare.
    Perubahan hanya bisa dilakukan lewat tim dukungan, dan perbaikannya memakan waktu beberapa hari
    Tautan kasus terkait
  • Saya juga merasa bug seperti ini mungkin saja berasal dari kode yang ditulis AI
  • Saya ingin mendengar lebih spesifik apa maksudnya “hanya diperiksa pada tahap terakhir”

• Saya penasaran dengan budaya operasional Cloudflare.
  Kesalahan terjadi saat merespons isu keamanan, tetapi alih-alih rollback mereka malah melakukan deployment global lagi, dan itu keputusan yang berisiko.
  Artinya mereka melanggar prinsip dasar, “kalau ragu, rollback”

  • Namun kali ini situasinya mendesak, seperti penanganan kerentanan React Server RCE.
    Jika deployment ditunda, pelanggan bisa benar-benar diretas, jadi ini kasus di mana kecepatan adalah keamanan
  • Rollback tidak selalu jawaban yang benar. Jika prosedurnya tidak benar-benar dikuasai, itu sendiri bisa menjadi risiko
  • Sebenarnya dua deployment itu adalah komponen yang berbeda.
    Perbaikan pertama justru menyingkap bug laten pada yang kedua, sehingga kadang roll forward lebih realistis daripada rollback
  • Sangat mungkin Cloudflare menumpuk utang teknis di tengah pertumbuhannya yang cepat.
    Gangguan yang sering terjadi belakangan ini bisa jadi sinyal bahwa utang itu mulai muncul ke permukaan