Wikipedia tạm chuyển sang chế độ chỉ đọc do lộ hàng loạt tài khoản quản trị, sau đó đã được khôi phục

• Theo trang trạng thái của Wikimedia Foundation, vào ngày 5 tháng 3 năm 2026, nhiều dịch vụ wiki bao gồm Wikipedia đã tạm thời chuyển sang chế độ chỉ đọc
• Sự việc bắt đầu bằng sự cố truy cập wiki, sau đó chuyển sang giai đoạn hạn chế chức năng chỉnh sửa
• Nguyên nhân không được nêu rõ, nhưng sau khi xác định được vấn đề, quá trình khắc phục đã được tiến hành và một số chức năng khi đó vẫn còn bị vô hiệu hóa
• Đến ngày 6 tháng 3, chức năng đọc-ghi đã được khôi phục, và phần lớn tính năng của các script người dùng cũng được kích hoạt trở lại
• Sau đó Wikimedia vẫn đang tiếp tục giám sát để kiểm tra độ ổn định

---

Tổng quan trạng thái hệ thống Wikimedia

• Trên trang trạng thái, tất cả các hệ thống đều được hiển thị là hoạt động bình thường (All Systems Operational)
  • Cả chức năng đọc lẫn chỉnh sửa đều được ghi là Operational
  • Ghi nhận 131.002 yêu cầu mỗi giây, 0,08 lỗi kết nối do người dùng báo cáo, 1,27 phản hồi lỗi từ wiki, thời gian phản hồi trung bình 0,20 giây và 11,4 lượt chỉnh sửa thành công

Sự cố wiki chuyển sang chế độ chỉ đọc ngày 5~6 tháng 3 năm 2026

• Từ 15:36 UTC ngày 5 tháng 3, một số vấn đề truy cập wiki đã được báo cáo
  • Đến 16:11 UTC, sự cố được ghi nhận và công việc khắc phục bắt đầu
  • Đến 17:09 UTC, trạng thái hiển thị là đã xác định nguyên nhân và đang tiến hành khắc phục
  • Đến 17:36 UTC, chế độ đọc-ghi được khôi phục, nhưng một số chức năng vẫn còn bị vô hiệu hóa
  • Đến 18:36 UTC, chuyển sang giai đoạn giám sát sau khi hoàn tất khắc phục
• Vào 00:05 UTC ngày 6 tháng 3, hệ thống được báo cáo là đang tiếp tục giám sát
  • Sau đó, sự cố được đánh dấu là đã giải quyết (Resolved) với nội dung: “Wiki đã duy trì ở chế độ đọc-ghi trong nhiều giờ và phần lớn chức năng script người dùng đã được khôi phục”

Các sự cố liên quan khác vào đầu tháng 3 năm 2026

• Ngày 3 tháng 3, đã xảy ra độ trễ chỉnh sửa do sự cố máy chủ cơ sở dữ liệu, nhưng được giải quyết ngay trong ngày
  • 10:09 UTC xác định được vấn đề, 10:17 UTC hoàn tất khắc phục rồi chuyển sang giám sát, 10:24 UTC hệ thống trở lại bình thường
• Trong các ngày 25~26 tháng 2, hiệu năng truy cập wiki suy giảm đã được báo cáo và đều được khắc phục, sau đó hoạt động trở lại bình thường
• Ngày 20 tháng 2, đã xảy ra độ trễ truy cập tại khu vực châu Âu, sau khi xác định nguyên nhân, khắc phục và giám sát thì sự cố được giải quyết

Tính năng đăng ký và thông báo

• Người dùng có thể nhận thông báo khi sự cố xảy ra, được cập nhật hoặc được giải quyết qua email, Slack, Webhook, Atom/RSS feed
• Khi đăng ký bằng email, xác thực OTP và bảo vệ reCAPTCHA sẽ được áp dụng
• Đăng ký qua Slack được vận hành theo điều khoản dịch vụ và chính sách quyền riêng tư của Atlassian Cloud

Tóm tắt

• Wikimedia đã trải qua nhiều sự cố gián đoạn chức năng chỉnh sửa và suy giảm hiệu năng vào đầu tháng 3, nhưng tất cả đều đã được khôi phục
• Việc chuyển sang chế độ chỉ đọc trong ngày 5~6 tháng 3 là sự cố lớn nhất, và sau khi khắc phục thì phần lớn chức năng đã trở lại bình thường
• Hiện tại, tất cả các hệ thống vẫn đang duy trì trạng thái hoạt động bình thường

[GN⁺]

Ý kiến trên Hacker News

• Nhìn vào ticket Phabricator đã công khai, có vẻ một kỹ sư bảo mật của Wikimedia Foundation đã tải ngẫu nhiên các user script để thử nghiệm
  Một trong số đó là script ruwiki độc hại đã tồn tại 2 năm, và script này đã tự chèn vào JS toàn cục, lan rất nhanh rồi gây thiệt hại
  Cuối cùng sự việc nghiêm trọng đến mức toàn bộ wiki phải chuyển sang chế độ chỉ đọc

  • Điều đặc biệt gây sốc là người mắc sai lầm này lại là một kỹ sư bảo mật
  • Ban đầu tôi tưởng là có kẻ tấn công đang hoạt động, nhưng khi biết đó là một script độc hại từ trước thì việc xử lý trở nên đơn giản hơn
    Chỉ cần dùng regex để phát hiện script đó và hoàn nguyên các trang bị nhiễm về phiên bản trước
  • Trường hợp này gần như giống sâu Samy
  • Thật khó tin một tổ chức quy mô 300 triệu USD lại mắc lỗi như vậy
  • Tôi tưởng tượng đã có cuộc hội thoại kiểu “Claude, script của cậu đã chạy mã độc rồi!” “Đúng vậy, xin lỗi nhé!”

