Analisis pasca-insiden gangguan Cloudflare pada 18 November 2025

(blog.cloudflare.com)

23 poin oleh GN⁺ 2025-11-19 | 8 komentar | Bagikan ke WhatsApp

Pada 18 November 2025 pukul 11:20 (UTC), fungsi inti pengiriman trafik di jaringan Cloudflare terhenti, sehingga pengguna di seluruh dunia melihat halaman error
Penyebabnya adalah file feature pada sistem Bot Management membesar secara tidak normal akibat perubahan izin database, dan tidak terkait dengan serangan siber
Kenaikan ukuran file ini membuat perangkat lunak routing trafik gagal setelah melampaui batasnya, sehingga error HTTP 5xx terjadi secara besar-besaran
Sekitar pukul 14:30, distribusi file bermasalah dihentikan dan diganti dengan versi sebelumnya yang normal sehingga trafik inti pulih, lalu semua layanan kembali normal pada pukul 17:06
Cloudflare menilai insiden ini sebagai gangguan terburuk sejak 2019, dan mendorong langkah pencegahan seperti penguatan validasi file konfigurasi serta penerapan kill switch global

Ringkasan gangguan

Sekitar pukul 11:20, terjadi kegagalan pengiriman trafik inti di jaringan Cloudflare, dan pengguna melihat halaman error internal Cloudflare
Bukan disebabkan oleh serangan siber atau tindakan jahat, melainkan langsung dipicu oleh perubahan izin pada sistem database
Perubahan itu membuat ukuran feature file yang digunakan sistem Bot Management meningkat dua kali lipat, lalu didistribusikan ke seluruh jaringan
Saat perangkat lunak routing trafik membaca file tersebut, batas ukuran file terlampaui, sehingga terjadi error sistem
Awalnya sempat disangka sebagai serangan DDoS berskala besar, tetapi setelah penyebabnya diketahui, pemulihan dilakukan dengan mengganti ke file normal sebelumnya

Perjalanan insiden dan dampaknya

Sebelum 11:20, rasio error 5xx masih berada di level normal, tetapi setelah itu error melonjak akibat distribusi feature file yang salah
Pada sebagian node klaster database ClickHouse, hasil query yang salah dihasilkan tiap 5 menit, sehingga file normal dan file abnormal didistribusikan secara bergantian, membuat sistem berulang kali pulih lalu gagal lagi
Mulai 14:30, pembuatan file bermasalah dihentikan dan file normal disisipkan secara manual, lalu pemulihan dilakukan dengan me-restart core proxy
Pada 17:06, semua layanan kembali normal

Layanan	Dampak
Core CDN dan layanan keamanan	Terjadi error HTTP 5xx
Turnstile	Gagal dimuat, tidak bisa login
Workers KV	Error 5xx melonjak akibat kegagalan gateway
Dashboard	Tidak bisa login karena gangguan Turnstile
Email Security	Akurasi deteksi spam sementara menurun, sebagian pemindahan otomatis gagal
Access	Banyak kegagalan autentikasi, tetapi sesi yang sudah ada tetap dipertahankan

Selama periode gangguan, latensi respons CDN meningkat, yang disebabkan oleh lonjakan penggunaan CPU pada sistem debugging

Penyebab gangguan: sistem Bot Management

Modul Bot Management milik Cloudflare menggunakan model machine learning untuk menghasilkan skor bot per permintaan
File konfigurasi feature yang dipakai sebagai input model didistribusikan ke seluruh jaringan setiap beberapa menit untuk merespons ancaman terbaru
Akibat perubahan perilaku query ClickHouse, banyak baris feature duplikat ikut masuk, sehingga ukuran file membesar
Hal ini memicu error pada modul Bot Management dan menyebabkan respons HTTP 5xx dikembalikan, serta berdampak pada Workers KV dan Access
Pada mesin proxy baru FL2, terjadi error 5xx; sedangkan pada versi lama FL, skor bot disetel ke 0 sehingga false positive meningkat

Perubahan perilaku query ClickHouse

