Ví lạnh Coldcard bị hack – Ví nóng SecondFi gặp lỗi bảo mật nghiêm trọng – Lưu trữ Bitcoin và Crypto ở đâu mới thực sự an toàn

Vụ việc Coldcard – dòng ví lạnh nổi tiếng của Coinkite – bị khai thác đang gây chấn động toàn bộ cộng đồng tiền mã hóa. Điều khiến giới Crypto bàng hoàng nhất là hacker không cần tiếp xúc vật lý với ví, không cần nạn nhân kết nối Internet hay click vào link độc hại, mà vẫn rút sạch Bitcoin ngay cả khi chiếc ví vật lý đang nằm yên trong két sắt. Tính đến những ngày đầu tháng 8/2026, các thống kê từ Galaxy Research cho thấy đã có hơn 4.500 địa chỉ ví bị rút sạch, thiệt hại ước tính từ khoảng 130 triệu USD (khoảng 2055+ BTC) và chưa có dấu hiệu dừng lại.

Trước đó, vào tháng 06/2026, một lỗ hổng nghiêm trọng của ví nóng SecondFi cũng đã làm cộng đồng Cardano chao đổi

Chi tiết vụ việc Ví lạnh Coldcard bị hack

Thời điểm vấn đề được phát hiện

Vụ việc bắt đầu bộc lộ trên dữ liệu blockchain vào sáng sớm ngày 31 tháng 7 năm 2026 (khoảng 01:31 UTC).

• Dấu hiệu: Một chuỗi các giao dịch rút tiền tự động quét sạch hàng loạt ví Bitcoin đơn chữ ký được tạo từ thiết bị Coldcard. Trong vòng chỉ 25 phút đầu tiên, khoảng 594 BTC đã bị chuyển đi mà nạn nhân không hề ký duyệt hay tương tác.
• Kẻ thực hiện: Kẻ tấn công chính là bên đầu tiên phát hiện ra lỗ hổng mã nguồn này. Hacker đã âm thầm chạy phần mềm dò quét toàn bộ không gian khóa 2^40 bị suy giảm trên máy tính cá nhân/máy chủ để tìm private key và thực hiện lệnh rút.

Đơn vị chính thức đưa ra cảnh báo và xác nhận lỗ hổng đầu tiên là Coinkite (công ty sản xuất Coldcard):

• Cảnh báo ban đầu: Ngày 30/7/2026 (giờ địa phương Bắc Mỹ, trùng thời điểm sóng rút tiền chuẩn bị hoặc vừa diễn ra), Coinkite đã đăng phát đi Cảnh báo Bảo mật khẩn cấp khuyên người dùng kiểm tra lại các ví Coldcard.
• Báo cáo kỹ thuật: Trong cùng ngày 30/7/2026, Coinkite xuất bản bài viết “Technical Deep Dive into the Entropy Issue“ trên trang blog chính thức để giải thích chi tiết lỗi liên quan đến trình biên dịch C và hàm MICROPY_HW_ENABLE_RNG bị bỏ qua.

Ngay sau khi sự cố rút tiền diễn ra và Coinkite ra thông báo, các đơn vị và nhà nghiên cứu độc lập đã tham gia phân tích, tái tạo lại lỗi để xác nhận nguyên nhân:

1. Galaxy Research & Chainalysis: Là những đơn vị phân tích on-chain đầu tiên theo dõi và đưa ra con số thống kê thiệt hại chi tiết (từ đợt rút đầu tiên 594 BTC cho đến khi vượt mốc 1.367 BTC).
2. Nhóm nghiên cứu tại Block & các Bitcoin Core Contributors: Đã kiểm tra trực tiếp mã nguồn trên thiết bị phần cứng thực tế để chứng minh lỗi Fallback PRNG (Yasmarang) đúng là nguyên nhân khiến entropy sụt giảm nghiêm trọng xuống mức 40-bit.
3. Ledger Donjon & Charles Guillemet (CTO của Ledger): Đã xuất bản bài phân tích so sánh lỗi Coldcard với các sự cố vỡ độ ngẫu nhiên tương tự trong lịch sử (như lỗi Trust Wallet 2023 hay Libbitcoin 2023).

Nguyên nhân gốc rễ của vấn đề

Nguyên nhân của vấn đề đã được Coinkite đưa ra vào ngày 30/07/2026 trong bài viết “Technical Deep Dive into the Entropy Issue“. Đây là một lỗ hổng RNG (random number generator) khá nghiêm trọng trong firmware Coldcard.

Vấn đề bắt đầu từ năm 2021, khi Coldcard chuyển các phép toán elliptic-curve sang dùng thư viện libsecp256k1 của Bitcoin Core, điều này đòi hỏi phải thêm thư viện libNgU, một thư viện MicroPython nhúng cung cấp các hàm 
libsecp256k1 và các hàm cơ bản khác của Bitcoin. Việc lựa chọn thuật toán mã hóa là đúng đắn, nhưng việc tích hợp thì không.

Lỗi này xảy ra do một lệnh tiền xử lý dùng sai kiểu kiểm tra: Lập trình viên đã sử dụng #ifndef để kiểm tra xem MICROPY_HW_ENABLE_RNG có được định nghĩa hay không, thay vì kiểm tra giá trị của nó có khác 0 hay không — trong khi Coinkite định nghĩa macro này bằng 0, nên lệnh #error không chặn được quá trình build. Chi tiết xem random.c:22-31

Vì MICROPY_HW_ENABLE_RNG = 0 vẫn được tính là đã định nghĩa, trình biên dịch đã không báo lỗi và đã âm thầm chọn hàm PRNG phần mềm dự phòng (Fallback Software PRNG) của MicroPython thay vì kết nối với hàm TRNG phần cứng. Xem code: micropython/ports/stm32/rng.c

Trong tệp rng.c lại kiểm tra giá trị của MICROPY_HW_ENABLE_RNG, vì nó bằng 0 nên không sử dụng hàm TRNG của phần cứng mà lại gọi hàm RNG mặc định của MicroPython (Chính là hàm pyb_rng_yasmarang()).

Chốt lại là lỗi do Dev của Coldcard:

