КИБЕРБЕЗОПАСНОСТЬ

Утечка данных Valve затронула покупателей Steam Machine в Европе

Valve предупредила клиентов в Европе о краже имён, адресов и телефонов у партнёра CEVA Logistics после кибератаки в конце июля.

✍️ Редакция iTech News | 11.08.2026 | ⏱ 5 мин | Источник: Habr / Новости

Утечка данных Valve затронула европейских покупателей Steam Machine и Steam Controller: злоумышленники получили доступ к именам, адресам, телефонам и e-mail клиентов через взлом логистического подрядчика CEVA Logistics. История важна не только для геймеров: это ещё одно напоминание для IT-команд и e-commerce, что самые неприятные инциденты нередко происходят не в ядре продукта, а в цепочке подрядчиков, где хранятся «временные» данные для доставки.

О происшествии, как пишет Habr / Новости, Valve сообщила в письмах пострадавшим клиентам Steam в Европе. По данным компании, атака на CEVA Logistics продолжалась в период с 29 июля по 1 августа 2026 года, а о вероятной компрометации данных Valve узнала 7 августа. Поскольку CEVA хранит информацию о доставке до 90 дней после заказа, уведомления отправили всем клиентам, которые могли попасть в затронутую выборку. Для пользователей это выглядит как классический сценарий «ваши платёжные данные не украли, но расслабляться рано»: адреса и контактная информация уже дают злоумышленникам неплохую почву для прицельного фишинга.

Список утекших данных Valve описывает довольно прямо. Речь идёт об именах покупателей, почтовых адресах, номерах телефонов, адресах электронной почты, а также о типе и стоимости заказанного товара. При этом Valve отдельно подчёркивает, что у CEVA не было доступа к паролям от Steam, платёжным данным, кодам Steam Guard и другой чувствительной информации, связанной с самой учётной записью. Формально это снижает масштаб прямого ущерба, но не отменяет проблему: если мошенник знает, что человек действительно заказывал конкретное устройство, знает его адрес и может сослаться на «доставку», вероятность успешной социальной инженерии заметно растёт.

Valve в уведомлении отдельно предупредила клиентов о письмах, SMS и голосовых сообщениях, которые могут маскироваться под Steam, Valve или курьерскую службу. Это важная деталь: злоумышленники, по словам компании, могут использовать реальный адрес получателя как «доказательство подлинности» и просить подтвердить доставку, оплатить небольшую пошлину, сбор за повторную отправку или войти в аккаунт для «проверки» заказа. То есть речь идёт не о гипотетическом риске, а о вполне понятной схеме монетизации утечки. Для компаний, работающих с физической доставкой, здесь нет ничего нового, но от этого не легче: даже без карт и паролей набор «имя + адрес + телефон + история покупки» давно стал самостоятельным активом на стороне атакующих.

Любопытен и сам контур инцидента. CEVA Logistics — не маленький локальный подрядчик, а крупный международный игрок и дочерняя компания CMA CGM Group. В материале говорится, что CEVA управляет 1000 складами, обработала 15 миллионов отправлений за прошлый год и сообщила о выручке в $18,3 млрд в 2025 году. Это полезный контекст для понимания масштаба: чем крупнее логистическая сеть и чем больше в ней систем, подрядчиков и интеграций, тем шире поверхность атаки. 1 августа CEVA уже уведомила нескольких европейских ритейлеров о кибератаке, нарушившей работу восьми её складов в Европе. Теперь видно, что история не ограничилась операционным сбоем и затронула данные клиентов одного из заметных партнёров.

Для самой Valve эта ситуация неприятна сразу в двух плоскостях. Во-первых, под удар попали покупатели железа Steam, а это всегда более чувствительная аудитория с физическими адресами и ожиданием доставки. Во-вторых, даже если компрометация произошла у подрядчика, пользователь всё равно видит в письме прежде всего знакомый бренд Valve, а не архитектуру цепочки поставок. Репутационный счёт приходит владельцу клиентского интерфейса, а не только оператору склада. Именно поэтому компании пришлось отдельно объяснять, какие именно данные были у CEVA, чего у неё не было и почему пользователям не нужно менять пароль или трогать настройки Steam-аккаунта.

Для русскоязычной IT-аудитории здесь несколько практических выводов. Первый: инвентаризация данных подрядчиков должна быть не формальным приложением к договору, а живым процессом с понятным сроком хранения и минимизацией состава передаваемых полей. Второй: уведомления после инцидента должны заранее учитывать сценарии мошенничества. Valve фактически сделала правильный шаг, заранее описав, как именно будут выглядеть фальшивые сообщения и на какие триггеры пользователь должен реагировать настороженно. Третий: логистика, поддержка и внешние сервисы давно стали такой же частью attack surface, как основная платформа, API или корпоративная почта. Если в вашей модели угроз подрядчики до сих пор живут в разделе «доверенная сторона», модель пора переписывать.

Есть и более приземлённый бизнес-урок. Данные доставки часто воспринимают как технический мусор: «это же не карточка и не пароль». На практике именно такие данные хорошо работают в мошеннических цепочках, потому что выглядят правдоподобно и не вызывают мгновенной тревоги у пользователя. После подобных историй компаниям стоит пересматривать не только требования к безопасности партнёров, но и UX уведомлений, шаблоны писем, сценарии customer support и внутренние playbook на случай утечки. Когда пользователю приходит сообщение про «небольшую пошлину» за уже ожидаемую посылку, побеждает не тот, у кого лучше SIEM, а тот, кто раньше и понятнее объяснил, как выглядит обман.

Утечка данных Valve в этом смысле — не экзотика из мира игр, а очень прикладной кейс про уязвимость экосистемы поставок. Чем больше компании выносят наружу логистику, fulfilment и поддержку, тем чаще инцидент будет начинаться не с взлома самого сервиса, а с компрометации партнёра, у которого «всего лишь» лежали адреса и телефоны. И главный вопрос здесь уже не в том, можно ли полностью исключить такие утечки, а в том, насколько быстро бизнес способен сузить объём передаваемых данных и не дать злоумышленникам превратить базу доставок в дешёвый конвейер фишинга.

Поделиться: Telegram X LinkedIn