Tóm tắt nhanh
- mSeven xác nhận một bên không được phép đã lấy bản sao database mã hóa chứa dữ liệu người dùng hiện tại và cũ trên mSecure Cloud.
- Công ty nói chưa có bằng chứng dữ liệu bí mật trong database bị truy cập, nhưng vẫn khuyến nghị đổi mật khẩu quan trọng, thiết lập lại 2FA và thay passkey khi cần.
- Phạm vi được xác nhận là người dùng từng đồng bộ với mSecure Cloud; ứng dụng tự lưu cục bộ không nằm trong database đám mây bị lấy.
- Mã hóa AES-256 không xóa bỏ rủi ro nếu kẻ tấn công có bản sao để thử bẻ khóa ngoại tuyến, nhất là khi mật khẩu chủ yếu yếu.
mSeven Software, nhà phát triển mSecure, gửi email cảnh báo ngày 3/11/2026 sau khi phát hiện hoạt động đáng ngờ liên quan đến ứng dụng. Công ty sau đó xác nhận một bên không được phép đã lấy bản sao database mã hóa của mSecure Cloud. Hiện mSeven nói chưa có bằng chứng nội dung trong kho bị giải mã, nhưng khuyến nghị người dùng chủ động bảo vệ các thông tin đăng nhập quan trọng.
Bản sao mã hóa vẫn có thể bị thử bẻ khóa ngoại tuyến
mSecure quảng bá mã hóa AES-256 và kiến trúc zero-knowledge: theo mô tả của hãng, mật khẩu tài khoản và khóa tài khoản không được lưu trên máy chủ mSeven. Điều đó giới hạn khả năng nhà cung cấp đọc nội dung kho, nhưng không đồng nghĩa bản sao database bị lấy sẽ vô hại trong mọi tình huống.
Khi kẻ tấn công có một bản sao dữ liệu mã hóa, họ có thể thử nhiều mật khẩu chủ yếu ngoại tuyến mà không phải gửi từng lần đoán qua máy chủ. Mỗi lần đoán vẫn phải vượt qua cơ chế mã hóa và dẫn xuất khóa, nhưng mật khẩu chủ yếu ngắn, phổ biến hoặc từng bị dùng lại sẽ làm bài toán dễ hơn đáng kể. Vì vậy, AES-256 bảo vệ dữ liệu bằng thuật toán mạnh không thể thay thế một mật khẩu chủ yếu đủ khó đoán.
Đây cũng là lý do các cảnh báo bảo mật thường phân biệt “chưa có bằng chứng bị giải mã” với “không có rủi ro”. Bản sao có thể được giữ lại để thử tiếp trong tương lai, kiểu tấn công thường gọi là harvest now, decrypt later. Hiện không có dữ kiện cho thấy kẻ tấn công đã giải mã được kho mSecure; đây là rủi ro cần cân nhắc, không phải bằng chứng dữ liệu đã bị đọc.
Người đồng bộ với mSecure Cloud cần ưu tiên tài khoản quan trọng
Phạm vi ảnh hưởng được mSeven nêu là người dùng từng đồng bộ dữ liệu qua mSecure Cloud, bao gồm cả tài khoản hiện tại và tài khoản cũ. Nếu bạn chỉ lưu kho trên thiết bị hoặc dùng cách đồng bộ không đi qua mSecure Cloud, dữ liệu đó không nằm trong bản database đám mây được mô tả là đã bị lấy; tuy vậy, nên kiểm tra lại chính xác thiết lập đồng bộ trước khi kết luận tài khoản an toàn.
mSeven khuyến nghị đổi mật khẩu, thiết lập lại hoặc đăng ký lại phương thức xác thực hai yếu tố (2FA), và gỡ các passkey hiện có nếu phù hợp. Với kho có hàng trăm mục, thay đổi tất cả cùng lúc có thể mất nhiều thời gian. Nên bắt đầu từ email chính, tài khoản ngân hàng, mạng xã hội, tài khoản quản lý công việc và những dịch vụ có quyền khôi phục các tài khoản khác; đặt mật khẩu mới, duy nhất cho từng dịch vụ và bật 2FA lại sau khi cập nhật.
Xóa ứng dụng khỏi điện thoại không thu hồi được bản sao đã rời khỏi máy chủ. Thay vào đó, cần xử lý thông tin xác thực trên từng dịch vụ và theo dõi thông báo tiếp theo từ mSeven. Nếu mật khẩu chủ yếu mSecure đã được dùng lại ở nơi khác, hãy đổi cả những tài khoản đó.
Điều còn thiếu là phạm vi sự cố và cách xử lý cụ thể
Thông tin công khai hiện chưa giải thích cách bên tấn công tiếp cận database, thời điểm xảy ra, loại trường dữ liệu nằm trong bản sao, hay liệu có thông tin tài khoản ngoài nội dung kho bị ảnh hưởng hay không. Những chi tiết này quan trọng vì chúng giúp người dùng xác định mức độ khẩn cấp và biết có cần thực hiện thêm bước nào ngoài việc thay thông tin đăng nhập.
Việc chưa có bằng chứng giải mã là thông tin đáng ghi nhận, nhưng khách hàng vẫn phải tự quyết định nên đổi dữ liệu nào khi chưa rõ phạm vi. mSeven cho biết đã điều tra, giảm thiểu sự cố và thuê chuyên gia an ninh mạng bên ngoài hỗ trợ; người dùng nên theo dõi thông báo chính thức tiếp theo thay vì chỉ gỡ ứng dụng hoặc đổi riêng mật khẩu tài khoản mSecure.
Nguồn tham khảo: TechRadar, BleepingComputer, The Register, mSecure
