Наиболее подробный анализ описывает компрометацию 659 торговых аккаунтов, 650 действующих секретных ключей sk_live и примерно 688 363 клиентских записей из 42 стран. Архив оценивался примерно в 35 ГБ и включал 17 654 файла.

Какие данные оказались в архиве

В опубликованных материалах, как сообщается, были записи, связанные с:

• платежами и списаниями;
• Payment Intents — объектами, описывающими намерение провести платёж;
• счетами и инвойсами;
• выплатами продавцам;
• возвратами;
• балансом и транзакциями по нему.

Данные охватывали период с января 2022 года по июнь 2026 года.

Риск был связан не только с раскрытием информации. По данным исследователей, 519 из 659 аккаунтов могли одновременно принимать платежи и отправлять выплаты. Если ключи оставались активными, это создавало возможность для мошеннических операций и попыток перенаправить средства.

Больше всего затронутых продавцов, согласно опубликованной оценке, находилось в США — 212 аккаунтов, затем в Великобритании — 81 и Франции — 57.

Почему цифры в разных отчётах расходятся

Анализ Hudson Rock, посвящённый связанному с публикацией первоначальному релизу, указывал на 669 папок продавцов, 1 033 скомпрометированных API-ключа и заявленный объём в 33 ГБ.

Эти показатели не совпадают с более поздней оценкой в 659 аккаунтов, 650 действующих ключей, 35 ГБ и 17 654 файла. Вероятно, отчёты описывают разные этапы публикации, методы подсчёта или критерии проверки. Поэтому их не следует складывать в один окончательный итог.

Hudson Rock также сообщила, что на форуме рекламировался архив размером 33 ГБ, тогда как доступный для скачивания файл занимал около 2,37 ГБ. Это согласуется с заявлением о наличии дополнительных материалов, но само по себе его не доказывает. Утверждение о примерно 20 000 дополнительных ключей Stripe, якобы предназначенных для будущих публикаций, независимо не подтверждено.

Это не похоже на взлом инфраструктуры Stripe

Доступные данные указывают на сценарий, при котором злоумышленники использовали украденные секретные ключи продавцов для обычных запросов к Stripe API. Иными словами, доступ к данным отдельных аккаунтов мог быть получен с помощью уже авторизующих ключей, а не через уязвимость в центральных системах Stripe. Исследователи не обнаружили свидетельств компрометации самой инфраструктуры Stripe.

Секретные ключи могли утечь через:

• журналы инфостилеров — вредоносных программ, крадущих пароли и токены;
• коммиты в публичных репозиториях;
• открытые файлы .env;
• незащищённые резервные копии;
• логи CI/CD-систем;
• неправильно настроенные веб-серверы;
• автоматический поиск переменных окружения и других плохо защищённых секретов.

На момент публикации исследователи не связали заражение инфостилером с конкретными доменами продавцов из набора данных. Поэтому первоначальный источник утечки ключей остаётся неустановленным.

Разница важна для расследования инцидента. Взлом Stripe означал бы системное событие на уровне платформы, тогда как текущие сведения указывают на массовую утечку множества отдельных ключей, которые затем использовали для доступа к соответствующим аккаунтам.

Что можно сделать с одним действующим ключом

Исследователи сообщили, что одного активного ключа хватило, чтобы получить доступ к списку клиентов продавца, создать мошенническую платёжную ссылку Payment Link и выполнить тестовое списание всего за 17 часов.

Это демонстрирует, почему действующий секретный ключ с широкими полномочиями нужно рассматривать как немедленный инцидент безопасности. Злоумышленнику необязательно взламывать Stripe, если ключ уже даёт доступ к данным клиентов и платёжным операциям.

Последствия могут включать не только утечку информации. В зависимости от разрешений ключа и настроек аккаунта злоумышленник способен получить доступ к платёжным данным или выполнять операции со ссылками на оплату, списаниями, возвратами и выплатами. При этом опубликованные материалы не доказывают, что мошеннические действия произошли в каждом из перечисленных аккаунтов.

Почему проверки GitHub недостаточно

