Sự cố ngày 5 tháng 12 năm 2025 của Cloudflare

• Vào lúc 08:47 UTC ngày 5 tháng 12 năm 2025, một phần mạng Cloudflare gặp sự cố nghiêm trọng, và được khôi phục hoàn toàn vào 09:12, khoảng 25 phút sau
• Khoảng 28% tổng lưu lượng HTTP bị ảnh hưởng, và chỉ những khách hàng đáp ứng các điều kiện nhất định mới gặp sự cố
• Nguyên nhân là thay đổi WAF (logic phân tích body) được thực hiện trong quá trình ứng phó lỗ hổng React Server Components (CVE-2025-55182), không liên quan đến tấn công mạng
• Lỗi mã trong proxy FL1 đã gây ra lỗi HTTP 500, trong khi proxy FL2 mới dựa trên Rust không gặp cùng lỗi này
• Cloudflare thừa nhận vấn đề tương tự đã lặp lại ngay cả sau sự cố ngày 18 tháng 11, và đang triển khai các dự án tăng cường an toàn triển khai và khả năng phục hồi như ưu tiên cao nhất

---

Tổng quan sự cố

• Vào lúc 08:47 UTC ngày 5 tháng 12 năm 2025, sự cố xảy ra tại một phần mạng Cloudflare
  • Tất cả dịch vụ được khôi phục vào 09:12, tổng thời gian ảnh hưởng là 25 phút
  • Khoảng 28% tổng lưu lượng HTTP bị ảnh hưởng
• Sự cố không liên quan đến tấn công mạng hay hành vi ác ý, mà xảy ra trong quá trình thay đổi cấu hình nội bộ
• Nguyên nhân là chỉnh sửa logic phân tích nội dung WAF để ứng phó với lỗ hổng mới của React Server Components

Nguyên nhân sự cố và bối cảnh kỹ thuật

• Cloudflare WAF đệm phần thân của yêu cầu HTTP trong bộ nhớ để phát hiện payload độc hại
  • Kích thước bộ đệm hiện có đang được mở rộng từ 128KB lên 1MB
• Do công cụ kiểm thử nội bộ không hỗ trợ kích thước bộ đệm mới, họ đã thực hiện thay đổi thứ hai để vô hiệu hóa công cụ kiểm thử
  • Thay đổi này được lan truyền ngay lập tức đến toàn bộ máy chủ thông qua hệ thống cấu hình toàn cục
• Trên proxy FL1, thay đổi này đã kích hoạt trạng thái lỗi, gây ra phản hồi HTTP 500
  • Thông báo lỗi: attempt to index field 'execute' (a nil value)
• Vấn đề được xác định ngay lập tức và thay đổi đã được hoàn tác vào 09:12

Phạm vi ảnh hưởng

• Chỉ những khách hàng sử dụng proxy FL1 và áp dụng Cloudflare Managed Ruleset mới bị ảnh hưởng
  • Mọi yêu cầu tới các trang đó đều trả về lỗi HTTP 500
  • Một số endpoint kiểm thử như /cdn-cgi/trace là ngoại lệ
• Mạng tại Trung Quốc và khách hàng với cấu hình khác không bị ảnh hưởng

Chi tiết lỗi runtime

• Hệ thống rulesets của Cloudflare đánh giá các quy tắc trên mỗi yêu cầu
  • Quy tắc gồm bộ lọc và hành động, trong đó hành động execute gọi một tập quy tắc khác
• Hệ thống ghi log nội bộ sử dụng execute để đánh giá các quy tắc kiểm thử
• Hệ thống killswitch được thiết kế để vô hiệu hóa các quy tắc hoạt động sai, nhưng
  • Đây là lần đầu tiên killswitch được áp dụng cho quy tắc có chứa hành động execute
• Việc cố truy cập khi đối tượng execute không tồn tại đã gây ra lỗi Lua
• Đây là một lỗi mã đơn giản đã tồn tại nhiều năm nhưng không bị phát hiện
  • Proxy FL2 viết bằng Rust không gặp cùng lỗi này

Tiến độ cải thiện sau sự cố ngày 18 tháng 11