• Lỗi thứ nhất: Đúng ra phải thiết lập MICROPY_HW_ENABLE_RNG=1 thì lại thiết lập MICROPY_HW_ENABLE_RNG=0
• Lỗi thứ hai: Nhẽ ra khi thiết lập MICROPY_HW_ENABLE_RNG=0 thì phải báo lỗi khi build, nhưng lại không báo lỗi do dòng code:
  ifndef MICROPY_HW_ENABLE_RNG

Do sai sót như vậy nên Dev thì nghĩ là hệ thống sử dụng hàm TRNG của phần cứng, nhưng thực ra không phải mà thực chất hàm pyb_rng_yasmarang() được sử dụng:

// For MCUs that don't have an RNG we still need to provide a rng_get() function,
// eg for lwIP and random.seed().  A pseudo-RNG is not really ideal but we go with
// it for now, seeding with numbers which will be somewhat different each time.  We
// don't want to use random's pRNG because then the user won't see a reproducible
// random stream.

// Yasmarang random number generator by Ilya Levin
// http://www.literatecode.com/yasmarang
static uint32_t pyb_rng_yasmarang(void) {
    static bool seeded = false;
    static uint32_t pad = 0, n = 0, d = 0;
    static uint8_t dat = 0;

    if (!seeded) {
        seeded = true;
        rtc_init_finalise();
        pad = *(uint32_t *)MP_HAL_UNIQUE_ID_ADDRESS ^ SysTick->VAL;
        n = RTC->TR;
        d = RTC->SSR;
    }

    pad += dat + d * n;
    pad = (pad << 3) + (pad >> 29);
    n = pad | 2;
    d ^= (pad << 31) + (pad >> 1);
    dat ^= (char)pad ^ (d >> 8) ^ 1;

    return pad ^ (d << 5) ^ (pad >> 18) ^ (dat << 1);
}

Hàm này sử dụng 4 giá trị sau để tạo số ngẫu nhiên seed:

• MP_HAL_UNIQUE_ID_ADDRESS: Đọc từ chip unique ID (VD: STM32 96-bit UID) — đây là giá trị cố định, không đổi giữa các lần chạy, thậm chí có thể đọc được nếu kẻ tấn công có quyền truy cập vật lý hoặc biết model chip. Không phải nguồn ngẫu nhiên, chỉ là hằng số theo từng thiết bị.
• SysTick->VAL: Bộ đếm timer hệ thống — giá trị phụ thuộc thời điểm chính xác trong quá trình boot khi hàm này được gọi lần đầu. Đây là biến số duy nhất có chút bất định, nhưng không gian giá trị bị giới hạn bởi tốc độ clock và thời gian boot cố định (thường vài chục ms, timer chạy ở MHz)
  → Không gian tìm kiếm thực tế của riêng biến này chỉ còn vài chục nghìn tới vài triệu giá trị khả dĩ, không phải 2^32.
• RTC->TR và RTC->SSR: Thời gian thực (giờ:phút:giây + sub-second) — Nếu kẻ tấn công biết khoảng thời gian gần đúng thiết bị được khởi tạo (VD: thời điểm mua, thời điểm setup ví — thường có thể suy ra từ metadata, log, hoặc social engineering), không gian giá trị của 2 biến này co lại rất mạnh.

Chính vì vậy mà giá trị ngẫu nhiên seed này không đạt tới 128 bit ngẫu nhiên mà thực tế chỉ tầm 40 bit ngẫu nhiên.

Tại sao Coldcard có public mã nguồn, nhưng lại không ai phát hiện cho đến khi nó xảy ra

Thực tế là ColdCard có public mã nguồn Firmware dưới dạng “Source-Available” (Mã nguồn có thể xem được), nhưng tại sao lỗ hổng “Tạo seed với độ ngẫu nhiên thấp” lại không bị phát hiện suốt nhiều năm.

Một phần câu trả lời là mã nguồn mở không có nghĩa là sẽ luôn có người kiểm tra kỹ. Bất kỳ ai cũng có thể xem mã nguồn, nhưng điều đó không có nghĩa là họ thực sự làm vậy. Phần lớn các lập trình viên chỉ tập trung vào thêm tính năng mới, sửa các lỗi dễ nhận thấy và xem xét những phần mã mà họ quan tâm. Rất ít người thực hiện các cuộc kiểm toán chuyên sâu về mật mã học, đặc biệt là quá trình tạo entropy hay seed.

Thực tế nhiều vấn đề bảo mật trước đây cũng vậy, mặc dù đã qua những đơn vị kiểm toán uy tín nhưng vẫn không phát hiện ra. Chỉ đến khi vấn đề xảy ra, nhiều chuyên gia cùng tập trung vào các dòng code liên quan tới vấn đề thì họ mới phát hiện ra.

Điều khiến cộng đồng chú ý hơn là nhiều người đã đào lại một bài đăng của ColdCard từ năm 2021, trong đó viết:
“Retirement attack” là khi nhà phát triển cố tình cài một lỗi vào quá trình tạo entropy để sau này có thể khôi phục và đánh cắp ví của người dùng.” Điều trớ trêu là bài đăng này lại mô tả gần như chính xác loại lỗ hổng sau đó xuất hiện trong firmware của ColdCard.
Tuy nhiên, bài đăng cũ này không phải là bằng chứng cho thấy lỗ hổng được cài vào một cách cố ý. Nó chỉ giải thích một khái niệm tấn công đã được biết đến trong lĩnh vực bảo mật.

Các dòng thiết bị bị ảnh hưởng

Với các dòng thiết bị khác nhau thì mức độ ảnh hưởng khác nhau do hàm pyb_rng_yasmarang() có thay đổi chút so với code trên.

• Dòng Coldcard Mk2 & Mk3: Dòng này bị ảnh hưởng ở mức độ cực kỳ nghiêm trọng
  • Entropy thực tế: Chỉ còn khoảng ~40 bits (so với chuẩn 128-bit).
  • Lý do: Không gian tìm kiếm 2^40 chỉ tương đương với khoảng vài nghìn tỷ trường hợp — con số mà các hệ thống máy tính/GPU hiện đại có thể thực hiện tấn công vét cạn toàn bộ trong thời gian ngắn.
