Ngày 13 tháng 9 năm 2026, một bản ghi Chess.com (2026) đã xuất hiện trên Have I Been Pwned: 7,3 triệu dòng, 4,6 triệu địa chỉ email duy nhất. Không có mật khẩu trong bản sao, không có hash, không có dữ liệu thanh toán. Và dường như cũng không có vụ hack: dữ liệu đã được thu thập trong chín ngày liên tiếp bằng các yêu cầu thông thường đến dịch vụ trực tiếp. Đây là trường hợp mà "rò rỉ" và "xâm nhập vào hệ thống" là hai điều khác nhau, và cần phải xem xét chính xác cơ chế.
Những gì đã bị công khai
Kho lưu trữ đã xuất hiện trên diễn đàn tội phạm mạng vào ngày 12 tháng 8 năm 2026 và đã được phát tán qua Telegram. Tệp đã giải nén có kích thước 15,5 GB (744 MB trong 7-Zip), bên trong có 7 337 395 bản ghi với 38 trường trong mỗi bản ghi.
- Địa chỉ email — khoảng 75% bản ghi (4,6 triệu duy nhất).
- Tên người dùng, tên thật, ID người dùng và UUID.
- Quốc gia, vị trí, ngôn ngữ giao diện.
- Xếp hạng, danh hiệu, cấp độ trò chơi, trạng thái đăng ký premium.
- Ngày đăng ký và lần đăng nhập cuối cùng — cho đến tháng 8 năm 2026.
- Các phân khúc quảng cáo của Google Ad Manager — các trường gam_audiences và audiences_member_of.
Điểm cuối cùng là điều bất ngờ nhất. Đây là các nhãn tiếp thị nội bộ như "phù hợp cho giai đoạn dùng thử", "người dùng đã rời bỏ", các khoảng xếp hạng, tham gia vào các thử nghiệm với gợi ý của huấn luyện viên. Người dùng không nhìn thấy chúng, không có trong API công khai, không có tùy chọn "xem và chỉnh sửa phân khúc của mình". Điều này có nghĩa là không chỉ hồ sơ bị rò rỉ mà còn cả cách mà nền tảng tự đánh dấu người chơi cho quảng cáo.
Tại sao đây là scraping, không phải hack: ba bằng chứng
Các nhà phân tích đã xem xét bản sao không dựa vào lời của người bán mà dựa vào cấu trúc dữ liệu.
- Nhịp độ thu thập. Các bản ghi được ghi ngày liên tiếp trong chín ngày — từ ngày 26 tháng 7 đến ngày 3 tháng 8 năm 2026, với các lô không đồng đều từ 72 đến 267 nghìn mỗi ngày. Xuất khẩu cơ sở dữ liệu một lần không giống như vậy: bản sao từ kho lưu trữ bị xâm phạm là một lát cắt tại một thời điểm.
- Trùng lặp. 7,4% bản ghi bị lặp lại: cùng một tài khoản đã xuất hiện trong các lần xuất khác nhau. Đây là dấu hiệu của việc quét tự động với cửa sổ trượt, không phải là xuất bảng.
- UUID phiên bản đầu tiên. Các định danh của Chess.com chứa một dấu thời gian nhúng. Kiểm tra mẫu cho thấy: 169 287 trong số 169 289 UUID trùng khớp với ngày đăng ký tài khoản với độ chính xác lên đến ba giây. Làm giả một sự tương quan như vậy trên hàng triệu bản ghi là không thể — dữ liệu là thật, nhưng được thu thập bằng các yêu cầu hợp pháp.
HIBP đã thêm một lập luận khác: 99% địa chỉ email trong bản sao đã xuất hiện trong các rò rỉ trước đó. Đối với một cơ sở dữ liệu được lấy trực tiếp từ sản xuất, tỷ lệ sẽ khác — ở đây rõ ràng là các địa chỉ đến từ bên ngoài và được đối chiếu với các tài khoản.
Cơ chế: chức năng "tìm bạn bè" như một chỉ mục tìm kiếm
Vector đã được biết đến từ sự cố năm 2023, khi Chess.com đã rò rỉ trước tiên 828 nghìn, sau đó khoảng 476 nghìn bản ghi với cấu trúc trường giống nhau. Khi đó, công ty đã tuyên bố thẳng thừng: "Đây KHÔNG phải là rò rỉ dữ liệu. Hạ tầng của chúng tôi, tài khoản và dữ liệu như mật khẩu đều an toàn". Về mặt hình thức — đúng.
Sơ đồ rất đơn giản. Nền tảng có chức năng tìm kiếm bạn bè: bạn tải lên địa chỉ email, dịch vụ sẽ trả lời xem có người dùng như vậy hay không, và hiển thị hồ sơ của họ. Chúng ta lấy một cơ sở dữ liệu email của người khác (có hàng tỷ địa chỉ công khai — từ đó mà có 99% sự trùng khớp với các rò rỉ trước đó), chạy qua chức năng này và nhận được hồ sơ được làm phong phú: tên, quốc gia, xếp hạng, ngày đăng nhập cuối cùng, phân khúc quảng cáo.
Không có một hoạt động riêng lẻ nào ở đây trông giống như một cuộc tấn công. Nó trở thành một cuộc tấn công khi có hàng triệu lần lặp lại. Các chuyên gia đã phân tích bản sao đã chỉ ra thủ phạm một cách rõ ràng: những kháng cự enumeration, giới hạn tốc độ và giám sát thu thập chậm rãi bị đánh giá thấp. Có nghĩa là có bảo vệ khỏi hack, nhưng không có bảo vệ khỏi việc thử nghiệm kiên nhẫn.
Đây không phải là trường hợp đơn lẻ — đây là một loại vấn đề
Ví dụ lớn nhất của cùng một loại — nghiên cứu của Đại học Vienna về WhatsApp. Nhóm đã thông qua kỹ thuật đảo ngược API phát hiện liên hệ đã khảo sát hơn 100 triệu số điện thoại mỗi giờ, sử dụng một máy chủ đại học và năm tài khoản đã xác thực. Kết quả — liệt kê 3,5 tỷ tài khoản hoạt động: số điện thoại, hình ảnh hồ sơ, khóa công khai. Giới hạn tốc độ chưa bao giờ hoạt động. Thí nghiệm diễn ra từ tháng 12 năm 2024 đến tháng 4 năm 2025, Meta đã âm thầm khắc phục lỗ hổng vào tháng 10 năm 2025, công việc đã được trình bày tại NDSS 2026.
Chi tiết đáng chú ý của cùng một nghiên cứu: 58% số điện thoại từ rò rỉ Facebook năm 2021 vẫn còn hoạt động trong WhatsApp. Dữ liệu được thu thập một lần không bị lỗi thời — chúng trở thành nguyên liệu đầu vào cho lần thử nghiệm tiếp theo. Chess.com vào năm 2026 đã bị tấn công chính xác bởi điều này: nó đã bị tấn công bằng một danh sách được thu thập bởi ai đó khác trước đó.
Điều này thay đổi điều gì cho những người thu thập dữ liệu hợp pháp
Mỗi sự cố như vậy không ảnh hưởng đến kẻ xấu, mà đến tất cả những ai làm việc với dữ liệu công khai. Phản ứng của các nền tảng là dễ đoán: sau khi bị công khai, các giới hạn sẽ được thắt chặt, phân tích hành vi sẽ được triển khai, các điểm cuối tìm kiếm và phát hiện sẽ bị ẩn sau xác thực và captcha. Trình phân tích công khai của bạn không liên quan đến việc thử nghiệm email — nhưng sẽ bị ảnh hưởng bởi quy tắc mới cùng với tất cả. Chúng tôi đã viết về các phương pháp chung cho vấn đề này trong bài phân tích giới hạn API và cách làm việc với chúng.
Vì vậy, cần phải giữ một ranh giới rõ ràng — nó không nằm ở kỹ thuật, mà ở những gì bạn làm với các định danh của con người.
- Dữ liệu công khai — những gì dịch vụ hiển thị cho khách truy cập ẩn danh qua liên kết trực tiếp: thẻ sản phẩm, giá cả, hồ sơ công khai, bài đăng mở. Thu thập — là bình thường.
- Enumeration — việc thay thế danh sách email, số điện thoại hoặc ID bên ngoài vào chức năng tìm kiếm để biết chúng thuộc về ai. Đây không còn là việc thu thập dữ liệu công khai, mà là việc đối chiếu các định danh cá nhân, và trong các khu vực có chế độ tương tự GDPR, nó được phân loại tương ứng — bất kể điểm cuối có mở hay không.
- Các trường ẩn. Các phân khúc quảng cáo của Chess.com không công khai dưới bất kỳ hình thức nào. Nếu từ phản hồi API nhận được điều gì đó không có trong giao diện, đó không phải là "thưởng", mà là tín hiệu để dừng lại.
Danh sách kiểm tra thực tiễn cho việc thu thập dữ liệu một cách có trách nhiệm: không thay thế thông tin liên lạc của người khác vào các chức năng tìm kiếm và phát hiện; giữ nhịp độ mà dịch vụ có thể chịu đựng mà không bị suy giảm; tôn trọng robots.txt và đề nghị công khai; chỉ lấy những trường mà có thể nhìn thấy trong giao diện; không lưu trữ thông tin thừa. Chúng tôi đã xem xét chi tiết khía cạnh pháp lý của vấn đề trong tài liệu về cách thu thập dữ liệu hợp pháp qua proxy.
Phải làm gì nếu địa chỉ của bạn nằm trong bản sao này
Không có mật khẩu trong bản xuất, vì vậy việc thay đổi mật khẩu chỉ vì lý do bị rò rỉ không có nhiều ý nghĩa — nhưng rủi ro không phải là không có, và nó rất đặc thù.
- Kiểm tra địa chỉ trên Have I Been Pwned. Bản ghi có tên Chess.com (2026), được tải lên vào ngày 13 tháng 9 năm 2026, với 4,6 triệu địa chỉ.
- Chờ đợi phishing có mục tiêu. Sự kết hợp "email + tên thật + quốc gia + xếp hạng + ngày đăng nhập cuối cùng + trạng thái đăng ký" — là nguyên liệu hoàn hảo cho một bức thư thuyết phục giả danh từ nền tảng. Một bản phát hành thông thường không trông như vậy; một bức thư biết xếp hạng của bạn thì có vẻ như vậy.
- Kiểm tra nơi khác mà địa chỉ này đã được sử dụng. 99% địa chỉ đã xuất hiện trong các rò rỉ trước đó — có nghĩa là email của bạn đã có trong danh sách của người khác từ lâu và sẽ được thử nghiệm qua nền tảng tiếp theo với chức năng tìm kiếm mở.
- Ngắt liên kết email khỏi hồ sơ công khai ở những nơi có thể. Nếu dịch vụ cho phép bạn cấm tìm kiếm mình qua email hoặc điện thoại — đó chính là công tắc sẽ tắt vector đã mô tả cho riêng bạn.
Đối với những ai xây dựng dịch vụ riêng, kết luận ngắn gọn từ sự cố này còn đơn giản hơn: bất kỳ chức năng nào mà trả lời "có người dùng như vậy, đây là hồ sơ của họ" dựa trên định danh bên ngoài — đó là một chỉ mục tìm kiếm trên cơ sở dữ liệu của bạn, có thể truy cập từ bên ngoài. Nó yêu cầu giới hạn tốc độ trên tài khoản và trên mạng IP, không chỉ trên một địa chỉ, cộng với việc giám sát các lựa chọn chậm rãi rộng rãi, mà trong các chỉ số hàng giờ trông giống như một nền tảng bình thường.
Vai trò của proxy — và điều mà nó chắc chắn không phải là
Cần phải nói rõ, vì sau mỗi sự cố như vậy, có một luận điểm "tất cả đều được thực hiện qua proxy". Proxy giải quyết ba nhiệm vụ: danh tiếng và ASN của địa chỉ IP, gắn kết địa lý của yêu cầu, phân phối tải để không làm vượt quá giới hạn của một địa chỉ khi thu thập hợp pháp. Proxy dân cư cần thiết ở những nơi mà trang web cung cấp nội dung khác nhau theo khu vực hoặc cắt các mạng con của trung tâm dữ liệu — chẳng hạn như trong việc theo dõi giá cả và kết quả ở các quốc gia khác nhau.
Điều mà proxy không làm — không biến việc thử nghiệm email của người khác thành việc thu thập hợp pháp và không bảo vệ khỏi hậu quả. Trong trường hợp của Chess.com, việc phân phối theo địa chỉ, rất có thể, đã cho phép kéo dữ liệu trong chín ngày mà không bị phát hiện, nhưng đó là đặc điểm của sự bảo vệ yếu của nền tảng, không phải là một lập luận ủng hộ cho kịch bản như vậy. Về mặt kỹ thuật, enumeration không thể phân biệt với lưu lượng bình thường cho đến khi ai đó đối chiếu khối lượng với nhật ký — và sau đó cuộc trò chuyện không còn về giới hạn, mà về cơ quan quản lý.
Kết luận
Câu chuyện của Chess.com là tập thứ ba trong ba năm với cùng một bề mặt tấn công và không có một vụ hack nào. Đối với các nền tảng, bài học là cứng rắn: đường bảo vệ chỉ coi sự cố là xâm nhập vào hạ tầng, không thấy cách mà cơ sở dữ liệu bị lấy đi từng phần thông qua tính năng chính thức. Đối với những ai thu thập dữ liệu một cách chuyên nghiệp — cũng có bài học thực tiễn: các hạn chế sẽ được thắt chặt không phải vì các trình phân tích giá, mà vì những câu chuyện như vậy, và giá của mỗi làn sóng mới sẽ đè nặng lên toàn bộ ngành công nghiệp thu thập dữ liệu. Phân biệt giữa việc thu thập công khai và việc thử nghiệm các định danh cá nhân — không chỉ là về đạo đức, mà là về việc liệu dữ liệu công khai có còn được truy cập hay không.