Pada 11:05, perubahan izin akses database di ClickHouse mulai didistribusikan
Sebelumnya, hanya metadata dari database default yang bisa diakses, tetapi setelah perubahan, metadata dari database r0 juga ikut terekspos
Query pembuat feature file milik Bot Management dijalankan tanpa filter nama database, sehingga pada akhirnya kolom duplikat ikut dikembalikan
Akibatnya, jumlah baris dalam feature file meningkat lebih dari dua kali lipat dan melampaui batas sistem

Pra-alokasi memori dan system panic

Modul Bot Management melakukan pra-alokasi memori dengan batas maksimum 200 feature machine learning
Saat file yang salah berisi lebih dari 200 feature, panic terjadi pada kode Rust, dengan keluaran error
thread fl2_worker_thread panicked: called Result::unwrap() on an Err value
Hal ini menyebabkan lonjakan besar error HTTP 5xx

Dampak lain dan proses pemulihan

Workers KV dan Access bergantung pada core proxy, sehingga dampak gangguan meluas
- Pada 13:04, Workers KV dipatch agar dapat melewati proxy, sehingga rasio error menurun
Dashboard tidak bisa login karena bergantung pada Turnstile dan Workers KV
- Terjadi penurunan ketersediaan dua kali, pada 11:30–13:10 dan 14:40–15:30
- Latensi meningkat akibat backlog dan permintaan retry, lalu pulih sekitar pukul 15:30
Setelah 14:30, sebagian besar layanan kembali normal, dan pada 17:06 pemulihan selesai sepenuhnya

Langkah pencegahan agar tidak terulang

Memperkuat validasi input untuk file konfigurasi yang dihasilkan Cloudflare
Memperluas kill switch fitur global
Mencegah kehabisan sumber daya sistem akibat pelaporan error
Meninjau kondisi error di seluruh modul core proxy

Ringkasan timeline (UTC)

Waktu	Status	Penjelasan
11:05	Normal	Perubahan kontrol akses database mulai didistribusikan
11:28	Dampak mulai terasa	Error pertama muncul pada trafik pelanggan
11:32–13:05	Investigasi berlangsung	Analisis penyebab error Workers KV, upaya mitigasi
13:05	Dampak berkurang	Bypass diterapkan untuk Workers KV dan Access
13:37	Fokus pada pemulihan	Persiapan rollback file konfigurasi Bot Management
14:24	Distribusi file bermasalah dihentikan	Pengujian file normal selesai
14:30	Dampak utama teratasi	File normal didistribusikan secara global, pemulihan layanan dimulai
17:06	Pulih sepenuhnya	Semua layanan kembali normal

Kesimpulan

Gangguan ini terjadi akibat interaksi antara logika pembuatan file konfigurasi Bot Management dan perubahan izin database
Cloudflare menilai ini sebagai gangguan jaringan paling serius sejak 2019
Ke depan, perusahaan akan mendorong perbaikan struktural untuk memperkuat ketahanan sistem dan memperkuat mekanisme pertahanan otomatis

8 komentar

t7vonn 2025-11-19

Gangguan yang terkait dengan file konfigurasi memang bisa terjadi di mana saja.

princox 2025-11-19

Saat Cloudflare tidak berfungsi dan berbagai layanan ikut terhenti, rasanya seperti neraka..

epdlemflaj 2025-11-19

Dokumen analisis penyebabnya ternyata dirilis cukup cepat ya, wow

epdlemflaj 2025-11-19

Ngomong-ngomong, ternyata penulis artikel ini adalah CEO.

GN⁺ 2025-11-19

Opini Hacker News

Ini adalah kisah kecelakaan .unwrap() bernilai ratusan juta dolar
Memanggil .unwrap() di jalur infrastruktur inti internet pada dasarnya sama dengan menyatakan, “ini tidak akan pernah gagal; kalau gagal, langsung matikan thread-nya”
Kompiler Rust memaksa kemungkinan kegagalan dinyatakan secara eksplisit, tetapi mereka memilih panic alih-alih menanganinya dengan anggun
Menurut saya ini contoh antipola klasik “parse, don’t validate”
- Banyak orang tampaknya punya blind spot terhadap .unwrap(). Mungkin karena terlalu sering muncul di kode contoh
  Dalam kode produksi nyata, .unwrap() atau .expect() seharusnya ditinjau seperti panic
  Jika memakai .unwrap() di kode produksi, seharusnya wajib ada komentar “INFALLIBILITY”, dan ini bisa dipaksa dengan clippy::unwrap_used