• Dòng Coldcard Mk4, Mk5 & Q: Các dòng này chịu ảnh hưởng ở mức độ rủi ro Cao/Trung bình.
  • Entropy thực tế: Đạt khoảng ~72 bits.
  • Lý do: Khi phát triển Mk4/Mk5/Q, Coinkite đã thiết kế cơ chế bảo vệ “Back-up cho Back-up”: Trộn thêm giá trị TRNG từ 2 chip Secure Element (SE1 và SE2) vào trạng thái của PRNG.
  • Mặc dù 72-bit tốt hơn rất nhiều so với 40-bit, nó vẫn không đạt tiêu chuẩn an toàn 128-bit của mật mã học. Đối với các hacker chuyên nghiệp có nguồn lực lớn, 2^72 vẫn là một không gian có thể dò quét thành công.

Các trường hợp đặc biệt không bị ảnh hưởng

Theo phân tích của Coinkite, ví của bạn AN TOÀN ngay cả khi được tạo trên firmware bị lỗi nếu thuộc một trong hai trường hợp sau:

1. Có gieo xúc xắc (Dice Rolls >= 50 lần):
   • Nếu người dùng gieo xúc xắc thủ công từ 50 đến 98 lần khi tạo ví, lượng Entropy độc lập này đóng góp thêm ít nhất 128 bits. Nếu gieo >= 99 lần, nó đóng góp trọn vẹn 256 bits.
   • Thuật toán băm SHA-256 sẽ trộn dữ liệu xúc xắc này với Entropy máy. Do dữ liệu xúc xắc hoàn toàn ngẫu nhiên và bí mật, nó đã khắc phục hoàn toàn lỗi PRNG.
2. Sử dụng Passphrase (Từ thứ 25) mạnh:
   • Passphrase hoạt động như một lớp mã hóa bổ sung ngoài Seed Phrase. Kẻ tấn công cho dù tìm ra được Seed Phrase 24 từ nhờ Brute-force vẫn phải giải mã tiếp Passphrase. Nếu Passphrase đủ dài và phức tạp, tài sản vẫn an toàn.

Giải pháp khắc phục kỹ thuật từ Coinkite

• Bản vá Hotfix: Coinkite đã phát hành firmware mới (Mk2/Mk3: v4.2.0, Mk4/Mk5: v5.6.0, Q: v1.5.0Q). Trong bản vá, họ loại bỏ triệt để đối tượng Fallback RNG của MicroPython và ép buộc quá trình biên dịch phải xác minh chính xác hàm rng_get() phần cứng.
• Chỉ dẫn di chuyển (Migration): Việc cập nhật Firmware KHÔNG THỂ sửa lại các Seed đã bị lỗi. Người dùng bắt buộc phải:
  1. Update Firmware lên phiên bản mới nhất.
  2. Tạo một Seed Phrase MỚI BẢN CHẤT trên thiết bị đã update.
  3. Chuyển toàn bộ tiền từ ví cũ sang ví mới.

Vụ việc xảy ra từ 2026-07-31, đến ngày 2026-08-04 vẫn còn nhiều ví tiếp tục bị tấn công, Coldcard đã khẩn cấp kêu gọi người dùng chuyển Bitcoin sang địa chỉ ví mới sau khi một lỗ hổng bảo mật đang bị khai thác.

Ảnh hưởng thực tế tới người dùng

Tình hình của ví lạnh ColdCard hiện khá nghiêm trọng. Tính đến 2026-08-04, ước tính đã có khoảng 2055+ BTC (khoảng 130 triệu USD) bị đánh cắp và chưa có dấu hiệu dừng lại.

Vụ việc không đơn giản chỉ là vụ tấn công đơn thuần, vấn đề lớn nhất là nó đánh vào niềm tin của những người từng rất tin tưởng vào Bitcoin. Đã có rất nhiều câu chuyện về những người để toàn bộ tiền mua nhà, tiền hưu trí trong ColdCard rồi bị đánh cắp. Điều khiến vụ việc trở nên nặng nề hơn là những người này không làm gì sai cả, họ làm đúng theo tất cả những gì các Bitcoin Maxi (Người theo chủ nghĩa tối đa hóa Bitcoin).

Điển hình nhất là câu chuyện của một người tên là Jonathan Goodman, sống ở Canada, là một trong những nạn nhân trong 1 vụ tấn công tới ví lạnh Coldcard. Và anh này bị đánh cắp 18.25 Bitcoin, khoảng ~$1.16M (30 tỷ VNĐ) vào ngày 30/7. Điều đáng nói là số Bitcoin này được lưu trữ đúng theo cách mà cộng đồng vẫn luôn khuyến nghị.
Vấn đề làm cho vụ hack này trở nên tồi tệ hơn bao giờ hết, đó chính là những người bị ảnh hưởng là những người mà họ làm theo cái mà mọi người khuyến nghị, như anh chảng người Canada này:

• Anh ta chỉ mua Bitcoin mà thôi
• Anh ta cất trong ví lạnh, đó là ví Coldcard. Đây là loại ví mà những người tin tưởng tuyệt đối vào Bitcoin khuyến nghị.
• Anh ta lưu trữ khóa cá nhân cẩn thận trên giấy và anh ta không có lưu trữ cái gì trên mạng hết
• Thiết bị ColdCard của anh ta được để trong két an toàn tại một ngân hàng ở Canada mà chưa từng kết nối với Internet lần nào hết

Nhưng anh ta vẫn bị tấn công. Ban đầu khi nghe tin Coldcard có lỗ hổng thì người này nghĩ là không đời nào mình bị ảnh hưởng hết, anh ta nghĩ cách mình làm là an toàn nhất rồi. Sau đó anh này vào phần mềm ví Wasabi để kiểm tra ví Bitcoin của mình, anh nhìn thấy hàng loạt các giao dịch rút tiền màu đỏ. Điều làm người này đau lòng nhất là anh ta đã làm mọi thứ đúng cách, y như những gì mà những chuyên gia nói.

