Báo cáo bảo mật Web3 tháng Tám: 29 sự cố lớn, mất hơn 68,29 triệu USD

The Beosin Alert platform reports that in August 2026, total losses from various security incidents amounted to approximately $76.15 million, with a total of 『29』 major security incidents occurring, primarily due to contract vulnerabilities. Among these, 18 incidents were caused by contract/network vulnerabilities, and 2 incidents resulted from private key leaks. Smart contract security and private key management remain weak points in Web3 security.

Ngày 13 tháng 8, địa chỉ người dùng cá nhân 0x13e3....179e bịrò rỉ khóa riêngđánh cắp các tài sản mã hóa như WBTC, cbBTC, LDO, USDS, CRV, tổng tổn thất khoảng 25,6 triệu USD, là sự kiện bảo mật gây tổn thất thực tế lớn nhất. Ngày 30 tháng 8,Cronos giao thức vay mượn Tectonic trên mạng Cronos bị tấn công bởi hacker do lỗ hổng hợp đồng, ước tính tổn thất khoảng 74 triệu USD. Cuộc tấn công này khiến mạng Cronos phải thực hiện các biện pháp khẩn cấp, tạm dừng mạng và hoàn tác giao dịch, cuối cùng hacker đã chuyển thành công khoảng 6 triệu USD sangEthereum mạng.

Ngoài ra, chuỗi khối Harmony đã bị đúc thêm khoảng 4 tỷ ONE do lỗ hổng, với tổn thất danh nghĩa vượt quá 4 triệu USD, nhưng cuối cùng đã xóa trạng thái của các đồng tiền giả bằng cách hoàn tác giao dịch, do đó không tính vào tổn thất.

Tháng này, các mục tiêu bị tấn công bao gồm nhiều loại như chuỗi công cộng, giao thức cho vay, ứng dụng ví, hợp đồng token, cầu liên chuỗi và người dùng cá nhân, trong đó các dự án DeFi chịu tổn thất lớn nhất, lên tới 33,09 triệu USD; trong khi các địa chỉ cá nhân bị mất khoảng 28,4 triệu USD do rò rỉ khóa riêng hoặc bị lừa đảo. Hợp đồng token bị tấn công nhiều nhất, với 10 lần; hợp đồng DeFi đứng thứ hai với 9 lần bị tấn công.

Chuỗi bị mất nhiều tiền nhất vào tháng 5 là Ethereum, với tổn thất vượt quá 48,58 triệu USD, tổng cộng 15 sự cố bảo mật; hiện nay, phần lớn các giao thức DeFi và các cuộc tấn công lừa đảo nhắm vào các đại gia vẫn chủ yếu tập trung vào Ethereum. Chuỗi có số lần xảy ra sự cố bảo mật nhiều thứ hai là BNB Chain, nhưng mục tiêu chính là các hợp đồng token, với mức tổn thất nhỏ. Ngoài ra, các chuỗi công như Cronos, Base, Harmony, Bitcoin và Solana cũng ghi nhận các sự cố bảo mật, cho thấy xu hướng tấn công đa chuỗi.

1. Tectonic và Moonwell: Thao túng giá

Tectonic và Moonwell là các giao thức vay mượn trên chuỗi, nguyên nhân bị tấn công đều do giá của các tài sản thế chấp là các token có thanh khoản yếu bị thao túng, từ đó vay ra lượng tài sản vượt quá giá trị tài sản được định giá giả tạo để kiếm lời. Trong vụ tấn công Tectonic, kẻ tấn công đã đẩy giá của token quản trị $TONIC của giao thức Tectonic tăng 100 lần, qua đó nhận được hạn mức vay khoảng 74 triệu USD và sau đó vay ra các tài sản như USDT. Sau sự cố, mạng Cronos đã tạm dừng ngay lập tức việc tạo khối toàn bộ chuỗi, và kẻ tấn công đã chuyển khoảng 6 triệu USD qua chuỗi khác sang Ethereum trước khi mạng bị tạm dừng. Sau đó, mạng Cronos đã thực hiện rollback để khôi phục tổn thất.

Địa chỉ lợi nhuận của hacker trên Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD và dòng chảy của số tiền bị đánh cắp:

Hiện vẫn còn khoảng 2659 ETH được lưu giữ tại 0xc4041, sau khi 140.1 ETH được chuyển đến 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c, số này tiếp tục được phân tán gửi đến nhiều địa chỉ mới được tạo.

Moonwell bị mất khoảng 8,7 triệu USD do kẻ tấn công thao túng giá của đồng MAMO có thanh khoản thấp để vay cbBTC:

Hai cuộc tấn công này không dựa trên lỗ hổng hợp đồng thông minh, mà do giao thức tự xác định giá trị tài sản thế chấp dựa trên thanh khoản spot yếu, dẫn đến tính toán sai giá trị tài sản thế chấp. Để ngăn chặn các cuộc tấn công như vậy, giao thức có thể thu thập dữ liệu từ nhiều nguồn thông qua nhiều oracle và thực hiện các đánh giá bổ sung khi giá biến động mạnh.

2. Harmony: Cuộc tấn công tái phát

Harmony là một Layer 1 hỗ trợ sharding, vận hành bốn sharding và chuyển tài sản giữa chúng thông qua cơ chế chéo sharding bất đồng bộ dựa trên phiếu thu. Sharding nguồn tạo ra phiếu thu mã hóa cho các giao dịch đi ra, trong khi sharding đích chịu trách nhiệm xác minh phiếu thu đó và bằng chứng Merkle của nó có khớp với tiêu đề khối nguồn đã ký hay không, và mỗi phiếu thu chỉ có thể được sử dụng một lần.

Lỗ hổng trong cuộc tấn công này nằm ở phần dư thừa của hệ thống shard của Harmony. Trước đây, Harmony kiểm tra xem phiếu thu shard đã được sử dụng chưa bằng cách xem hai trường CXMerkleProof.ShardID và BlockNum,

Vì hai trường này nằm ngoài tiêu đề khối đã ký, nên kẻ tấn công có thể chỉnh sửa chúng mà không làm hỏng bất kỳ chức năng nào hiện có. Trong cuộc tấn công này, kẻ tấn công đã lấy một biên lai chéo shard và sửa đổi ShardID và BlockNum trong đó, khiến chương trình kiểm tra nhận diện nó là một biên lai hoàn toàn mới. Shard mục tiêu đã chấp nhận biên lai đã được sửa đổi và ghi nhận lại, trong khi shard ban đầu không trừ đi tài sản tương ứng.

Đây là một cuộc tấn công replay rất điển hình. Đối với bất kỳ trường nào được sử dụng làm “thẻ dùng một lần”, nó phải là một phần của chữ ký tiêu đề. Khi xác minh biên lai, nên trực tiếp đọc ID mảnh và số khối từ tiêu đề khối đã được xác thực, thay vì tin tưởng các trường chưa được xác thực trong cấu trúc chứng minh.

3. Tài chính kỳ hạn: Cuộc tấn công quản trị

Term Finance là một giao thức vay mượn lãi suất cố định DeFi, trong đó mỗi kho (Vault) đều là một Vault ERC-4626 dựa trên mã Yearn V3. Việc quản trị kho của Term Finance không phải là bỏ phiếu phê duyệt, mà là bỏ phiếu phủ quyết. Khi người điều phối đề xuất đề xuất thay đổi thông số, người quản trị sẽ mở một cửa sổ yêu cầu các chủ sở hữu token LP đưa ra phản đối. Ngưỡng bỏ phiếu quản trị có lỗ hổng nghiêm trọng:

● Thiếu ngưỡng tuyệt đối về số phiếu hoặc vốn: Điều kiện để đề xuất được thông qua là isSupportThresholdReached() và isMinParticipationReached() chỉ kiểm tra tỷ lệ tương đối, chứ không phải số phiếu tuyệt đối. Điều này có nghĩa là, chỉ cần đáp ứng đa số tương đối, đề xuất đã có thể được thông qua, bất kể tổng số người bỏ phiếu hoặc tổng lượng vốn tham gia.

● Mức độ tham gia cực kỳ thấp: Hầu như không có người gửi tiền nào đóng gói cổ phần kho (tmvETH) thành token quản trị (gtmvETH) để tham gia bỏ phiếu. Điều này dẫn đến tổng nguồn cung token quản trị của kho liên quan cực kỳ thấp.

Các kẻ tấn công đã khai thác lỗ hổng thiết kế nêu trên để thực hiện cuộc tấn công quản trị vào kho lưu trữ với chi phí cực kỳ thấp:

(1) Nhận quyền bỏ phiếu: Kẻ tấn công đổi khoảng 0,5 ETH lấy khoảng 0,485 phần trăm quỹ tmvETH và đóng gói 1:1 thành 0,485 token quản trị gtmvETH để có quyền bỏ phiếu.

(2) Đề xuất ác ý: Khi kẻ tấn công tạo đề xuất, hợp đồng ghi nhận tổng nguồn cung token quản trị tại thời điểm đó chỉ là 0,535 gtmvETH. Điều này có nghĩa là 0,485 gtmvETH mà kẻ tấn công nắm giữ đã chiếm 90,66% tổng lượng.