- Poin tulisan ini tampaknya adalah bahwa masalah muncul bukan dari satu penyebab tunggal, melainkan dari kombinasi komponen yang secara individual normal
  Bukan sekadar karena .unwrap(), tetapi juga karena kueri tidak membedakan database sehingga payload membesar, dan ClickHouse mengekspos lebih banyak DB
  Daripada menyimpulkan “ini gara-gara unwrap”, saya rasa yang lebih penting adalah perbaikan desain seperti global kill switch atau pencegahan agar sumber daya sistem tidak kewalahan
- Sebenarnya ini juga gagal di luar jalur Rust. Sistem manajemen bot mengklasifikasikan semua trafik sebagai bot
  Di layer FL2, panic dari tiap komponen memang harus ditangkap, tetapi fail-open tidak selalu lebih baik
  Perlu ditambahkan logika agar keputusan apakah panic akan ditangkap dan ditangani dibuat secara eksplisit di level FL2
- Jika ditangani dengan anggun, tampaknya akan ada penurunan performa (meski menurut saya tetap lebih baik daripada penurunan keandalan)
  Kalau ini sistem yang di-shard, saya juga penasaran kenapa tidak ada rollout bertahap dan monitoring
- Swift punya unwrap implisit ! dan unwrap eksplisit ?
  Saya hampir tidak pernah memakai unwrap implisit. Bahkan untuk nilai yang dijamin ada pun saya selalu menanganinya secara eksplisit
  Misalnya saya mendefinisikan @IBOutlet weak var someView? alih-alih @IBOutlet weak var someView!
  Ini semacam pendekatan belt & suspenders
Sangat mengesankan mereka merilis post mortem kurang dari 24 jam setelah insiden
- Saya penasaran seperti apa kebijakan internal yang memungkinkan publikasi secepat dan setransparan ini
  Di sebagian besar perusahaan besar, publikasi kode seperti ini nyaris mustahil karena harus melewati peninjauan berbagai stakeholder
- Ditambah lagi tulisannya sendiri bagus. Dibandingkan postmortem AWS, ini nyaris setingkat karya sastra
Saat membaca penjelasan Cloudflare tentang gangguan ini, saya bertanya-tanya, “kenapa pemulihannya butuh waktu selama itu?”
Saya paham penyebab gangguannya, tetapi kalau sebagian besar jaringan down, bukankah membalikkan perubahan konfigurasi terbaru seharusnya jadi prioritas pertama?
Tentu setelah kejadian semuanya terlihat jelas, tetapi memulai investigasi hanya dalam 7 menit tetap mengesankan
- Awalnya ini disangka serangan. Setelah sumber masalah ditemukan, ternyata tidak ada cara untuk mengganti file yang rusak di antrean, dan banyak mesin di seluruh dunia harus direstart
Kejadian ini terasa mirip dengan insiden CrowdStrike
File konfigurasi yang dihasilkan otomatis merusak perangkat lunak, lalu menyebar ke seluruh jaringan
Saya paham perlunya deployment cepat, tetapi kejadian ini menunjukkan tidak adanya rollout bertahap dan strategi rollback
- Ini lebih tepat dilihat bukan sebagai deployment CI/CD, melainkan sebagai control channel untuk sistem deteksi bot terdistribusi
- Mengejutkan bahwa mereka mendorongnya langsung ke produksi tanpa simulator
- Meski begitu, saya percaya kejadian ini akan mendorong perbaikan
Jika melihat rencana perbaikan yang diumumkan Cloudflare, ada
- penguatan validasi file konfigurasi yang dihasilkan Cloudflare
- penambahan global kill switch
- pencegahan kehabisan sumber daya akibat core dump atau error report
- peninjauan mode error modul proxy
  dan lain-lain
  Namun canary deployment atau deployment konfigurasi bertahap justru tidak disebut
  Global switch bisa berbahaya, dan satu bug saja bisa menghentikan seluruh sistem