• Ngày 18 tháng 11 cũng đã xảy ra sự cố diện rộng do triển khai toàn cục tương tự
• Khi đó, Cloudflare đã trao đổi trực tiếp với hàng trăm khách hàng và chia sẻ kế hoạch ngăn một bản cập nhật đơn lẻ lan rộng toàn hệ thống
• Các cải tiến đó vẫn chưa hoàn tất, nên đã ảnh hưởng đến sự cố lần này
• Cloudflare đã xác định đây là ưu tiên cao nhất trên toàn tổ chức

Các dự án đang triển khai để tăng cường khả năng phục hồi

• Enhanced Rollouts & Versioning
  • Áp dụng triển khai dần, kiểm tra tình trạng và rollback nhanh ngay cả với thay đổi dữ liệu và cấu hình phục vụ ứng phó mối đe dọa
• Streamlined Break Glass Capabilities
  • Đảm bảo khả năng thao tác khẩn cấp ngay cả khi có tương tác giữa dịch vụ nội bộ và control plane
• Xử lý lỗi fail-open
  • Khi có lỗi trong tệp cấu hình, hệ thống sẽ không chặn yêu cầu mà chuyển sang trạng thái mặc định bình thường hoặc cho phép lưu lượng đi qua
  • Một số dịch vụ dự kiến sẽ cung cấp tùy chọn chọn giữa fail-open/fail-closed
• Cloudflare dự kiến công bố chi tiết toàn bộ các dự án tăng cường khả năng phục hồi trong tuần tới
• Cho đến lúc đó, hệ thống sẽ duy trì trạng thái lockdown, tức tạm dừng toàn bộ thay đổi trên mạng

Dòng thời gian (UTC)

• 08:47 – Triển khai thay đổi cấu hình và bắt đầu lan truyền trên mạng
• 08:48 – Toàn bộ tác động xuất hiện
• 08:50 – Tuyên bố sự cố nhờ cảnh báo tự động
• 09:11 – Bắt đầu hoàn tác thay đổi
• 09:12 – Khôi phục hoàn tất, toàn bộ lưu lượng trở lại bình thường

Kết luận

• Cloudflare thừa nhận mức độ nghiêm trọng của hai sự cố liên tiếp và xin lỗi khách hàng cũng như toàn bộ Internet
• Trong tương lai, công ty sẽ thúc đẩy các biện pháp ngăn sự cố tương tự thông qua an toàn triển khai, khả năng chịu lỗi và tăng cường khả năng phục hồi

[GN⁺]

Ý kiến trên Hacker News

• Sự cố Cloudflare lần này không chỉ là một lỗi Lua đơn thuần, mà còn phơi bày một vấn đề kiến trúc mang tính nền tảng
  Cấu trúc web phân tán ban đầu vốn chống chịu tốt hơn nhiều trước các sự cố toàn cục như vậy. Ngược lại, các hệ thống tập trung đồng nhất như Cloudflare có thể khiến dịch vụ trên toàn thế giới đồng loạt dừng lại chỉ vì một sai sót. Dù viết bằng Rust thì con người vẫn mắc lỗi. Cuối cùng, điều quan trọng vẫn là thiết kế vững chắc

  • Điều đó có nghĩa là càng phụ thuộc vào các nhà cung cấp khổng lồ như Cloudflare hay AWS thì độ ổn định của web càng giảm
  • Giống phép so sánh “1.000 con ong bắp cày vs 1 con chó”, dù là sự cố toàn cục hay cục bộ thì chỉ khác ở hình thức đau đớn mà thôi. Khi Cloudflare ngừng hoạt động, hàng trăm kỹ sư sẽ lập tức ứng phó, còn nếu máy chủ của tôi chết thì người phụ trách có khi đang ở biệt thự trên núi
  • Tạm gác tranh luận về độc quyền sang một bên, nếu nhìn vào thời gian hoạt động dài hạn của Cloudflare thì có thể nó vẫn tốt hơn việc từng website tự vận hành hạ tầng riêng. Theo logic đó, việc mọi dịch vụ cùng dừng 1 giờ có thể còn đỡ hơn mỗi nơi tự dừng 1 giờ vào các thời điểm khác nhau, xét từ góc nhìn người dùng. Tuy nhiên, nếu độ ổn định của Cloudflare tụt xuống dưới mức trung bình thì giá trị đó cũng biến mất
  • Ở quy mô xử lý 80 triệu yêu cầu mỗi giây, tôi cho rằng ngay từ đầu chính cấu trúc để một sản phẩm phình to đến mức này mới là vấn đề
  • Cloudflare vẫn là một trong những công ty phục hồi hạ tầng toàn cầu nhanh nhất ở bất kỳ đâu trên thế giới. Lần này họ cũng xử lý xong sự cố 28% mạng trong 25 phút, và thời gian ngừng dịch vụ xét khách quan vẫn ít hơn các đám mây khác