Coldcard là loại ví chỉ hỗ trợ duy nhất 1 loại tài sản, đó là Bitcoin. Vì thế trong mắt những Bitcoin Maxi, đây là loại ví lạnh được tin tưởng sử dụng. Bởi trong mắt Bitcoin Maxi, đối với họ chỉ có duy nhất Bitcoin, tất cả các đồng khác ngoài Bitcoin đều là rác. Ví lạnh Trezor hay Ledger đều hỗ trợ nhiều đồng coin khác nhau, nên trong mắt của các Bitcoin Maxi thì hai ví này không an toàn. Có thời kỳ, rất nhiều KOL nổi tiếng đều khuyến khích mọi người lưu trữ Bitcoin vào trong ví lạnh Coldcard. Vì thế số người sử dụng Coldcard không phải là nhỏ và thường lưu số lượng tương đối Bitcoin.

Bạn lướt trên diễn đàn Reddit sẽ còn thấy nhiều câu chuyện đau lòng liên quan tới Coldcard. Như một người mất toàn bộ số Bitcoin tích lũy sau nhiều năm:

Hay một người khác mất toàn bộ số Bitcoin tích lũy sau 8 năm:

Có người đã lập bản đồ cuộc tấn công Coldcard đang diễn ra với một bảng điều khiển trực tiếp: https://cktripwire.com

Tình hình các đồng Bitcoin bị đánh cắp cho đến thời điểm hiện tại

Theo thông tin từ BitcoinNews tính đến 2026-08-04 thì 90% lượng Bitcoin vẫn ở trong ví của hacker, còn 10% thì đã di chuyển 1 bước sang ví mới, nhưng chưa có Bitcoin nào được gửi tới bộ trộn tiền (Mixers, CoinJoin), và cũng chưa có bitcoin nào được chuyển tới một sàn giao dịch nào đó.

Nhiều người nghĩ đây không phải là hacker chuyên nghiệp, mà chỉ là người giỏi về máy tính hoặc đã dùng AI để tìm lỗ hổng, sau đó thực hiện tấn công mà không có bất kỳ kế hoạch rửa tiền nào. Với những vụ trước đây, khi sự việc bị phát hiện thì hacker gần như đã hoàn thành xong việc rửa tiền rồi.

Số Bitcoin càng để lâu thì càng bất lợi cho việc rửa tiền. Chính vì vậy mà cộng đồng mạng đang có một hy vọng nho nhỏ, đó là hacker sau khi không rửa được sẽ giữ lại một phần và trả lại lượng Bitcoin còn lại và không bị truy tố nữa.

Sự cố của SecondFi làm rung lắc hệ sinh thái Cardano

Bây giờ, chúng ta quay về sự cố liên quan đến ví SecondFi (tên gọi cũ vô cùng quen thuộc là Yoroi Wallet) diễn ra vào tháng 6/2026 là một trong những cuộc tấn công ứng dụng ví nghiêm trọng nhất lịch sử hệ sinh thái Cardano (ADA). Tương tự như vụ Coldcard, sự cố của SecondFi không bắt nguồn từ việc mạng lưới blockchain Cardano bị tấn công, mà xuất phát từ lỗi phần mềm ở khâu tạo chìa khóa (Key Generation) của ứng dụng ví.

Yoroi Wallet (ứng dụng chủ lực ra mắt từ năm 2018) được phát triển bởi EMURGO – một trong ba tổ chức sáng lập nên hệ sinh thái Cardano. Yoroi luôn được coi là ví “chuẩn chỉnh” và an toàn nhất cho người dùng ADA. Đến tháng 4/2026, EMURGO tiến hành đổi tên Yoroi thành SecondFi và chuyển hướng phát triển từ một ví nhẹ (Light Wallet) thành một ứng dụng tài chính “Neo-finance” đa chức năng. Trong đợt tái cấu trúc này, ứng dụng đã có những thay đổi lớn trong mã nguồn ứng dụng web và di động.

Thời điểm vấn đề được phát hiện và sự xuất hiện của hacker mũ trắng

Vào khoảng ngày 23 tháng 6 năm 2026, cộng đồng Cardano bàng hoàng khi phát hiện hàng loạt địa chỉ ví tạo trên SecondFi bị rút sạch ADA mà người dùng không hề bấm vào link scam hay ký bất kỳ giao dịch lạ nào. Sự việc nghiêm trọng đến mức mà SecondFi phải tạm dừng toàn bộ dịch vụ.

Thực tế thì các đợt rút tiền trái phép diễn ra chủ yếu từ tối ngày 21/6 đến ngày 22/6/2026 — tức là cuộc tấn công đã xảy ra trước khi được phát hiện khoảng 1-2 ngày. SecondFi xác nhận 3 đợt tấn công riêng biệt từ bên ngoài đã rút khoảng 16 triệu ADA (~2,4 triệu USD) từ 374 ví, thông qua lỗ hổng trong phần mềm sinh ví của họ. Snapshot số dư cuối cùng được chốt vào thứ Sáu, ngày 26/6/2026, phục vụ cho việc ghi nhận thiệt hại và làm cơ sở khôi phục sau này.

Sau khi vấn đề được phát hiện vào ngày 2026-06-23, SecondFi đã thừa nhận sự cố và tạm dừng toàn bộ dịch vụ. Công ty cũng đã thực hiện sao lưu nhanh số dư tài khoản của người dùng, về cơ bản là ghi lại số tiền mà mọi người nắm giữ tại thời điểm phát hiện vi phạm. SecondFi cho biết họ đã thuê một công ty bảo mật blockchain hàng đầu để thực hiện đánh giá độc lập về lỗ hổng này. Công ty cũng đang phối hợp với một số đối tác lớn trong hệ sinh thái Cardano, bao gồm Input Output Global (IOG), Cardano Foundation, IntersectMBO và SundaeSwap, để xử lý hậu quả và hỗ trợ người dùng bị ảnh hưởng.

Có điều thú vị trong sự kiện này là có 2 dòng tiền chính:

• Dòng tiền bị Hacker đánh cắp:
  • Số lượng thiệt hại: Khoảng 16M ADA trên 374 địa chỉ (SecondFi xác nhận) hoặc ~12.1M ADA trên 178 ví (theo dữ liệu theo dõi độc lập của Fetch). Ví bị thiệt hại nặng nhất mất 3.30M ADA.
  • Phương thức tấn công (Method): Kẻ tấn công dùng cơ chế fee-sponsored drainer (rút tiền tài trợ phí) bằng cách nhận vốn từ cầu nối NEAR → Nạp phí giao dịch → Rút sạch tiền về các địa chỉ gom (Collectors A/B/C).
  • Rửa tiền: Tiền trộm được xả trực tiếp qua các bể thanh khoản DEX trên Cardano (đặc biệt là cặp ADA → USDCx, gây ra cú sụp giá/nhảy giá mạnh trên cặp giao dịch này) rồi phân tán đi nhiều nơi.