- Konfigurasi manajemen bot memang harus tersebar cepat, tetapi jika diuji dulu di satu instance, panic ini mungkin bisa tertangkap lebih awal
  Saya juga mempertanyakan kenapa ClickHouse dipakai sebagai feature flag store. Bahkan di dokumentasi deduplication ClickHouse pun ada faktor risikonya
- Layanan konfigurasi memang punya rollout bertahap, tetapi layanan yang mengonsumsinya melakukan auto-update terlalu sering sehingga kesalahan kecil pun berdampak ke semuanya
- Konfigurasi global berguna untuk respons cepat, tetapi mekanisme rollback cepat itu wajib
  Kalau ada pemetaan dependensi antar layanan, pelacakan akar masalah akan jauh lebih mudah
- Pada akhirnya, sebagian besar outage besar memang disebabkan oleh config push
  Deployment kode dilakukan dengan hati-hati, tetapi deployment konfigurasi tidak. Perlu ada kesadaran bahwa konfigurasi juga adalah kode
Bagian bahwa halaman status ikut down sehingga sempat disangka serangan itu menarik
Katanya infrastruktur itu sepenuhnya terpisah dari Cloudflare, tetapi tidak ada penjelasan kenapa ikut mati
- Kemungkinan besar ini karena lonjakan trafik yang membuat penskalaan infrastruktur gagal
- Bisa jadi mereka mengira tidak bergantung pada Cloudflare, tetapi karena sebagian besar internet bergantung pada CloudFront, mungkin sebenarnya tidak sepenuhnya independen
- Untuk mengetahui penyebabnya, perlu postmortem dari statuspage.io. Itu layanan yang dioperasikan Atlassian
- Bisa juga semata-mata karena skala Cloudflare begitu besar sehingga trafik menumpuk ke sana
Saya mengintegrasikan Turnstile dengan strategi fail-open, dan itu membantu dalam gangguan ini
Jika JS tidak termuat, pengiriman tetap diizinkan dengan token dummy, dan bahkan jika verifikasi backend gagal, saya juga menanganinya secara fail-open
Sebagian pengguna memang tetap terblokir, tetapi dampak keseluruhan berkurang
Ini pendekatan yang dimungkinkan karena ada sarana mitigasi bot lain
- Kalau begitu, bukankah penyerang bisa memblokir skrip dan melewati CAPTCHA?
  Namun ini tampaknya hanya akan berhasil kalau bukan serangan yang ditargetkan
Saya heran kenapa .unwrap() diizinkan di kode Cloudflare
Paling tidak mereka seharusnya memakai expect("ini tidak akan pernah terjadi")
Filosofi memperlakukan error sebagai nilai justru dibuat untuk mencegah masalah seperti ini, dan itu akan membuat diagnosis jauh lebih mudah
- Saya bukan karyawan Cloudflare, tetapi saya cukup banyak memakai Rust
  Di kode yang melibatkan network call, ada terlalu banyak kemungkinan gagal
  Saat pengembangan saya memakai .unwrap(), tetapi di produksi saya kadang tetap menyisakan expect(). Karena kadang memang tidak ada lagi cara untuk melanjutkan
Pelajaran sebenarnya adalah terlalu banyak fungsi bergantung pada segelintir pemain
Struktur winner-takes-all makin menguat dan resiliensi sistem menurun
Tentu posisi itu mereka raih karena kemampuan mereka, tetapi rasanya berlebihan jika berharap internet akan selalu “berfungsi normal”
Pernyataan “kalau pakai Rust pasti aman” itu berlebihan
Bahasa apa pun, kalau dipakai dengan salah, sama saja seperti mengarahkan moncong senjata ke kaki sendiri

barca105 2025-11-19

Bahkan di perusahaan sekelas Cloudflare pun mereka pakai .unwrap() ya, duh. Gimana bisa kode itu diterapkan ke production?

skageektp 2025-11-19

Sepertinya masalahnya bukan pada unwrap