Ngày 29 tháng 10 năm 2026, nhà cung cấp dịch vụ giám sát DebugBear yêu cầu khách hàng dùng sản phẩm Real User Monitoring (RUM, giám sát người dùng thực) gỡ đoạn mã nhúng khỏi website. Nếu website của bạn đang tải đoạn mã này, đó là việc cần làm ngay hôm nay. Nếu không, sự cố vẫn là lý do tốt để rà soát những đoạn mã bên thứ ba đang chạy trong trang của bạn. Dưới đây là việc cần làm, những gì các thông báo công khai xác lập tính đến lần kiểm tra ngày 2 tháng 11 năm 2026, và những gì còn chưa được xác minh.
Việc cần làm ngay
Đây là các kiểm tra thực tế cho chủ website và đơn vị vận hành, không phải yêu cầu bắt buộc từ nhà cung cấp.
- Xác định vị trí tích hợp thật sự trong giao diện, trình quản lý thẻ và plugin, và ghi lại những trang yêu cầu đăng nhập hoặc nhạy cảm có tải đoạn mã này.
- Nếu đang dùng DebugBear RUM, hãy làm theo hướng dẫn gỡ bỏ có ghi ngày và xin hướng dẫn khôi phục hiện hành từ nhà cung cấp trước khi bật lại bất cứ thứ gì.
- Gỡ mã nhúng khỏi các trang và xóa các bản sao trong bộ đệm còn tham chiếu đến nó. Sau đó kiểm tra biểu mẫu và thanh toán vẫn hoạt động bình thường, và xác nhận không còn yêu cầu tải đoạn mã trong phiên trình duyệt được ủy quyền.
- Không tự tải về hoặc chạy mã nghi ngờ để kiểm tra.
- Khi có thể, giữ lại nhật ký phân phối và bằng chứng trang hiện có trước khi dọn dẹp theo cách không thể khôi phục.
- Xác định mức phơi nhiễm và rủi ro phiên thực tế cùng đơn vị vận hành. Thực hiện các hành động có mục tiêu với phiên hoặc thông tin đăng nhập khi có bằng chứng, không đổi toàn bộ khóa hay khôi phục toàn bộ bản sao lưu chỉ vì tên nhà cung cấp.
- Rà soát danh mục mã bên thứ ba và quyền mỗi đoạn mã cần. Giữ các tích hợp không cần thiết khỏi trang thanh toán và trang tài khoản.
- Lên kế hoạch áp dụng Subresource Integrity (SRI) và Chính sách bảo mật nội dung (CSP) đã kiểm thử ở nơi tương thích. SRI đối chiếu các byte tải về với mã băm đã ghim trước khi thực thi và từ chối tệp không khớp; dùng xuyên nguồn gốc cần máy chủ hỗ trợ CORS và thuộc tính crossorigin phù hợp. Nó phù hợp với tài nguyên cố định đã được xem xét và cập nhật có kiểm soát, không phải đoạn mã thay đổi liên tục không có phiên bản. CSP dạng danh sách máy chủ cho phép chỉ xác minh nguồn gốc, không xác minh nội dung byte. Ghim một tệp đang chứa mã độc không tạo ra sự tin cậy, và cả hai biện pháp đều không phải bảo đảm. Hãy kiểm thử trước khi bật và không làm hỏng biểu mẫu kinh doanh.
Nhà cung cấp đã nói gì
Trong thông báo công khai đăng ngày 29 tháng 10 lúc 18:00 UTC, DebugBear xác nhận một sự cố bảo mật đang diễn ra và hướng dẫn khách hàng RUM gỡ mã nhúng khỏi website của họ. Đây là hướng dẫn có ghi ngày. Tính đến lần kiểm tra ngày 2 tháng 11, chúng tôi chưa xác minh được thông báo an toàn nào mới hơn, và trang chủ cùng blog của nhà cung cấp không truy cập được trong các lần kiểm tra. Thông báo này không xác lập dịch vụ hôm nay còn bị ảnh hưởng hay không, nguyên nhân sự cố là gì, có phải mọi khách hàng đều bị ảnh hưởng, hay giám sát tổng hợp (synthetic monitoring) có liên quan không. RUM là đoạn mã nhúng trong trang của bạn; giám sát tổng hợp chạy từ phía nhà cung cấp và không cần mã nhúng.
Các nhà nghiên cứu phát hiện gì
Hudson Rock báo cáo ngày 29 tháng 10 rằng họ đã lấy về đoạn mã DebugBear CDN theo dự án mà Polymarket sử dụng, dưới dạng văn bản không thực thi, hai lần trong ngày hôm đó. Các nhà nghiên cứu mô tả logic tìm kiếm ứng dụng giao dịch hoặc bộ ký đã xác thực sẵn và tìm cách chuyển tài sản. Phân tích tĩnh cho thấy ý đồ. Nó không chứng minh mọi yêu cầu ký đều được thực hiện âm thầm hay các giao dịch chuyển đã hoàn tất, vì bộ ký có thể hiện lời nhắc hoặc từ chối. Dấu thời gian build bản sản xuất trong siêu dữ liệu tệp cho thấy việc gỡ bỏ không phải bằng chứng đã ngăn chặn thực tế hay các tab đang mở sẵn đều an toàn.
Phân tích do ohey.ca công bố ngày 29 tháng 10 xem xét cùng mẫu dành riêng cho Polymarket, đối chiếu với bản lưu trữ và dữ liệu chuỗi công khai. Phân tích này củng cố việc đoạn mã bị thay thế bằng mã độc và hướng dẫn gỡ bỏ của nhà cung cấp. Mục tiêu là đoạn mã của một dự án, không phải bằng chứng mọi dự án DebugBear đều nhận mã độc. The Hacker News đưa tin về phát hiện này ngày 1 tháng 11.
Những điều các nguồn trên chưa xác minh:
- Nguyên nhân gốc và cơ chế xâm nhập ban đầu.
- Có khách hàng nào ngoài dự án này bị ảnh hưởng hay không.
- Khung thời gian phân phối chính xác và tổng mức ảnh hưởng.
- Bất kỳ thông báo an toàn mới hơn nào từ nhà cung cấp.
- Thông tin về thiệt hại và hoàn tiền ngày 25 tháng 6 được nhắc đến trong các bài đưa tin là vấn đề riêng, tách biệt với phát hiện về đoạn mã ngày 29 tháng 10.
Vì sao điều này quan trọng với website doanh nghiệp nhỏ
Đoạn mã bên thứ ba thực thi trong ngữ cảnh của trang nhúng nó. Từ đó, nó có thể đọc cây DOM của trang và dữ liệu mà mã có thể truy cập, và có thể yêu cầu các hành động mà ứng dụng cho phép, như mẫu mã trên Polymarket đã làm khi tìm bộ ký đã xác thực sẵn. Những gì nó làm được bị giới hạn bởi các ranh giới của trình duyệt, cơ chế ủy quyền phía máy chủ và bất kỳ bước xác nhận nào mà bộ ký hoặc bước thanh toán yêu cầu. Vì vậy rủi ro là có điều kiện: nó phụ thuộc vào trang nào tải đoạn mã và khách truy cập làm gì ở đó, không phụ thuộc vào tên nhà cung cấp.
Những giới hạn còn lại
Gỡ mã nhúng khỏi các trang đã cập nhật chỉ ngăn đoạn mã tải đó trên chính các trang ấy. Các trang còn trong bộ đệm, các tab đã mở từ trước, các đường tiêm mã khác và rủi ro phiên thực tế của khách truy cập trước đó vẫn cần được kiểm tra. Việc gỡ bỏ không phải bằng chứng những khách truy cập trước đó đã an toàn hay sự cố đã kết thúc. ViWeb chưa điều tra khách hàng nào và chưa xử lý vụ việc này.