• Dòng tiền “Giải cứu”:
  • Số lượng bảo vệ: ~129.43M ADA (thuộc sở hữu của khoảng 2.850 ví, trong đó có 27 ví cá voi giữ trên 1M ADA, ví lớn nhất giữ 5.41M ADA).
  • Bản chất hành động:
    • Đây không phải là trộm cắp, mà là hành động mũ trắng (white-hat rescue) thực hiện thao tác tương tự như hacker để chủ động rút khẩn cấp số tiền nằm ở các ví có nguy cơ rò rỉ private key để gom vào 1 ví duy nhất.
    • Đại diện của EMURGO thừa nhận trong cuộc họp với Intersect rằng họ không hề biết danh tính của Hacker Mũ Trắng này là ai và người này không thuộc nhân sự của EMURGO.
  • Trạng thái hiện tại: Tiền đang ở trạng thái PARKED (nằm yên tại một ví duy nhất từ ngày 23/06 lúc 12:20 UTC) và chưa hề dịch chuyển hay thực hiện hành vi rửa tiền nào. Hacker Mũ Trắng mới chủ động liên hệ với SecondFi/EMURGO để thỏa thuận chuyển giao số tiền này cho một đơn vị lưu ký độc lập (Third-party Custodian) kiểm toán và trả lại cho người dùng.

Lùm xùm tranh chấp pháp lý liên quan tới EMURGO

Khoản tiền 129.43 triệu ADA (được Hacker Mũ Trắng gom lại) ban đầu dự định sẽ được chuyển trực tiếp vào một hợp đồng thông minh (Smart Contract) hoặc qua bên lưu ký thứ ba để phân phối lại cho các nạn nhân bị lộ Private Key. Tuy nhiên, quá trình này bị đóng băng và trì hoãn kéo dài do xuất hiện tranh chấp pháp lý đằng sau hậu trường giữa EMURGO (công ty mẹ của SecondFi) và các bên liên quan.

• Vấn đề của Emurgo:
  • EMURGO với tư cách là một doanh nghiệp thương mại hoạt động trong thời gian dài đã có những tranh chấp hợp đồng, khoản nợ và cam kết đầu tư với các quỹ/đối tác bên ngoài (liên quan đến các dự án mở rộng trước đây của hệ sinh thái).
  • Khi vụ hack SecondFi xảy ra, phía EMURGO chịu áp lực bồi thường tài chính cực kỳ lớn. Do SecondFi là sản phẩm trực thuộc EMURGO, các nguyên đơn trong các vụ kiện/tranh chấp hợp đồng độc lập khác đã cố gắng xem khoản 129.43M ADA này là tài sản do EMURGO kiểm soát để yêu cầu tòa án/bên trọng tài phong tỏa hoặc dùng làm tài sản đảm bảo cho các nghĩa vụ tài chính khác của EMURGO.
• Phản ứng dữ dội tự cộng đồng:
  • Sự phẫn nộ trong cộng đồng Cardano bùng nổ khi các tin nhắn leak và biên bản làm việc cho thấy: Phía EMURGO từng đề xuất một phương án xử lý tái cấu trúc, trong đó khoản ADA được giải cứu này sẽ được đưa vào một quỹ chung. Mục tiêu của Quỹ này là vừa dùng để đền bù theo tỷ lệ cho nạn nhân vụ SecondFi, vừa dùng để trang trải/dàn xếp các khoản nợ và nghĩa vụ pháp lý phát sinh từ các thương vụ thất bại khác của EMURGO.
  • Charles Hoskinson công khai tuyên bố rằng khoản 129.43 triệu ADA đó chưa bao giờ thuộc sở hữu của EMURGO hay SecondFi. Đó là tài sản bị rút khỏi ví của người dùng và do Mũ Trắng giữ hộ. Việc lấy tiền của người dùng vụ này đi đền bù hoặc xử lý nghĩa vụ cho vụ khác/thương vụ khác là hành vi vi phạm nghĩa vụ ủy thác và có dấu hiệu gian lận.
  • Hacker Mũ Trắng từ chối chuyển tiền cho EMURGO: Chính vì các tranh chấp pháp lý và nguy cơ số tiền bị các bên thứ ba (như tòa án hoặc nguyên đơn kiện EMURGO) phong tỏa, Hacker Mũ Trắng đã từ chối chuyển trực tiếp số ADA này cho EMURGO. Mũ Trắng yêu cầu một cơ chế On-chain công khai hoặc một bên lưu ký độc lập được cộng đồng phê duyệt trước khi bàn giao.
  • Sự can thiệp của Tổ chức Intersect: Tổ chức quản trị dựa trên cộng đồng của Cardano (Intersect) đã phải nhảy vào đóng vai trò trung gian, lập ra một hội đồng độc lập để tách biệt hoàn toàn khoản 129.43M ADA ra khỏi mọi khoản nợ, vụ kiện hay nghĩa vụ pháp lý riêng của EMURGO.

Nguyên nhân chi tiết lỗ hổng

Vấn đề phát hiện từ 2026-06-23 nhưng báo cáo phân tích kỹ thuật đầy đủ chỉ được công bố sau đó gần một tháng — vào ngày 22/7/2026, SecondFi mới công bố chi tiết rằng đây là lỗ hổng cryptographic trong quá trình sinh chữ ký giao dịch. Chi tiết xem bài: An update regarding the recent security incident involving SecondFi, không chi tiết trong 1 bài mà phải xem trong nhiều bài trước đó. Tóm lại, lỗ hổng bảo mật xảy ra tại khâu “Tạo chữ ký” (Per-Transaction Signatures Flaw).

Để hiểu được vấn đề, đầu tiên chúng ta cần phải hiểu cơ chế ký của thuật toán ECDSA/EdDSA, chi tiết xem bài viết: Tìm hiểu nền tảng kỹ thuật cơ bản sử dụng trong blockchain Bitcoin và một số nền tảng blockchain khác. Quy trình tạo chữ ký như sau:

Quan trọng nhất, trong công thức trên chính lá số ngẫu nhiên nonce k, đây là mấu chốt của vấn đề bảo mật. Trong phương trình trên có hai ẩn số là k và d, đây là một phương trình hai ẩn số nên không thể giải điều, chính điều này tạo nên tính bảo mật cho hệ thống.

Trong trình cập nhật web/app mới của SecondFi, đội ngũ phát triển đã đưa vào một thuật toán tạo chữ ký bị lỗi. Lỗi ở chỗ, họ thay vì chọn k ngẫu nhiên hoàn toàn độc lập cho mỗi giao dịch, đoạn mã bị lỗi của SecondFi đã tính k theo một công thức đại loại như sau:

Trong đó, Public Transaction Data là các dữ liệu công khai trên Cardano Blockchain của chính giao dịch đó (ví dụ: Hash của giao dịch, UTXO Input, Dấu thời gian, hoặc Địa chỉ người nhận…).

Chính điều này đã tạo ra nguy cơ chết người, chỉ cần người dùng thực hiện 1 giao dịch bất kỳ, thì họ sẽ bị lộ Private Key. Khi người dùng thực hiện 1 giao dịch, trong giao dịch đó:

• Có giao dịch nên hacker sẽ có thông tin chữ ký s.
• Từ thông tin giao dịch, hacker sẽ có được Public Transaction Data, hacker cho qua cùng một hàm băm mà SecondFi sử dụng trong code (vốn bị leak trên GitHub) để tính ra chính xác giá trị k mà ví SecondFi đã dùng cho giao dịch đó.
• Hacker tính r = kP
• Hacker thực hiện tính ngược ra Private Key d theo công thức dưới.

Trong lịch sử Crypto thì cũng đã xảy ra 3 kịch bản lỗi liên quan tới k:

• k cố định:
  • Đặc điểm: r không bao giờ thay đổi giữa các giao dịch. Cực kỳ dễ bị phát hiện và khai thác.
  • Ví dụ thực tế: Sự cố trên một số thư viện Bitcoin sơ khai những năm 2011–2012.
• k sử dụng lại:
  • Đặc điểm: Chọn k ngẫu nhiên nhưng do lỗi entropy nên 2 giao dịch khác nhau lại vô tình dùng chung một k (r1 = r2).
  • Ví dụ thực tế: Vụ hack PlayStation 3 (2010) và vụ Android Bitcoin Wallet (2013).
• k tính từ dữ liệu công khai:
  • Đặc điểm: k luôn thay đổi ở mỗi giao dịch (nên r khác nhau, nhìn qua tưởng ngẫu nhiên), nhưng k lại tính toán được từ dữ liệu public.
  • Ví dụ thực tế: Vụ SecondFi / Yoroi (2026).

Ảnh hướng tới cộng động Cardano

Vào ngày 2025-11-21, cộng đồng Cardano đã gặp một phen hú vía trong một sự cố hy hữu “Fork ngoài ý muốn” của mạng lưới blockchain, khi có một người đàn ông vì tò mò đã thử nghiệm một giao dịch “độc”, khiến hệ thống kích hoạt một lỗi tiềm ẩn tồn tại từ năm 2022. Hậu quả là mạng lưới bị tách thành 2 nhánh, blockchain cũng bị gián đoạn 1h đến 2h, block tạo ra chậm hơn, các SPO bị ảnh hưởng phần thưởng, giá ADA giảm 16%, nhưng may mắn là không ai bị mất tài sản.

Nhưng sự cố Yoroi / SecondFi lần này được đánh giá còn nghiêm trọng hơn nhiều so với sự cố ở trên,. Sự cố đã giáng một đòn nặng nề vào niềm tin và uy tín thương hiệu của toàn bộ hệ sinh thái Cardano. Nó đánh thẳng vào túi tiền của người dùng cuối, những người đã tin tưởng vào hệ sinh thái suốt bao năm qua. Sự cố cũng đã làm giá đồng tiền ADA đã giảm xuống mức thấp nhất kể từ năm 2022, về mức giá 0.14$.

Một số sự cố khác trước đây liên quan tới vấn đề lưu trữ tài sản Crypto

Ledger Recover – Khủng hoảng triết lý bảo mật

Vào tháng 05/2023, Ledger ra mắt dịch vụ Ledger Recover, một tính năng trả phí $9.99/tháng. Dịch vụ này đã đụng chạm trực tiếp vào “lời hứa cốt lõi” mà Ledger cũng như ngành ví lạnh (Hardware Wallet) luôn quảng cáo với người dùng từ trước đến nay. Điều này đã gây ra sự cố khủng hoảng truyền thông và niềm tin lớn nhất trong lịch sử của Ledger.

Bình thường, khi tạo ví lạnh Ledger, bạn nhận được một cụm từ khôi phục (Seed Phrase / Recovery Phrase) gồm 24 từ. Nguyên tắc bất di bất dịch của ví lạnh là: “Khóa bí mật (Private Key) được khởi tạo và lưu vĩnh viễn bên trong chip bảo mật (Secure Element) của thiết bị, KHÔNG BAO GIỜ rời khỏi thiết bị dưới bất kỳ hình thức nào.“. Tuy nhiên, với dịch vụ Ledger Recover, Ledger giới thiệu cơ chế khôi phục Seed Phrase dành cho những ai sợ quên 24 từ:

1. Chia nhỏ Private Key (Sharding): Thiết bị Ledger sẽ mã hóa 24 từ khôi phục của bạn và chia nó thành 3 mảnh băm (shards) bằng thuật toán Shamir’s Secret Sharing.
2. Gửi ra bên ngoài: 3 mảnh mã hóa này được gửi ra khỏi thiết bị Ledger qua internet.
3. Lưu trữ ở 3 công ty độc lập:
   • 1 mảnh do Ledger giữ.
   • 1 mảnh do Coincover (công ty bảo hiểm/bảo mật crypto) giữ.
   • 1 mảnh do EscrowTech (công ty lưu ký code/dữ liệu) giữ.