Инцидент показывает ограничения проверки публичных репозиториев. Ключи могут сохраняться не только в текущем коде, но и в логах GitHub Actions, исторических артефактах, публичных файлах .env, резервных копиях и на неправильно настроенных серверах. Поэтому обычное сканирование репозитория не обеспечивает полного контроля над секретами.

Отдельно сообщалось, что исследователи обнаружили более 50 000 секретов Stripe в публичном коде, логах GitHub Actions и на неправильно настроенных серверах. Это показатель масштабной проблемы поиска открытых ключей, а не число ключей, подтверждённо вошедших в архив от 18 августа.

Удаление ключа из последней версии репозитория также не делает его безопасным: копии могут оставаться в истории коммитов, логах сборки, артефактах, резервных копиях или уже развернутых системах.

Что делать продавцам Stripe

Компаниям, которые могли раскрыть секретные ключи, следует сосредоточиться на сдерживании инцидента:

1. Немедленно отозвать или заменить потенциально раскрытые действующие ключи. Простого удаления файла или записи из репозитория недостаточно — сам ключ продолжит работать.
2. Проверить журналы API и аккаунта Stripe на наличие незнакомых IP-адресов, обращений к спискам клиентов, выгрузок данных, создания Payment Link, попыток платежей, возвратов и операций с выплатами.
3. Проверить банковские реквизиты для выплат и недавние изменения выплат. При необходимости временно усилить контроль за переводами.
4. Заменить широкие секретные ключи ограниченными, разрешив приложению только те операции API, которые ему действительно нужны.
5. Перенести секреты в управляемое хранилище и удалить их из исходного кода, файлов окружения, логов и незащищённых резервных копий.
6. Проверить историю репозиториев, логи CI/CD, артефакты, серверы и резервные копии, а не только текущий публичный код.

Имеющиеся свидетельства говорят о серьёзной утечке ключей продавцов с существенным риском для клиентских и платёжных данных. Они не подтверждают взлом центральной инфраструктуры Stripe. Из-за расхождений в подсчётах итоговые показатели следует воспринимать как оценки конкретных наборов данных, а не как единую окончательную инвентаризацию.

Наиболее подробный анализ описывает компрометацию 659 торговых аккаунтов, 650 действующих секретных ключей sk_live и примерно 688 363 клиентских записей из 42 стран. Архив оценивался примерно в 35 ГБ и включал 17 654 файла.

Какие данные оказались в архиве

В опубликованных материалах, как сообщается, были записи, связанные с:

• платежами и списаниями;
• Payment Intents — объектами, описывающими намерение провести платёж;
• счетами и инвойсами;
• выплатами продавцам;
• возвратами;
• балансом и транзакциями по нему.

Данные охватывали период с января 2022 года по июнь 2026 года.

Риск был связан не только с раскрытием информации. По данным исследователей, 519 из 659 аккаунтов могли одновременно принимать платежи и отправлять выплаты. Если ключи оставались активными, это создавало возможность для мошеннических операций и попыток перенаправить средства.

Больше всего затронутых продавцов, согласно опубликованной оценке, находилось в США — 212 аккаунтов, затем в Великобритании — 81 и Франции — 57.

Почему цифры в разных отчётах расходятся

Анализ Hudson Rock, посвящённый связанному с публикацией первоначальному релизу, указывал на 669 папок продавцов, 1 033 скомпрометированных API-ключа и заявленный объём в 33 ГБ.

Эти показатели не совпадают с более поздней оценкой в 659 аккаунтов, 650 действующих ключей, 35 ГБ и 17 654 файла. Вероятно, отчёты описывают разные этапы публикации, методы подсчёта или критерии проверки. Поэтому их не следует складывать в один окончательный итог.

Hudson Rock также сообщила, что на форуме рекламировался архив размером 33 ГБ, тогда как доступный для скачивания файл занимал около 2,37 ГБ. Это согласуется с заявлением о наличии дополнительных материалов, но само по себе его не доказывает. Утверждение о примерно 20 000 дополнительных ключей Stripe, якобы предназначенных для будущих публикаций, независимо не подтверждено.

Это не похоже на взлом инфраструктуры Stripe

