Для кого эта статья: для людей, которые создали проект на CAMPFIRE, поддержали его, получили возврат средств или зарегистрировались как партнёры, а также для разработчиков и администраторов, которые работают с GitHub и облачными сервисами. Статья основана на официальных уведомлениях самой CAMPFIRE и не описывает методы атак.
Что делать пользователям прямо сейчас
Проверьте, затронуты ли вы: письмо с уведомлением имеет фиксированную тему
С 24 апреля 2026 года компания отправляет затронутым людям отдельные письма с японской темой «【重要：CAMPFIRE】お客様情報漏えい可能性に関するお詫びとご報告» (извинения и отчёт о возможной утечке информации о клиентах). Затронутые группы:
- Часть владельцев проектов и сообществ, которые пользовались сервисом до 9 апреля 2026 года
- Покровители, которые платили через PayPal (с 1 января 2021 года по 19 апреля 2026 года) или через отсрочку платежа Kondo-barai (с 3 января 2022 года по 24 апреля 2023 года)
- Покровители, которые получили возврат средств банковским переводом (с 6 января 2022 года по 5 марта 2026 года)
- Партнёры, зарегистрированные до 5 марта 2025 года
- Люди, которые в 2020 году редактировали банковские реквизиты на странице своего аккаунта
Если вы подпадаете под одну из этих групп, но не нашли письма, всё равно выполните перечисленные шаги.
Не открывайте ссылки в сообщениях о возврате средств или счетах для выплат
Под угрозой оказались имя, адрес, номер телефона, адрес электронной почты и банковские реквизиты. Если вы получили сообщение «повторно зарегистрируйте аккаунт для возврата средств» или «подтвердите, куда отправить деньги», не открывайте ссылку; при необходимости входите в CAMPFIRE через закладку или адрес, который вводите вручную. Компания заявляет, что никогда не запрашивает PIN-коды по телефону или электронной почте (основы: что такое фишинг).
Проверьте банковские выписки
Компания говорит, что банковские реквизиты, которые могли утечь, сами по себе не позволяют снять наличные или сделать переводы. Компания просит немедленно связаться с банком или с ней, если вы увидите незнакомые операции. Если вы пользуетесь интернет-банком, уведомления об операциях помогут быстрее заметить такие случаи.
Отказывайтесь от неожиданных посылок наложенным платежом
Поскольку в данных есть адреса, компания предупреждает о мошенниках, которые отправляют посылки наложенным платежом, которых вы не заказывали. Перед получением проверьте отправителя и содержимое.
Смените пароли, которые используете на других сервисах
Компания просит людей, которые используют одинаковые адрес электронной почты и пароль на других сервисах, поменять их в целях предосторожности. Пароли не входят в перечисленные данные, но прекратите повторное использование уже сейчас; практичный способ сделать это — менеджер паролей.
Владельцы проектов: проинформируйте и свою команду
Если проект ведёт компания или группа людей, сотрудникам могут приходить письма, выдающие себя за уведомления о выплатах или проверках. Договоритесь в команде проверять изменения счёта для выплат в панели управления CAMPFIRE и никогда не выполнять инструкции только из письма.
Выделенная линия компании — 0120-188-070 (с 10:00 до 19:00 JST, с июля только по будням; бесплатно внутри Японии). В Японии по вопросам мошенничества работает полицейская линия консультаций #9110.
Что произошло (по уведомлениям CAMPFIRE)
Компания опубликовала серию уведомлений с 3 апреля 2026 года и отчёт о расследовании от 2 июня. Всё, что приведено ниже, соответствует официальным уведомлениям компании.
2 апреля 2026 г., около 22:50 JST
Выявлен несанкционированный доступ третьей стороны к учётной записи GitHub, которая использовалась для управления системой; часть исходного кода могла быть просмотрена (как указано в первом уведомлении).3 апреля
Обнаружены подозрительные действия в некоторых репозиториях GitHub; связанные учётные записи удалены, возможно украденные учётные данные заменены. Опубликовано первое уведомление (на тот момент утечка персональных данных не подтверждена).7 апреля
Установлена причина утечки учётных данных GitHub.14 апреля
Второе уведомление: учётная запись GitHub могла просматривать имя и контактные данные одного делового партнёра, а также имена и адреса электронной почты 413 человек, работавших над разработкой. Сообщено в Комиссию по защите персональных данных Японии.20 апреля
Обнаружен несанкционированный доступ к облачной среде, используемой для внутренних бизнес-процессов; злоупотребляемые учётные записи и ресурсы остановлены и отключены.22–24 апреля
В третьем уведомлении сообщено о следах несанкционированного доступа к части системы, управляющей данными клиентов. Четвёртое уведомление (24 апреля) раскрыло масштаб возможной утечки (225 846 уникальных записей затронутых пользователей), начались индивидуальные уведомления.27–28 апреля
Пятое уведомление уточнило разбивку. 28 апреля открыта выделенная линия для вопросов.30 мая / 2 июня
Внешняя криминалистическая экспертиза завершена (30 мая). 2 июня компания опубликовала результаты расследования и меры профилактики.
- Часть владельцев проектов и сообществ
- Имя, адрес, номер телефона, адрес электронной почты, банковские реквизиты. 108 784 записи (53 869 с банковскими реквизитами)
- Часть покровителей
- Имя, адрес, номер телефона, адрес электронной почты, банковские реквизиты. 118 010 записей (4 307 с банковскими реквизитами)
- Партнёры
- Имя. 1 282 записи
- Категория неясна (например, незавершённая регистрация)
- Банковские реквизиты людей, которые редактировали их на странице аккаунта в 2020 году. 10 521 запись
- Прочее
- 413 записей с именами и адресами электронной почты, связанных с разработкой, были доступны для просмотра
- Данные банковских карт
- Не включены
- Результаты экспертизы
- В определённой облачной среде были получены учётные данные и ключи API, некоторые файлы данных без персональной информации, а также названия таблиц и сведения о конфигурации. Во время исследования одна запись с персональными данными была выведена как результат запроса. Следов передачи за пределы компании файлов с персональными данными не найдено
- Оценка компании
- Поскольку в некоторых областях журналы не собирались, компания не может исключить просмотр данных
- Вторичный ущерб
- На момент уведомлений сообщений о вреде от злоупотребления данными не поступало
Для разработчиков и администраторов: от токена GitHub до внутреннего облака
Отчёт компании от 2 июня необычно подробно описывает последовательность событий и причину. Схема показывает путь так, как его описала компания, и справа — настройки, которые предотвращают или ограничивают ущерб на каждом этапе.
1. Учётные данные GitHub, выпущенные сотрудником
Непреднамеренно загружены на сервер для личного проекта
↓→
Политика организации: блокировать классические токены, ограничивать срок действия
2. Репозитории организации
Часть исходного кода и данные о 413 сотрудниках были доступны для просмотра
↓→
Минимальные права по умолчанию, в репозиториях нет персональных данных
3. От информации GitHub к учётным данным облака
↓→
Без долгоживущих ключей облака (использовать краткосрочную аутентификацию)
4. Часть области управления внутреннего облака
Получены учётные данные, ключи API, названия таблиц
↓→
Журналы аудита везде, оповещения о необычных действиях
5. Данные клиентов в 225 846 уникальных записях затронутых пользователей под угрозой
↓→
Вести учёт данных клиентов вне производственной среды
По словам компании, сервис работает в среде, отдельной от облачной среды, где был обнаружен несанкционированный доступ, и злоупотреблений или изменений платформы сервиса не выявлено. Данные клиентов всё же оказались под угрозой, поскольку к ним можно было получить доступ из внутреннего бизнес-облака.
Компания говорит, что данные для доступа должны были храниться только в средах под её контролем и предоставлять минимально необходимые права, а её механизмы и правила управления учётными данными и разграничения прав были недостаточными. Меры, которые, по словам компании, уже выполнены:
- Отказ от персональных токенов доступа в пользу методов аутентификации с ограниченными правами
- Пересмотр прав доступа по умолчанию внутри организации
- Усиление сбора журналов аудита и оповещений
- Внедрение инструмента сканирования кода на уязвимости
Если вы хотите сделать то же в своей организации, начните с этих трёх шагов.
Настройте политику персональных токенов доступа в организации GitHub
В настройках организации, в разделе «Personal access tokens», GitHub позволяет владельцам организации:
- Запретить персональным токенам доступа (classic) обращаться к ресурсам организации
- Требовать одобрения администратора для гранулярных токенов (более новый тип, ограниченный определёнными репозиториями и правами)
- Задать максимальный срок действия токена
Поскольку полностью исключить попадание рабочего токена на личный компьютер или сервер невозможно, реальная защита — сделать так, чтобы в случае такого попадания токен быстро переставал работать и имел очень ограниченный доступ.
Держите долгоживущие ключи облака вдали от репозиториев
Компания говорит, что третья сторона использовала информацию, доступную на GitHub, чтобы найти и получить учётные данные облака. Если GitHub Actions развёртывает ваше приложение в облаке, перейдите на краткосрочную аутентификацию через OpenID Connect (OIDC), которая выдаёт временные учётные данные для каждого запуска, и не храните долгоживущие ключи доступа в репозиториях и конфигурационных файлах.
Сначала проверьте репозитории, включая историю коммитов, и отзовите и перевыпустите всё, что найдёте; см. поиск секретов до коммита с gitleaks. Защита от push в GitHub, которая блокирует отправку секретов, бесплатна для публичных репозиториев и доступна для приватных как часть платного GitHub Secret Protection.
Запишите, где вне производственной среды хранятся данные клиентов
Аналитические платформы, внутренние инструменты, административные панели поддержки, выгруженные CSV-файлы. Как бы хорошо ни была защищена производственная среда, копия данных клиентов в другой среде всё равно может утечь. Для каждого места укажите, чьи учётные данные дают доступ к ней и ведутся ли журналы операций.
CAMPFIRE говорит, что не может исключить просмотр данных, поскольку в некоторых областях журналов не было. Там, где нет журналов операций, нельзя доказать, что никто не просматривал данные.
Позиция этого сайта: разрабатывайте токены, исходя из того, что они могут покинуть машины компании
Компания говорит, что учётные данные GitHub, выпущенные сотрудником, непреднамеренно были загружены на сервер, который сотрудник использовал для личной разработки. Дело не в одном человеке; это отражает общее для любой организации: разработчики пишут код и вне работы. Вероятность того, что рабочий токен покинет управляемые машины, нельзя свести к нулю. Поэтому одного предотвращения утечек недостаточно: токены нужно проектировать так, чтобы токен, который всё же утёк, быстро истекал и давал очень ограниченный доступ.
В том же году в южнокорейской TVING один ключ доступа разработчика открыл доступ ко всему исходному коду и производственным учётным данным (утечка данных TVING). Общий путь проникновения в японских инцидентах того года описан в статье взломы 2026 года шли через легитимные учётные данные.
Источники (публичные материалы)
Факты в этой статье основаны на следующих публичных источниках. Мы не строим предположений о нераскрытых методах.
- CAMPFIRE, Inc., уведомление о несанкционированном доступе к учётной записи GitHub (3 апреля 2026 года; на японском языке) — campfire.co.jp
- Там же, второе уведомление (14 апреля 2026 года) — campfire.co.jp
- Там же, третье уведомление (22 апреля 2026 года) — campfire.co.jp
- CAMPFIRE, Inc., извинения и отчёт о возможной утечке персональных данных вследствие несанкционированного доступа (24 апреля 2026 года) — campfire.co.jp
- CAMPFIRE, Inc., уточнение масштаба возможной утечки (27 апреля 2026 года) — campfire.co.jp
- CAMPFIRE, Inc., открытие выделенной линии для вопросов (28 апреля 2026 года) — campfire.co.jp
- CAMPFIRE, Inc., результаты расследования инцидента несанкционированного доступа (2 июня 2026 года) — campfire.co.jp
- GitHub Docs, «Setting a personal access token policy for your organization» — docs.github.com / «About push protection» — docs.github.com / «About security hardening with OpenID Connect» — docs.github.com
История обновлений
2026-10-19: Единица измерения исправлена с «людей» на официальное число уникальных записей пользователей; возможная утечка отделена от подтверждённых выводов; пересекающиеся категории сохранены без суммирования.
2026-09-30: Первая публикация на основе уведомлений CAMPFIRE — от первого уведомления 3 апреля 2026 года до отчёта о расследовании от 2 июня. Количество записей соответствует разбивке в отчёте от 2 июня.
Читайте далее
- Другой японский случай в этом году: Medica Shuppan (банковские реквизиты медицинских специалистов и авторов)
- Мошенничество после утечек: что такое фишинг / как выбрать менеджер паролей
- Разработчикам: поиск секретов до коммита с gitleaks / безопасность self-hosted Git и GitHub / основы .env и ключей API
- Тот же паттерн: взломы через легитимные учётные данные / утечка данных TVING
- Другие инциденты 2026 года: утечки данных и кибератаки в 2026 году