4. Khôi phục bằng KYC: Khi người dùng làm mất thiết bị hoặc 24 từ, họ chỉ cần làm thủ tục xác minh danh tính (KYC – chụp Căn cước/Hộ chiếu, quét khuôn mặt) với bên thứ ba. Sau khi KYC thành công, 2 trong số 3 mảnh sẽ được gửi lại để khôi phục ví.

Trước đây, Ledger luôn truyền thông rằng:
“Về mặt phần cứng, không có bất kỳ firmware nào có thể trích xuất Private Key ra khỏi chip Secure Element.”
Khi Ledger Recover ra mắt, cộng đồng ngộ ra một sự thật phũ phàng: Firmware hoàn toàn có khả năng trích xuất và gửi Private Key ra bên ngoài, miễn là Ledger viết một bản cập nhật phần mềm (Firmware Update) để kích hoạt tính năng đó:
“Nếu Ledger có thể cập nhật firmware để gửi mã hóa Private Key cho 3 công ty lưu trữ, thì họ (hoặc cơ quan chính phủ ép họ) cũng có thể cập nhật firmware để gửi Private Key đó cho bất kỳ ai.”

Và chính tính năng này tạo thêm một nguy cơ Pháp lý cực kỳ lớn. Do người dùng đã KYC, nên nếu tòa án hoặc chính quyền (ví dụ: Mỹ, Pháp) ban hành trát yêu cầu cung cấp dữ liệu, Ledger và các đối tác lưu ký sẽ bắt buộc phải giao 2/3 mảnh băm để chính quyền khôi phục ví và phong tỏa tài sản của người dùng mà không cần sự đồng ý của họ. Điều này đi ngược lại hoàn toàn với tinh thần Phân quyền (Decentralization) và Tự chủ tài sản (Self-custody) của Crypto.

Trong làn sóng chỉ trích, tài khoản Twitter hỗ trợ khách hàng của Ledger (@Ledger_Support) đã có một câu trả lời gây sốc làm ngọn lửa bùng cháy dữ dội hơn:
“Về mặt kỹ thuật, chúng tôi luôn có thể viết một bản firmware cho phép trích xuất khóa bí mật. Bạn luôn phải tin tưởng rằng Ledger không làm điều đó.”
Câu nói này như một “gáo nước lạnh” dập tắt niềm tin của những người dùng chọn ví lạnh với tư tưởng:
“Don’t trust, verify” (Không tin tưởng ai, hãy tự xác minh).

Rất nhiều người dùng lâu năm đã đập bỏ ví Ledger hoặc cất tủ để chuyển sang mua ví lạnh mã nguồn mở hoàn toàn (Open-source) như Trezor, BitBox02, Coldcard, Blockstream Jade… Trước sức ép khủng khiếp, CEO của Ledger (Pascal Gauthier) đã phải đăng thư xin lỗi, thừa nhận cách truyền thông vụng về và thông báo:

• Tạm hoãn triển khai dịch vụ Ledger Recover.
• Cam kết mở mã nguồn (Open-source) các đoạn code của ứng dụng Ledger và giao thức Ledger Recover để cộng đồng kiểm toán (Audit) độc lập trước khi chính thức phát hành.

Vụ việc năm 2022: Voyager, Celsius, FTX phá sản

Năm 2022 được ví như năm “Mùa đông Crypto” thảm khốc nhất lịch sử. Vòng xoáy sụp đổ dây chuyền này không bắt đầu từ FTX, mà được châm ngòi từ cú sập của hệ sinh thái Terra (LUNA/UST) vào tháng 5/2022, tạo nên hiệu ứng domino kéo theo sự sụp đổ của Voyager Digital, Celsius Network và cuối cùng là cú đòn chốt hạ FTX.

Voyager Digital: Bản hợp đồng cho vay mù quáng

Voyager là một công ty môi giới crypto tập trung niêm yết trên sàn chứng khoán Canada, thu hút người dùng bằng cách cung cấp dịch vụ giao dịch không tốn phí và trả lãi suất gửi crypto cao (lên đến 9-10%/năm). Để trả mức lãi suất cao đó, Voyager đã đem tiền gửi của khách hàng cho các quỹ đầu tư mạo hiểm vay.

Lỗi chết người của Voyager là quản trị rủi ro tập trung: Họ đã cho quỹ đầu tư Three Arrows Capital (3AC) vay hơn 650 triệu USD (gồm 15,250 BTC và 350 triệu USDC) mà không có tài sản thế chấp tương ứng. Khi mô hình LUNA/UST sụp đổ, 3AC bị vỡ nợ hoàn toàn và không thể trả nợ cho Voyager.

Voyager nộp đơn xin bảo hộ phá sản (Chapter 11) vào tháng 7/2022, đóng băng toàn bộ tài sản của hàng triệu người dùng.

Celsius Network: Cú sập của “Gã khổng lồ” Ngân hàng Crypto

Celsius tự quảng cáo là một “Ngân hàng Crypto an toàn hơn ngân hàng truyền thống” với khẩu hiệu “Unbank Yourself“ (Hãy tự giải thoát mình khỏi ngân hàng). Họ hứa hẹn trả lãi suất gửi tiền cực kỳ hấp dẫn từ 7% đến 18%/năm.

Celsius thực chất hoạt động như một quỹ đầu tư rủi ro đòn bẩy cao. Họ lấy tiền gửi của khách đem đi mang đi thế chấp, đi đào Bitcoin, và tham gia vào các chiến lược DeFi mạo hiểm (như Lido stETH). Khi thị trường lao dốc, các khoản đầu tư DeFi của Celsius bị kẹt thanh khoản. Đồng thời, họ cũng gánh khoản lỗ hàng trăm triệu USD do liên đới từ vụ sập 3AC và LUNA.

Khi tin đồn mất thanh khoản lan rộng, người dùng ồ ạt rút tiền. Celsius không có đủ tài sản khả dụng để trả. Celsius dừng toàn bộ tính năng rút tiền vào tháng 6/2022 và nộp đơn phá sản Chapter 11 vào tháng 7/2022. CEO Alex Mashinsky sau đó bị Bộ Tư pháp Mỹ (DOJ) bắt giữ và khởi tố vì tội lừa đảo tài chính.

FTX & Alameda Research: Cú chốt hạ hoàn thành “Dây chuyền sụp đổ”

