13 сентября 2026 года в Have I Been Pwned появилась запись Chess.com (2026): 7,3 млн строк, 4,6 млн уникальных email-адресов. Паролей в дампе нет, хешей нет, платёжных данных нет. И взлома, судя по всему, тоже не было: данные собирали девять дней подряд обычными запросами к живому сервису. Это тот случай, когда «утечка» и «проникновение в систему» — разные вещи, и разбираться стоит именно в механике.
Что именно попало в публичный доступ
Архив появился на киберкриминальном форуме 12 августа 2026 года и разошёлся через Telegram. Распакованный файл — 15,5 ГБ (744 МБ в 7-Zip), внутри 7 337 395 записей по 38 полей в каждой.
- Email-адреса — примерно у 75% записей (4,6 млн уникальных).
- Имена пользователей, реальные имена, user ID и UUID.
- Страна, локация, язык интерфейса.
- Рейтинги, звания, уровень игры, статус премиум-подписки.
- Даты регистрации и последнего входа — вплоть до августа 2026 года.
- Рекламные сегменты Google Ad Manager — поля gam_audiences и audiences_member_of.
Последний пункт — самый неожиданный. Это внутренние маркетинговые метки вроде «подходит для пробного периода», «ушедший пользователь», диапазоны рейтинга, участие в экспериментах с подсказками тренера. Пользователю они не видны, в публичном API их нет, настройки «посмотреть и поправить свой сегмент» не существует. То есть в дамп попал не только профиль, но и то, как площадка сама размечает игрока для рекламы.
Почему это скрапинг, а не взлом: три доказательства
Аналитики, разбиравшие дамп, опирались не на слова продавца, а на структуру данных.
- Ритм сбора. Записи датированы девятью днями подряд — с 26 июля по 3 августа 2026 года, неравномерными партиями от 72 до 267 тысяч в день. Единовременный экспорт базы так не выглядит: дамп из скомпрометированного хранилища — это один срез на один момент.
- Дубли. 7,4% записей повторяются: один и тот же аккаунт попадал в выгрузку в разные дни. Признак автоматизированного обхода со скользящим окном, а не выгрузки таблицы.
- UUID первой версии. Идентификаторы Chess.com содержат встроенную временную метку. Проверка выборки показала: 169 287 из 169 289 UUID совпали с датой регистрации аккаунта с точностью до трёх секунд. Подделать такую корреляцию на миллионах записей невозможно — данные настоящие, но получены легальными по форме запросами.
В HIBP добавили ещё один аргумент: 99% email-адресов из дампа уже встречались в прошлых утечках. Для базы, поднятой прямо из продакшена, доля была бы иной — здесь же видно, что адреса пришли снаружи и сопоставлялись с аккаунтами.
Механика: функция «найти друзей» как поисковый индекс
Вектор известен ещё по инциденту 2023 года, когда с Chess.com утекли сначала 828 тысяч, а затем ещё около 476 тысяч записей с идентичной структурой полей. Тогда компания заявила прямо: «Это НЕ утечка данных. Наша инфраструктура, аккаунты и данные вроде паролей в безопасности». Формально — правда.
Схема простая. У площадки есть функция поиска знакомых: вы загружаете адрес почты, сервис отвечает, есть ли такой пользователь, и показывает его профиль. Берём чужую базу email (их в открытом доступе миллиарды — отсюда и те самые 99% совпадений с прошлыми утечками), прогоняем через эту функцию и получаем на выходе обогащённый профиль: имя, страну, рейтинг, дату последнего входа, рекламный сегмент.
Ни одна отдельная операция здесь не выглядит атакой. Атакой это становится на миллионах повторов. Эксперты, разбиравшие дамп, назвали виновника прямо: недооценённые enumeration resistance, ограничение темпа и мониторинг медленного широкого сбора. То есть защита есть от взлома, но нет от терпеливого перебора.
Это не единичный случай — это класс проблем
Самая крупная демонстрация того же класса — исследование Венского университета по WhatsApp. Команда через реверс-инжиниринг API контакт-дискавери опрашивала более 100 млн телефонных номеров в час, используя один университетский сервер и пять аутентифицированных аккаунтов. Итог — перечислены 3,5 млрд активных аккаунтов: номера, фотографии профилей, публичные ключи. Ограничение темпа не сработало ни разу. Эксперимент шёл с декабря 2024 по апрель 2025 года, Meta тихо закрыла дыру в октябре 2025-го, работу представили на NDSS 2026.
Показательная деталь того же исследования: 58% телефонных номеров из старой утечки Facebook 2021 года всё ещё были активны в WhatsApp. Данные, собранные один раз, не устаревают — они становятся входным материалом для следующего перебора. Chess.com в 2026-м пострадал ровно от этого: его атаковали списком, собранным кем-то другим и раньше.
Что это меняет для тех, кто собирает данные легально
Каждый такой инцидент бьёт не по злоумышленнику, а по всем, кто работает с публичными данными. Реакция площадок предсказуема: после огласки закручиваются лимиты, выкатывается поведенческий анализ, эндпойнты поиска и дискавери прячутся за авторизацию и капчу. Ваш аккуратный парсер публичных карточек товаров не имеет отношения к перебору email — но под новое правило попадёт вместе со всеми. Об общих подходах к этой проблеме мы писали в разборе лимитов API и работы с ними.
Поэтому стоит чётко держать границу — она проходит не по технике, а по тому, что вы делаете с идентификаторами людей.
- Публичные данные — то, что сервис показывает анонимному посетителю по прямой ссылке: карточка товара, цена, публичный профиль, открытый пост. Собирать — нормально.
- Enumeration — подстановка внешнего списка email, телефонов или ID в функцию поиска, чтобы узнать, кому они принадлежат. Это уже не сбор публичных данных, а сопоставление персональных идентификаторов, и в юрисдикциях с GDPR-подобным режимом оно квалифицируется соответствующе — независимо от того, что эндпойнт открыт.
- Скрытые поля. Рекламные сегменты Chess.com не были публичными ни в каком виде. Если из ответа API прилетает то, чего нет в интерфейсе, это не «бонус», а сигнал остановиться.
Практический чек-лист для добросовестного сбора: не подставляйте чужие контактные данные в поисковые и дискавери-функции; держите темп, который сервис выдерживает без деградации; уважайте robots.txt и публичную оферту; забирайте только те поля, которые видны в интерфейсе; не храните лишнее. Юридическую сторону вопроса мы подробно разбирали в материале о том, как законно собирать данные через прокси.
Что делать, если ваш адрес в этом дампе
Паролей в выгрузке нет, поэтому менять пароль ради самого факта попадания смысла мало — но риск не нулевой, и он специфический.
- Проверьте адрес в Have I Been Pwned. Запись называется Chess.com (2026), загружена 13 сентября 2026 года, 4,6 млн адресов.
- Ждите таргетированного фишинга. Связка «email + настоящее имя + страна + рейтинг + дата последнего входа + статус подписки» — готовый материал для убедительного письма якобы от площадки. Обычная рассылка так не выглядит; письмо, знающее ваш рейтинг, выглядит.
- Проверьте, где ещё использован этот адрес. 99% адресов уже светились в прошлых утечках — значит, ваш email давно в чужих списках и будет прогоняться через следующую площадку с открытой функцией поиска.
- Отвяжите почту от публичного профиля там, где это возможно. Если сервис позволяет запретить поиск себя по email или телефону — это ровно тот переключатель, который выключает описанный вектор лично для вас.
Для тех, кто строит собственный сервис, короткий вывод из инцидента ещё проще: любая функция, которая по внешнему идентификатору отвечает «такой пользователь есть, вот его карточка», — это поисковый индекс по вашей базе, доступный снаружи. Он требует ограничения темпа на аккаунт и на IP-подсеть, а не только на один адрес, плюс мониторинга широких медленных выборок, которые в почасовых метриках выглядят как нормальный фон.
Роль прокси — и чем она точно не является
Стоит сказать прямо, потому что после каждого такого инцидента всплывает тезис «всё это делается через прокси». Прокси решают три задачи: репутация и ASN IP-адреса, географическая привязка запроса, распределение нагрузки, чтобы не выбивать лимит одного адреса при легальном объёме сбора. Резидентные прокси нужны там, где сайт отдаёт разный контент по региону или режет датацентровые подсети, — например при мониторинге цен и выдачи в разных странах.
Чего прокси не делают — не превращают перебор чужих email в законный сбор и не защищают от последствий. В кейсе Chess.com распределение по адресам, скорее всего, и позволило тянуть данные девять дней незамеченным, но это характеристика слабой защиты площадки, а не аргумент в пользу такого сценария. Технически enumeration неотличим от нормального трафика ровно до момента, когда кто-то сопоставит объём с логами, — а дальше начинается разговор не про лимиты, а про регулятора.
Вывод
История Chess.com — это третий за три года эпизод с одной и той же поверхностью атаки и без единого взлома. Для площадок вывод жёсткий: контур защиты, который считает инцидентом только проникновение в инфраструктуру, не видит, как базу выносят по частям через штатную фичу. Для тех, кто собирает данные профессионально, — тоже практический: ограничения ужесточают не из-за парсеров цен, а из-за таких историй, и цена каждой новой волны ложится на всю индустрию сбора данных. Разделять публичный сбор и перебор персональных идентификаторов — это не про этикет, это про то, останутся ли публичные данные доступными вообще.