• Tối qua tôi thấy lỗi Cloudflare 500 trên nhiều website. Nhưng trang trạng thái lại không hề nhắc đến, chỉ có thông báo bảo trì theo lịch

  • Cũng như phần lớn các trang trạng thái khác, luôn cần thời gian để nhận ra vấn đề thực tế và cập nhật. Chừng nào chưa được tự động hóa hoàn toàn thì Cloudflare cũng không ngoại lệ. Điều đáng lo hơn là gần đây AWS, Azure, Cloudflare liên tiếp bị sập. Theo trực giác của tôi, có lẽ đây là hệ quả tổng hợp của việc dùng LLM tăng mạnh, thiếu nhân lực, dư chấn hậu đại dịch và bất ổn chính trị
  • Có lẽ vấn đề với các trang trạng thái như thế này chỉ có thể được cải thiện thông qua chỉ trích công khai. Cần có nhiều phản hồi kiểu “Cloudflare thậm chí còn không phát hiện nổi sự cố” hơn

• Có vẻ như kỹ thuật chất lượng của Cloudflare không theo kịp tốc độ phát triển sản phẩm. Tôi từng nghe nói trong ngành quốc phòng, đội chất lượng luôn là những người dày dạn hơn, nhưng ngành phần mềm dường như lại ngược lại

  • Điều đó khiến tôi nhớ đến một giai thoại trong ngành quốc phòng: họ biết có rò rỉ bộ nhớ nhưng vẫn bỏ qua vì cho rằng “trong thời gian sử dụng thì không thành vấn đề”
  • Việc này xảy ra hai lần trong một tháng thì không phải chuyện “đáng khen”. Lặp lại như vậy là không còn gì để biện minh

• Cấu trúc chuyển mạch gói của Internet vốn được thiết kế để chịu đựng các sự cố toàn cục kiểu này.
  Mạng DARPA thời Chiến tranh Lạnh từng có mục tiêu duy trì hệ thống chỉ huy ngay cả khi xảy ra tấn công hạt nhân.
  Đây chính là lúc cần quay lại với mô hình Internet local-first

  • Tham khảo: The Real Internet Architecture
  • Tham khảo: Local-first software

• Gần đây tôi có cảm giác Cloudflare đang khiến Internet trở nên chậm hơn và bất tiện hơn. Các thủ tục như “hãy chứng minh bạn là con người” xuất hiện ngày càng nhiều, và thời gian tải trang cũng bị kéo dài.
  Có vẻ nguyên nhân không phải để bảo vệ website mà là vì chính sách tính phí crawler AI của họ (Giới thiệu Pay-per-crawl)

  • Các thủ tục xác minh con người như vậy không tương thích với trình duyệt cũ, đến mức có website hoàn toàn không thể truy cập
  • Nhưng việc AI tự ý cào nội dung cũng là vấn đề. Cloudflare đang cung cấp cho chủ website một tùy chọn bảo vệ nội dung, và nếu không muốn thì có thể tắt đi
  • Cũng có những lời mỉa mai kiểu: “Giờ thì đến chuyện bí mật theo dõi chúng ta cũng không làm nổi nữa à”

• Hệ thống cấu hình toàn cục của Cloudflare có cấu trúc quá rủi ro vì nó lan ra toàn bộ mạng chỉ trong vài giây mà không có rollout dần dần.
  Cần có một cơ chế giúp xác định ngay lập tức mối tương quan khi thay đổi cấu hình gây ra lỗi

  • Vấn đề là cảnh báo phát ra quá muộn. Thông báo đến sau 2 phút, trong khi lẽ ra phải phát hiện ở cấp độ từng giây.
    Người phụ trách triển khai lẽ ra phải quan sát chỉ số thời gian thực và nhấn nút rollback ngay lập tức.
    Nhật ký thậm chí đã chỉ rõ đến tận dòng mã, nhưng có vẻ đội triển khai và đội hiểu mã nguồn lại bị tách rời
  • Có vẻ họ đã thấy tín hiệu cảnh báo và thử rollback, nhưng chính quá trình đó lại gây thêm vấn đề
  • Các công cụ nội bộ thường có quá nhiều cảnh báo giả, và đôi khi bản thân chúng cũng đang bị hỏng
  • Nghe giống câu đùa: “Đèn báo lỗi động cơ cứ sáng mãi nên tôi tháo luôn cái bóng đèn ra”