Trong khi Voyager và Celsius phá sản, Sam Bankman-Fried (SBF) — CEO của sàn FTX — đóng vai “Kẻ cứu rỗi” khi tuyên bố bơm hàng trăm triệu USD để giải cứu/mua lại Voyager và BlockFi. Nhưng đây thực chất chỉ là màn kịch để che giấu một lỗ hổng tài chính khổng lồ bên trong FTX.

Nhưng sự thật là FTX không hề giải cứu ai bằng tiền thật. Họ lấy chính tiền gửi của khách hàng trên sàn FTX chuyển qua “cửa sau” cho quỹ Alameda Research để bù đắp các khoản lỗ giao dịch và đi mua lại các công ty phá sản.

Cú nổ xảy ra vào tháng 11/2022, Khi Changpeng Zhao (CZ – CEO Binance) tuyên bố sẽ bán sạch số token FTT mà Binance nắm giữ sau các báo cáo nghi vấn về bảng cân đối tài chính của Alameda, làn sóng rút tiền kỷ lục nổ ra trên FTX. FTX không thể đáp ứng 6 tỷ USD yêu cầu rút tiền trong 72 giờ vì tiền đã bị rút cạn từ trước. FTX phá sản vào ngày 11/11/2022, SBF bị bắt tại Bahamas và bị tuyên án 25 năm tù sau đó.

Lưu trữ Bitcoin và Crypto ở đâu mới thực sự an toàn

Quá nhiều sự kiện đã xảy ra và mỗi sự kiện là một bài học:

• FTX dạy chúng ta không nên để coin trên sàn tập trung
• Voyager, Celcius dạy chúng ta không nên tảng lending
• SecondFi (Yoroi) dạy chúng ta không nên để tiền trong ví nóng
• Coldcard dạy chúng ta không để tiền trong ví lạnh
• Ledger dạy chúng ta không được tin hoàn toàn vào 1 nhà sản xuất thiết bị phần cứng.

Vậy thì chúng ta phải lưu trữ Bitcoin và Crypto ở đâu mới thực sự an toàn. Thực ra không có nơi nào là an toàn tuyệt đối cả, mỗi nơi đều có ưu và nhược điểm riêng của nó. Có hai giải pháp tương đối an toàn cho đến thời điểm hiện tại mà cộng đồng mạng đang khuyên:

• Ví Đa chữ ký (Multi-Sig – ví dụ: Safe/Gnosis):
  • Muốn chuyển tiền, cần 2/3 hoặc 3/5 chữ ký từ các thiết bị/ví khác nhau.
  • Dù 1 ví nóng bị dính lỗi (như vụ SecondFi) hay 1 chiếc Ledger bị hỏng, kẻ tấn công vẫn không thể chuyển tiền đi vì thiếu các chữ ký còn lại.
• Công nghệ MPC (Multi-Party Computation) / Passkeys:
  • Khóa bí mật không bao giờ tồn tại trọn vẹn ở một nơi. Nó được chia nhỏ thành các mảnh toán học mã hóa lưu ở nhiều thiết bị độc lập.

Nhưng nếu ví được tạo từ thiết bị lỗi như ColdCard thì hai giải pháp trên cũng không thể giải quyết được. Cho dù cần 3 chữ ký mới chuyển tiền được, mới vụ ColdCard với không gian 2^40, thì hacker cũng chỉ mất thời gian gấp 3 lần so với 1 ví để tìm ra Private key của cả ba ví.

Nếu bạn là một nhà phát triển, thì bạn tự viết code để tạo và quản lý ví của mình cũng là một cách tương đối tốt. Nhưng hãy nhớ phải review code cẩn thận, có thể dùng AI chuyên dụng để review.

Đối với người dùng thông thường thì tôi nghĩ giải pháp tốt nhất là “Quản lý tài sản” theo mô hình “3 tầng lưu trữ” như sau:

• Tầng 1: Tầng Giao dịch (Trading Tier) – Tối đa 10-20% tài sản
  • Nơi lưu trữ: Các sàn CEX lớn, uy tín top đầu có cơ chế Proof of Reserves (PoR) rõ ràng và quỹ bảo hiểm người dùng (như SAFU của Binance).
  • Mục đích: Để giao dịch, chốt lời/lỗ, nạp rút tiền pháp định.
  • Quy tắc an toàn:
    • Bật 2FA bằng ứng dụng Authentication (Google Authenticator / YubiKey), tuyệt đối không dùng SMS 2FA.
    • Không để toàn bộ vốn tích lũy trên sàn. Khi có lợi nhuận, rút ngay về Tầng 2 hoặc Tầng 3.
• Tầng 2: Tầng Tương tác DApp / DeFi (Hot Wallet Tier) – Tối đa 10-20% tài sản
  • Nơi lưu trữ: Ví nóng mã nguồn mở độc lập (MetaMask, Rabby…).
  • Mục đích: Săn airdrop, mint NFT, tham gia staking, tương tác với các giao thức DeFi.
  • Quy tắc an toàn:
    • Tách biệt ví: Ví dùng săn Airdrop phải hoàn toàn độc lập với ví chứa tiền chính.
    • Thường xuyên hủy ủy quyền (Revoke approval) các smart contract không còn sử dụng.
    • Tuyệt đối không lưu Seed Phrase dưới dạng file ảnh, chụp màn hình hay lưu trên iCloud/Google Drive/Notion.
• Tầng 3: Tầng Kho báu dài hạn (Cold Storage Tier) – 60-80% tài sản
  • Nơi lưu trữ: Ví lạnh phần cứng (Hardware Wallet) hoặc Ví Đa chữ ký (Multi-Sig).
  • Mục đích: Cất giữ tài sản dài hạn, không đụng tới thường xuyên.
  • Quy tắc an toàn:
    • Ưu tiên các dòng ví Mã nguồn mở hoàn toàn cả phần cứng lẫn phần mềm (như Trezor, BitBox02, Blockstream Jade).
    • Chép Seed Phrase ra Kim loại (Steel/Titanium Plate): Chống cháy, chống nước, chống ăn mòn thay vì ghi ra giấy.
    • Tuyệt đối không bao giờ gõ 24 từ khôi phục lên bàn phím máy tính hay điện thoại dưới bất kỳ hình thức nào.