• Cách con sâu này hoạt động khá thú vị
  Nó tự chèn vào Common.js và User:Common.js của MediaWiki để duy trì lây nhiễm toàn cục, đồng thời dùng jQuery để che giấu dấu vết bị nhiễm
  Nó phá hoại 20 tài liệu ngẫu nhiên, và nếu lây nhiễm được tài khoản quản trị thì dùng tính năng Special:Nuke để xóa tài liệu

  • Có vẻ động cơ chỉ ở mức trò phá phách kiểu “xem tôi có thể gây hỗn loạn đến đâu”
  • Tên miền basemetrika.ru không tồn tại. Nó trả về phản hồi NXDomain
  • Trông như đang cố thử XSS, nhưng thực tế là mã không hiệu quả nên không có tải ngoài nào xảy ra
  • Tôi nghĩ cũng có khả năng AI đã thiết kế con sâu tinh vi này

• Có ý kiến nói rằng vì chính cơ sở dữ liệu là môi trường lây nhiễm nên việc dọn dẹp sẽ là cơn ác mộng digital forensics
  Nhưng nó không chiếm được quyền root, và nếu có bản sao lưu thì có lẽ vẫn khôi phục được

  • Dù có mất vài ngày chỉnh sửa thì xét trên quy mô toàn Wikipedia vẫn là mức chấp nhận được
  • Trên thực tế, việc xử lý không phải rollback DB mà dùng các công cụ hoàn tác wiki thông thường, và chỉ site Meta bị ảnh hưởng chứ không phải bản thân Wikipedia

• Theo điều tra từ cộng đồng wiki tiếng Nga, có vẻ đoạn mã từng được dùng trong các cuộc tấn công phá hoại nhắm vào các wiki thay thế tiếng Nga năm 2023 cũng đã được dùng lần này
  test.js do người dùng ruwiki Ololoshka562 tạo ra chính là script đó,
  và có vẻ nhân viên WMF sbassett đã gọi script này trong lúc thử nghiệm nên nó mới chạy

  • Năm ngoái ruwiki cũng từng bị phá hoại quy mô lớn theo cách tương tự

• Trông giống một sâu XSS kiểu cũ
  Tôi từ lâu đã nghĩ cấu trúc cho phép người dùng chèn JavaScript vào MediaWiki là rất nguy hiểm

  • Điều đáng ngạc nhiên là kiểu XSS này đến giờ vẫn chưa bị dùng cho các cuộc tấn công như đánh cắp mật khẩu
    Nếu lợi dụng lỗ hổng tự động điền của trình duyệt như bài viết này thì có lẽ còn nghiêm trọng hơn nhiều

• Dù có bất mãn với Wikipedia đi nữa, cũng không thể lấy sự việc lần này để biện minh cho quấy rối hay theo dõi đeo bám

• Theo lời một người bạn là biên tập viên wiki, sự việc lần này có vẻ là một vụ hack bằng cross-site scripting (XSS)
  Đoạn mã bắt đầu từ trang người dùng trên wiki tiếng Nga rồi lan qua common.js của Meta,
  và có thể thấy các quản trị viên đang hoàn tác thủ công trên trang Recent Changes

  • Nó trông như một “cuộc tấn công từ Nga”, nhưng giả mạo nguồn gốc theo cách đó là chuyện rất dễ
  • Nhưng một người khác lại cho rằng đoạn mã này rất có thể là biến thể của công cụ hack cũ của Nga mang tên “woodpecker”

• Thêm bối cảnh thì có diễn đàn Wikipediocracy,
  thảo luận tại Village Pump,
  và megathread trên Reddit
  Payload liên quan có thể xem tại liên kết này

  • Bản trên web archive có thể xem an toàn
  • Một số liên kết không mở được vì cần quyền truy cập

• Thật ra chuyện này chỉ là sớm muộn cũng xảy ra
  Wikipedia từ lâu đã có thái độ quá lỏng lẻo với bảo mật
  Chỉ cần có quyền “interface administrator” là có thể sửa JS/CSS toàn cục, và 2FA cũng chỉ mới được đưa vào gần đây
  Hơn nữa còn rất nhiều người dùng đang dùng user script chưa được kiểm chứng
  Bản thân cấu trúc này đã là cơn ác mộng bảo mật, và có lẽ đó cũng là lý do user script bị vô hiệu hóa toàn cục sau sự việc lần này

  • Trước đây ngay cả trang chính cũng từng bị xóa (liên kết)
  • Hiện có khoảng 137 interface administrator, và phần lớn là nhân viên Wikimedia nên ít nhất vẫn là những người đã được thẩm tra
  • Internet đang ngày càng trở thành môi trường thù địch hơn, nên tôi cảm thấy cần có quyên góp hoặc hỗ trợ kỹ thuật để giải quyết các vấn đề kiểu này
  • User script qua tiện ích mở rộng trình duyệt như TamperMonkey vẫn tồn tại, nên không thể chặn hoàn toàn
  • Thực tế, theo wiki tiếng Anh thì chỉ có 15 interface administrator đang hoạt động (tham khảo)

• Giờ thì cũng có người nửa đùa nửa thật rằng vì AI đã cào sạch Wikipedia, nên chẳng còn ai trực tiếp dùng Wikipedia nữa