• Tỷ lệ uptime của Cloudflare đã rơi xuống dưới 99,9%. Thậm chí còn kém cả PC ở nhà tôi

  • AWS cũng vậy. Lý do tồn tại của cloud là “độ sẵn sàng cao hơn”, nên nếu vừa đắt vừa bất ổn thì hoàn toàn có lý do để tự host
  • Nhưng tự host có thể mất vài ngày để phục hồi nếu phần cứng hỏng hoặc backup thất bại
  • Ở những nơi hay mất điện theo khu vực, ngay cả dùng laptop và pin dự phòng cũng khó trụ nổi. Đôi lúc tôi lại mơ về một hạ tầng tự cung tự cấp
  • Tôi tò mò không biết có thể xem thống kê uptime chính xác hiện tại của Cloudflare ở đâu
  • Dù vậy, việc so sánh trực tiếp PC cá nhân với Cloudflare vẫn là một phép so sánh vô nghĩa

• Với quy mô của Cloudflare thì nhất định phải có môi trường thử nghiệm.
  Mọi thay đổi nên được mô phỏng trong một môi trường mô hình cách ly trước, rồi mới triển khai dần dần.
  Điều quan trọng hơn cả hệ thống kiểu dữ liệu mạnh là các chốt chặn quy trình

  • Công ty chúng tôi dùng quy trình triển khai ba giai đoạn: phát triển → tích hợp nội bộ → production.
    Những đội hay mắc lỗi thì giảm tốc độ, còn đội đáng tin cậy hơn thì có thể đi nhanh.
    Cuối cùng, tốc độ kỹ thuật là vấn đề của lựa chọn. Nếu SLA bị đe dọa thì phải giảm tốc và tăng kiểm thử
  • Cũng có thể dùng người dùng miễn phí làm bãi thử, còn khách hàng trả phí thì nhận phiên bản ổn định
  • Câu “hệ thống kiểu dữ liệu mạnh sẽ không cứu được bạn” có nghĩa là trước thất bại về quy trình, ngôn ngữ cũng bất lực

• Có vẻ chất lượng phần mềm của Cloudflare đang lung lay.
  Từng có cả lỗi mà việc kiểm tra quyền truy cập của tính năng chỉ dành cho doanh nghiệp lại chỉ được thực hiện ở bước cuối cùng

  • Tôi cũng từng gặp một cấu hình không thể rollback trong API Cloudflare.
    Chỉ có thể thay đổi thông qua đội hỗ trợ, và mất vài ngày mới sửa xong
    Liên kết trường hợp liên quan
  • Tôi thậm chí còn nghĩ những lỗi như vậy có thể là do mã do AI viết ra
  • Tôi muốn nghe cụ thể hơn xem “chỉ kiểm tra ở bước cuối cùng” chính xác là có nghĩa gì

• Tôi khá tò mò về văn hóa vận hành của Cloudflare.
  Đang ứng phó với sự cố bảo mật mà vẫn tiếp tục triển khai toàn cục thay vì rollback là một quyết định nguy hiểm.
  Điều đó chẳng khác nào đi ngược nguyên tắc cơ bản “nếu còn nghi ngờ thì hãy rollback”

  • Tuy nhiên lần này là tình huống khẩn cấp như ứng phó với lỗ hổng React Server RCE.
    Nếu trì hoãn triển khai thì khách hàng có thể thực sự bị hack, nên đây là trường hợp mà tốc độ chính là bảo mật
  • Rollback không phải lúc nào cũng là đáp án đúng. Nếu quy trình chưa đủ quen thuộc thì bản thân nó cũng là một rủi ro
  • Thực ra hai lần triển khai đó là ở hai thành phần khác nhau.
    Bản vá đầu tiên chỉ làm lộ ra lỗi tiềm ẩn của bản thứ hai, nên đôi khi roll forward lại thực tế hơn rollback
  • Rất có thể Cloudflare đã tích tụ nợ kỹ thuật trong quá trình tăng trưởng quá nhanh.
    Những sự cố xảy ra dày đặc gần đây có thể là tín hiệu cho thấy khoản nợ đó đang lộ ra