Доступные данные указывают на сценарий, при котором злоумышленники использовали украденные секретные ключи продавцов для обычных запросов к Stripe API. Иными словами, доступ к данным отдельных аккаунтов мог быть получен с помощью уже авторизующих ключей, а не через уязвимость в центральных системах Stripe. Исследователи не обнаружили свидетельств компрометации самой инфраструктуры Stripe.

Секретные ключи могли утечь через:

• журналы инфостилеров — вредоносных программ, крадущих пароли и токены;
• коммиты в публичных репозиториях;
• открытые файлы .env;
• незащищённые резервные копии;
• логи CI/CD-систем;
• неправильно настроенные веб-серверы;
• автоматический поиск переменных окружения и других плохо защищённых секретов.

На момент публикации исследователи не связали заражение инфостилером с конкретными доменами продавцов из набора данных. Поэтому первоначальный источник утечки ключей остаётся неустановленным.

Разница важна для расследования инцидента. Взлом Stripe означал бы системное событие на уровне платформы, тогда как текущие сведения указывают на массовую утечку множества отдельных ключей, которые затем использовали для доступа к соответствующим аккаунтам.

Что можно сделать с одним действующим ключом

Исследователи сообщили, что одного активного ключа хватило, чтобы получить доступ к списку клиентов продавца, создать мошенническую платёжную ссылку Payment Link и выполнить тестовое списание всего за 17 часов.

Это демонстрирует, почему действующий секретный ключ с широкими полномочиями нужно рассматривать как немедленный инцидент безопасности. Злоумышленнику необязательно взламывать Stripe, если ключ уже даёт доступ к данным клиентов и платёжным операциям.

Последствия могут включать не только утечку информации. В зависимости от разрешений ключа и настроек аккаунта злоумышленник способен получить доступ к платёжным данным или выполнять операции со ссылками на оплату, списаниями, возвратами и выплатами. При этом опубликованные материалы не доказывают, что мошеннические действия произошли в каждом из перечисленных аккаунтов.

Почему проверки GitHub недостаточно

Инцидент показывает ограничения проверки публичных репозиториев. Ключи могут сохраняться не только в текущем коде, но и в логах GitHub Actions, исторических артефактах, публичных файлах .env, резервных копиях и на неправильно настроенных серверах. Поэтому обычное сканирование репозитория не обеспечивает полного контроля над секретами.

Отдельно сообщалось, что исследователи обнаружили более 50 000 секретов Stripe в публичном коде, логах GitHub Actions и на неправильно настроенных серверах. Это показатель масштабной проблемы поиска открытых ключей, а не число ключей, подтверждённо вошедших в архив от 18 августа.

Удаление ключа из последней версии репозитория также не делает его безопасным: копии могут оставаться в истории коммитов, логах сборки, артефактах, резервных копиях или уже развернутых системах.

Что делать продавцам Stripe

Компаниям, которые могли раскрыть секретные ключи, следует сосредоточиться на сдерживании инцидента:

1. Немедленно отозвать или заменить потенциально раскрытые действующие ключи. Простого удаления файла или записи из репозитория недостаточно — сам ключ продолжит работать.
2. Проверить журналы API и аккаунта Stripe на наличие незнакомых IP-адресов, обращений к спискам клиентов, выгрузок данных, создания Payment Link, попыток платежей, возвратов и операций с выплатами.
3. Проверить банковские реквизиты для выплат и недавние изменения выплат. При необходимости временно усилить контроль за переводами.
4. Заменить широкие секретные ключи ограниченными, разрешив приложению только те операции API, которые ему действительно нужны.
5. Перенести секреты в управляемое хранилище и удалить их из исходного кода, файлов окружения, логов и незащищённых резервных копий.
6. Проверить историю репозиториев, логи CI/CD, артефакты, серверы и резервные копии, а не только текущий публичный код.

Имеющиеся свидетельства говорят о серьёзной утечке ключей продавцов с существенным риском для клиентских и платёжных данных. Они не подтверждают взлом центральной инфраструктуры Stripe. Из-за расхождений в подсчётах итоговые показатели следует воспринимать как оценки конкретных наборов данных, а не как единую окончательную инвентаризацию.