Phân tích cuộc tấn công quản trị X100: Cho vay chớp nhoáng + thuê phiếu làm cạn kho bạc và năm tiêu chí tự kiểm tra an toàn quản trị
Vào ngày 24 tháng 10 năm 2026, X100 Global trên Ethereum đã trở thành mục tiêu của một cuộc tấn công quản trị sử dụng cho vay chớp nhoáng: kẻ tấn công…
Vào ngày 24 tháng 10 năm 2026, dự án X100 Global trên Ethereum đã bị tấn công bằng cơ chế quản trị khai thác khoản vay chớp nhoáng (flash loan): kẻ tấn công chiếm giữ hai trong ba ghế “Thượng viện (Senate)”, tiếp cận kho bạc và khiến token X lao dốc 96%. Cơ quan an ninh Blockaid xác định tổn thất USDT khoảng 4,85 triệu đô la Mỹ, trong khi Chainalysis ghi nhận số tiền bẩn được đổi sang ETH rồi phân bổ vào bốn ví, mỗi ví nắm giữ 400 ETH.
Điều thực sự đáng chú ý trong sự việc này chính là phương thức tấn công: không có lỗ hổng mã nguồn, không rò rỉ khóa riêng — kẻ tấn công chuyển tiền đi chỉ bằng “bỏ phiếu hợp pháp”. Nếu trong danh mục đầu tư của bạn có bất kỳ token nào tích hợp cơ chế quản trị, danh sách kiểm tra dưới đây rất đáng để bạn xem qua một lượt.
Tấn công diễn ra như thế nào: Ba bước “hợp pháp” rút sạch kho bạc
Theo dữ liệu giám sát trên chuỗi và phân tích lại từ nhiều phía do Blockaid thực hiện, quy trìnhtầm chừng như sau:
- Vay token quản trị bằng flash loan. Kẻ tấn công vay một lượng đủ lớn token X trong một giao dịch duy nhất để giành quyền biểu quyết — khoản vay này được hoàn trả ngay trước khi giao dịch kết thúc, nên vốn tự có gần như bằng không.
- Chiếm ghế Thượng viện. Cơ chế quản trị của X100 Global áp dụng mô hình “ghế Thượng viện”, tổng cộng ba ghế. Kẻ tấn công đã chiếm được hai ghế, từ đó nắm đa số quyền kiểm soát.
- Đề xuất và thực thi trong cùng một giao dịch. Cơ chế quản trị cho phép bỏ phiếu tức thì, không chụp ảnh trạng thái (no snapshot), không khóa thời gian (no time lock), không yêu cầu thời gian nắm giữ tối thiểu (no minimum holding period). Do đó, đề xuất được đưa ra và thực thi ngay trong cùng một giao dịch: bán 400.000 token X trong kho bạc vào một pool do chính kẻ tấn công tạo ra, rút toàn bộ thanh khoản; sau đó một kẻ tấn công khác đốt bỏ vị thế Uniswap V3 trên hợp đồng Freezer, trong khi một bên thứ ba sử dụng cùng đường dẫn Thượng viện để rút đi khoảng 550.000 token X.
Đây chính là điểm đáng sợ của “tấn công quản trị”: mã hợp đồng có thể hoàn toàn đúng, kết quả bỏ phiếu cũng “có hiệu lực thực tế”, nhưng quyền ra quyết định có thể được thuê trong vài giây. Khi “chi phí kiểm soát quyền quản trị” thấp hơn “giá trị tài sản trong kho bạc”, thì cuộc tấn công trở nên khả thi về mặt kinh tế.