(3) Bỏ phiếu và thực thi: Kẻ tấn công, với tư cách là người bỏ phiếu duy nhất, đã bỏ phiếu đồng ý. Do không có phiếu phản đối, tỷ lệ ủng hộ của họ vượt xa ngưỡng 50%; đồng thời, quyền bỏ phiếu cá nhân của họ cũng vượt quá ngưỡng tham gia tối thiểu (minVotingPower) được tính dựa trên tổng nguồn cung cực kỳ thấp.

(4) Rút tài sản: Sau khi đề xuất được thông qua, một thao tác độc hại đã được thực hiện để rút tài sản trong kho (WETH)

Kẻ tấn công đã sử dụng cùng một thủ pháp để xâm nhập vào 6 kho tiền của Term Finance, gây thiệt hại khoảng 8,5 triệu USD.

Cuộc tấn công này cũng là một cuộc tấn công quản trị giao thức trên chuỗi rất điển hình. Đối với quản trị trên chuỗi, đội ngũ dự án nên thiết lập các điểm kiểm tra sau để phòng ngừa:

● Thiết lập số phiếu tuyệt đối hoặc ngưỡng vốn tối thiểu: Các đề xuất quản trị không thể chỉ dựa vào tỷ lệ tương đối để thông qua. Phải thiết lập một ngưỡng cứng dựa trên số lượng tuyệt đối, ví dụ yêu cầu số phiếu thuận phải đạt một mức tiền nhất định (như 1 triệu USD) hoặc số lượng địa chỉ độc lập.

● Trang bị người giám hộ hoặc đường dẫn hủy bỏ cho thời gian khóa: Mặc dù việc thực thi quản trị thường có độ trễ, nhưng điều này chỉ giữ lại một khoảng thời gian phản ứng. Dự án phải thiết lập cơ chế giám hộ hiệu quả (Guardian) hoặc đường dẫn hủy bỏ đề xuất trong giai đoạn trễ thực thi. Khi phát hiện đề xuất độc hại trong khoảng thời gian trễ, người giám hộ có thể can thiệp ngay lập tức và hủy bỏ.

● Theo dõi mức độ tham gia quản trị: Giao thức nên thiết lập việc theo dõi thời gian thực đối với mức độ tham gia quản trị của từng kho. Khi phát hiện tổng lượng token quản trị hoặc tỷ lệ tham gia bỏ phiếu của một kho nào đó thấp bất thường, cần kịp thời cảnh báo, thậm chí tự động kích hoạt các biện pháp bảo vệ.

Xu hướng mối đe dọa bảo mật Web3

Xu hướng sâu sắc nhất trong bảo mật Web3 năm 2026 là sự mở rộng có hệ thống bề mặt tấn công. Các lỗ hổng đang đồng thời xuất hiện ở cấp độ mã, hoạt động hàng ngày và các thao tác tương tác; chỉ dựa vào một vài cuộc kiểm tra bảo mật hoặc công cụ không thể bao quát các lỗ hổng về an toàn vận hành, quản trị trên chuỗi và logic kinh doanh. Điều này đặt ra những thách thức mới cho các dự án Web3 trong việc xây dựng hệ thống phòng thủ bảo mật.

Ngoài ra, các cuộc tấn công vào hợp đồng DeFi và người dùng cá nhân đang diễn ra thường xuyên. Lỗ hổng hợp đồng hoặc quyền được cấp dễ bị kẻ tấn công khai thác; các nhà phát triển hoặc người vận hành hợp đồng nên rà soát lại tính bảo mật của hợp đồng, đặc biệt đối với các hợp đồng xử lý nghiệp vụ cốt lõi, cần thực hiện nhiều lần kiểm toán bảo mật bởi nhiều bên. Đối với người dùng cá nhân, nên định kỳ sử dụng trình duyệt blockchain hoặc công cụ hủy cấp quyền để kiểm tra và hủy các quyền đã cấp cho hợp đồng không còn sử dụng, đồng thời tìm hiểu thêm các kỹ thuật lừa đảo phổ biến và mới xuất hiện để nâng cao nhận thức bảo mật.

Bài viết này được đội ngũ an toàn Beosin biên soạn dựa trên hệ thống cảnh báo an toàn Beosin Alert, dữ liệu trên chuỗi và phân tích hậu sự công khai từ phía dự án. Nếu có bất kỳ câu hỏi nào, vui lòng liên hệ và phản hồi với chúng tôi.