Tấn công quản trị không hiếm — chỉ là ít khi lên trang nhất
Theo phân loại dữ liệu sự cố công khai từ DefiLlama, tính đến nay năm 2026 đã ghi nhận tổng cộng 312 sự cố an ninh, trong đó chỉ có 10 vụ được xếp vào nhóm “quản trị (Governance)”. Số lượng ít, nhưng mức độ phá hoại từng vụ cực kỳ nghiêm trọng — vì chúng trực tiếp lấy đi toàn bộ kho bạc, chứ không chỉ khai thác chênh lệch giá từ một pool nào đó. Trong bộ dữ liệu này, X100 được đánh dấu riêng là “Tấn công quản trị bằng flash loan (Flashloan Governance Attack)”, là ví dụ tiêu biểu nhất của loại hình này.
Điều này cũng giải thích vì sao tấn công quản trị dễ bị bỏ qua: kẻ tấn công không cần viết mã khai thác lỗ hổng, không cần lừa đảo để chiếm khóa riêng, mà chỉ cần tìm ra “quyền ra quyết định có thể thuê được” trong các tham số quản trị. Các trường hợp tương tự bao gồm ApeCoin năm 2022 (cũng được gán nhãn là tấn công quản trị bằng flash loan). Trong danh sách sự cố DeFi tháng 10 năm 2026, phần lớn là thao túng giá, còn tấn công quản trị chỉ có duy nhất vụ này — nhưng nó đã cướp đi gần 5 triệu đô la Mỹ.
Cách đánh giá một giao thức quản trị có an toàn hay không: Năm tiêu chí kiểm tra
Những điểm yếu trong cơ chế quản trị của X100 rất điển hình — và ngược lại, chúng chính là danh sách kiểm tra dành cho bạn. Mỗi khi gặp một giao thức có kho bạc, hãy đặt năm câu hỏi sau:
- Đề xuất có dùng ảnh chụp trạng thái (snapshot) không? Nếu quyền biểu quyết được tính theo “số dư hiện tại”, thì việc vay token bằng flash loan sẽ cho phép bỏ phiếu; nếu có ảnh chụp trạng thái tại một khối lịch sử (historical block snapshot), thì token vay không có quyền biểu quyết. X100 thuộc nhóm đầu tiên.
- Có khóa thời gian (time lock) trước khi thực thi không? Sau khi đề xuất được thông qua, phải chờ một khoảng thời gian (thường là 24–72 giờ) mới được thực thi — đây là lớp đệm quan trọng nhất, giúp cộng đồng phát hiện sớm và rút vốn kịp thời. X100 không có time lock, đề xuất và thực thi hoàn tất trong cùng một giao dịch.
- Có yêu cầu thời gian nắm giữ tối thiểu không? Yêu cầu người nắm quyền biểu quyết phải giữ token đủ một thời gian nhất định, từ đó vô hiệu hóa hoàn toàn mô hình flash loan.
- Việc rút tiền từ kho bạc cần những quyền hạn gì? Kho bạc do một hợp đồng quản trị duy nhất kiểm soát, hay được bảo vệ bởi đa chữ ký (multi-sig) kết hợp time lock? Có thể chuyển toàn bộ tài sản ra ngoài trong một giao dịch duy nhất không?
- Quyền quản trị có thể cho thuê được không? Nếu token quản trị có thanh khoản sâu trên DEX và không bị khóa, bất kỳ ai cũng có thể mua tạm đủ số lượng để đạt đa số phiếu.
Nếu đồng thời xảy ra cả ba tình huống “không snapshot + không time lock + không thời gian nắm giữ tối thiểu”, thì kho bạc của giao thức đó về bản chất là mở cửa cho các cuộc tấn công bằng flash loan.
Là người dùng bình thường, bạn có thể làm gì
- Đừng chỉ nhìn vào TVL và APY. Lợi suất cao thường đồng nghĩa với việc giao thức đang dùng các tham số mạo hiểm để mở rộng quy mô — và tham số càng mạo hiểm thì lợi ích từ việc thao túng càng lớn.
- Kiểm tra phạm vi bao quát của báo cáo kiểm toán. Nhiều báo cáo kiểm toán chỉ tập trung vào logic hợp đồng, không xem xét các tham số quản trị (snapshot, time lock). Kiểm toán đạt yêu cầu ≠ quản trị an toàn.
- Ưu tiên chọn các giao thức có time lock. Đây là tiêu chí cứng hữu ích nhất, đồng thời dễ tra cứu công khai.
- Không nên gửi số tiền lớn vào một giao thức duy nhất. Sau khi X100 lao dốc 96%, thanh khoản gần như biến mất — muốn thoát cũng không chạy nổi.
- Ngay lập tức rút vốn khi thấy “đề xuất quản trị bất thường”. Khi xuất hiện đề xuất lạ trên diễn đàn cộng đồng hoặc X, time lock là cửa sổ duy nhất để bạn chạy thoát; với các giao thức không có time lock, bạn chỉ còn biết nuối tiếc sau khi sự việc xảy ra.
Nếu muốn phân tích hệ thống về các loại mất mát và hồ sơ bồi thường, bạn có thể tham khảo phương pháp phân tích tương tự trong bài Tổng kết lại vụ tấn công chuỗi cung ứng ví cứng và Kiểm tra chuyên sâu về an ninh của Gate: đầu tiên xem lịch sử công bố, sau đó kiểm tra tham số kỹ thuật, cuối cùng mới xem cách truyền thông quảng bá.
Các câu hỏi thường gặp
Số tiền bị đánh cắp trong tấn công quản trị có thể thu hồi được không?
Xác suất rất thấp. Kẻ tấn công đã đổi stablecoin sang ETH và phân tán vào nhiều ví khác nhau; việc theo dõi trên chuỗi chỉ có thể đánh dấu địa chỉ, chứ không thể bắt buộc thu hồi. Trừ khi đội dự án có quỹ dự trữ riêng hoặc phối hợp với sàn giao dịch để đóng băng khoản nạp vào, nếu không thì tổn thất này gần như được coi là vĩnh viễn.
Token X của X100 còn đáng để nắm giữ không?
Theo dữ liệu công khai, token X đã lao dốc 96% và thanh khoản gần như cạn kiệt. Vấn đề với loại token này không phải là “có hồi phục hay không”, mà là “còn có người mua không” — một tài sản thiếu thanh khoản thì giá trên bảng cân đối không còn ý nghĩa. Mọi quyết định “bắt đáy” đều nên dựa trên sự thật công khai, chứ không phải cảm xúc cộng đồng.
Tại sao nói đây không phải là “lỗ hổng hợp đồng”?
Vì hợp đồng đã thực thi đúng logic được thiết kế, và cuộc bỏ phiếu cũng đáp ứng đầy đủ các quy tắc quản trị. Vấn đề nằm ở việc thiết kế tham số quản trị (không có chụp ảnh trạng thái – snapshot, không có khóa thời gian – time lock), khiến “quy trình hợp pháp” vô tình trở thành con đường tấn công. Đây cũng là lý do vì sao kiểm toán mã nguồn thuần túy không thể phát hiện ra lỗ hổng này.
Các giao thức lớn thì sẽ không gặp vấn đề này sao?
Không. Quy mô càng lớn, tính thanh khoản của token quản trị càng cao, chi phí thuê phiếu bầu (vote renting) so với quy mô kho bạc thậm chí còn thấp hơn. Điểm khác biệt là các giao thức lớn thường áp dụng khóa thời gian và chụp ảnh trạng thái, từ đó làm tăng chi phí tấn công.
Làm sao tự tra cứu dữ liệu của DefiLlama?
Bộ dữ liệu công khai nằm tại api.llama.fi/hacks, trả về định dạng JSON gồm ngày tháng, tên dự án, classification (phân loại), technique (kỹ thuật tấn công), số tiền thiệt hại và chuỗi khối (chain). Bạn có thể tự tổng hợp theo năm và phân loại — không cần phụ thuộc vào các con số được truyền thông tóm tắt lại.
cảnh báo rủi ro: Giá tài sản mã hóa biến động mạnh, bạn có thể mất toàn bộ số vốn đầu tư. Bài viết này không cấu thành lời khuyên đầu tư. Các chi tiết sự kiện X100 được xác nhận dựa trên báo cáo từ các tổ chức an ninh như Blockaid và thông tin cập nhật sau đó từ đội ngũ dự án; con số thiệt hại hiện vẫn đang được thống kê và có thể thay đổi. Dữ liệu từ DefiLlama là kết quả tổng hợp từ các bộ dữ liệu công khai; cách thống kê có thể khác biệt so với cách trình bày của truyền thông — vui lòng tham khảo trực tiếp bộ dữ liệu gốc. Các giao thức DeFi tiềm ẩn nhiều rủi ro: từ hợp đồng thông minh, quản trị đến oracle — bạn cần tự đánh giá kỹ lưỡng.