Что произошло в OpenCode Console и кого затронуло
В ночь на 16 октября неизвестный получил несанкционированный доступ к устаревшей системе OpenCode Console, онлайн-платформы, которую компания выводила из эксплуатации. Затронуты 1,4% пользователей Console: те, кто подключил внешнего провайдера и вставил свой API-ключ в веб-панель. Открытый исходный код OpenCode и CLI-инструмент не пострадали.
Утром 17 октября OpenCode разослала письмо с темой «Action Required: Potential provider key breach» и попросила получателей отозвать ключи у каждого провайдера и выпустить новые. Компания заявила, что уведомила всех затронутых по электронной почте, а те, кому письмо не пришло, в список не попали. Формулировка в официальном сообщении осторожная: ключи «могли быть раскрыты». Что какие-то ключи скопировали или использовали, OpenCode не подтверждала.
OpenCode это открытый AI-агент для программирования, который продвигают как альтернативу Claude Code и Cursor. Инцидент ударил по хостинговой надстройке, а не по самому агенту. Это различие определяет, кому сейчас нужно бежать менять ключи, а кому достаточно проверить биллинг.
Хронология: ночь 16 октября, письма 17 октября
- Ночь на 16 октября: посторонний получает доступ к устаревшей системе OpenCode Console, которую выводили из эксплуатации.
- 16-17 октября: у части пользователей срабатывают алерты по расходам в OpenAI, Anthropic и Google. Параллельно появляются жалобы на ошибку «Unable to start social login» при входе через Google или GitHub и на истёкшие API-ключи.
- Утро 17 октября: рассылка «Action Required: Potential provider key breach» с просьбой отозвать и заменить ключи у каждого провайдера.
- 17 октября, позже: публичное заявление OpenCode. Инцидент назван связанным с «крупномасштабной distillation-атакой», затронуто 1,4% пользователей Console, компания работает с Anthropic, OpenAI и Google и называет ситуацию продолжающейся.
OpenCode не раскрыла, что представляла собой устаревшая система, как к ней получили доступ, сколько ключей в ней хранилось и сколько человек стоит за 1,4%. Виновные не названы. Сам факт, что систему выводили из эксплуатации, объясняет её состояние, но не оправдывает: в ней лежали рабочие секреты, и доступ к ним нужно было закрыть до отключения.
Атака шла не одну ночь. По словам компании, злоумышленники непрерывно пытались взломать её системы в течение 48 часов, и команде пришлось держать AI-защитных агентов включёнными круглосуточно.
Кто в группе риска: 1,4% пользователей Console
Критерий простой: ключ должен был лежать в веб-панели Console. Речь о пользователях, которые привязали внешнего провайдера (OpenAI, Anthropic, Google) и вставили его ключ в интерфейс.
- Потенциально затронуты: те, кто вставлял ключи провайдеров в OpenCode Console.
- Не затронуты: те, кто хранил ключи только локально, в CLI или десктопном приложении.
- Сигнал: письмо от 17 октября. По заявлению компании, его отсутствие означает, что пользователь не в списке.
1,4% это доля от пользователей Console, а не от всей аудитории OpenCode. Сколько это в абсолютных числах, компания не сообщила.
Если письма нет, но ключ когда-то вставлялся в Console, дешевле ротировать его, чем проверять предположения. Выпуск нового ключа занимает пару минут, разбор чужого счёта занимает недели.
CLI и открытый код OpenCode не пострадали: что это значит на практике
Сооснователь OpenCode Dax Raad в ответе на X подчеркнул, что взлом касается «OpenCode Console, а не OpenCode как такового», и что ключи, добавленные в CLI и десктопном приложении, «никогда не попадают к нам». Открытое приложение и командная строка не затронуты.
Console vs CLI: где хранятся ключи и почему это критично
Разница архитектурная, и она определяет модель угроз. В Console ключ лежит на сервере: один взлом сервера открывает секреты сразу у группы пользователей. В CLI и десктопе ключ остаётся на машине пользователя, и сервер OpenCode его не видит.
API-ключ провайдера работает как bearer-креденшл: любой, у кого есть копия, может гонять платные запросы к чужому аккаунту, пока провайдер не отзовёт ключ. Два следствия, которые часто упускают:
- Удаление ключа из Console не отзывает его. Отзыв делает только панель провайдера.
- Бюджет, выставленный в Console, не ограничит такой расход: Console видит только запросы, проходящие через её инфраструктуру.
Для чувствительных проектов разумная схема: локальное хранение ключей плюс отдельный ключ под каждый инструмент. Локальное хранение не делает вас неуязвимым, оно переносит риск на вашу машину. Компрометация ноутбука, вредоносный плагин в редакторе или ключ, случайно попавший в лог сборки, дают тот же результат, что и взлом чужого сервера, только без публичного письма с извинениями.
Списания у пострадавших: реальные суммы и реакция провайдеров
Первые сигналы пришли от самих пользователей: у людей одновременно сработали алерты по расходам в OpenAI, Anthropic и Google. Дальше пошли конкретные цифры в публичных сообщениях.
| Кто сообщил | Провайдер | Сумма |
|---|---|---|
| Colin Parsons | OpenAI | $281 |
| Colin Parsons | Anthropic | $168 |
| Preston Zeller | по его оценке, суммарно | $1700 |
| Пользователь Reddit | Anthropic | $400 |
| Пользователь Reddit | около €200, проект приостановлен |
Часть пострадавших писала о сотнях долларов, у некоторых суммы перевалили за $1000. Эти цифры взяты из публичных сообщений пользователей, а не из официальной статистики OpenCode или провайдеров.
Реакция провайдеров:
- Anthropic и Google заблокировали ключи, которые считали скомпрометированными.
- OpenAI заявила, что вместе с OpenCode восстановила доступ и вернула API-клиентам кредиты, потраченные в ходе атаки.
- OpenCode сообщила, что возвраты за несанкционированные списания уже идут.
Что делать, если ключ утёк: пошаговый план
- Отозвать ключ в панели провайдера (OpenAI, Anthropic, Google) и выпустить новый. Не удалять из Console, а именно отозвать у провайдера.
- Проверить биллинг и usage-логи минимум с 16 октября, включая запросы, которых вы не делали.
- Зафиксировать аномалии: скриншоты счетов, идентификаторы запросов, время. Это понадобится для тикета и компенсации.
- Написать в поддержку провайдера и в OpenCode, приложив эти данные. Возвраты по инциденту уже идут.
- Выставить жёсткий лимит расходов и алерт на непривычный объём токенов.
- Обновить ключ везде, где он использовался: скрипты, CI, локальные конфиги, сторонние сервисы и плагины.
Скорость отзыва напрямую определяет итоговую сумму. Каждый час жизни скомпрометированного ключа это оплаченные вами запросы чужого человека.
«Крупномасштабная distillation-атака»: что это и почему формулировка спорная
В заявлении OpenCode инцидент описан так: «security breach last night related to a large-scale distillation attack that impacted 1.4% of OpenCode Console users». Как именно взлом связан с дистилляцией, компания не объяснила, детали устаревшей системы не раскрыла.
Дистилляция без хайпа: как это работает и при чём тут украденные ключи
Дистилляция это термин провайдеров для кампаний, которые массово вытягивают ответы сильной модели, чтобы обучить на них конкурирующую. Механика простая: нужен доступ к модели и деньги на оплату запросов. Украденный ключ даёт второе без первого: запросы идут за счёт владельца аккаунта.
Связь между утечкой ключей и дистилляцией в теории есть. Anthropic в сентябре описывала, что лаборатории, стоящие за такими кампаниями, добираются до моделей через сети фейковых аккаунтов, созданных на украденных картах и учётных данных. Украденные ключи при этом ещё и перепродают на криминальных рынках, в том числе чтобы накручивать чужие счета. Отдельный мотив: ключи дают возможность генерировать большие объёмы вывода пользователям из стран с ограниченным доступом к американским моделям.
Всё это объясняет, почему кража ключей и дистилляция иногда пересекаются. Но не доказывает, что в этом конкретном инциденте было именно так.
Скептики называют формулировку натянутой: произошло прямое проникновение в систему, а использование украденных ключей для дистилляции не подтверждено. Заметим, что сама OpenCode говорит о ключах в модальности «могли быть раскрыты» и не заявляет, что их копировали. Ярлык атаки в таких историях часто становится частью коммуникации, и это отдельная тема: как риторика вокруг инцидентов с AI подменяет разбор фактов.
Практический вывод: «distillation-атака» здесь это версия компании, а не установленный факт. Для ваших действий разницы почти нет, ключи всё равно нужно ротировать, но в пересказе не стоит подавать эту версию как доказанную.
Почему защитные AI-модели отказывались анализировать атаку
Пока атакующие двое суток долбили системы, команда пыталась разбирать атаку с помощью AI. Модели какое-то время помогали, а потом начали отказываться: вредоносный код, который им показывали, активировал safety-фильтры. То есть инструмент, который должен ускорять реакцию на инцидент, выключался ровно на том фрагменте, ради которого его позвали.
Ситуация не уникальная. В июле Hugging Face сообщала, что коммерческие модели блокировали её попытки разобрать логи вторжения автономных AI-агентов. Детали того кейса и что из него вынесли защитники разобраны в материале про автономного агента, взломавшего Hugging Face.
Проблема асимметрии guardrails: защитник и атакующий выглядят одинаково
Формулировка Hugging Face: фильтры не отличают специалиста по инцидентам от атакующего. Классификатор смотрит на текст запроса, а не на контекст автора, его роль, историю обращений и цель. Шелл-код, эксплуатационный payload, разбор фишингового письма или лог с подозрительными командами выглядят для фильтра одинаково подозрительно, независимо от того, кто их прислал.
Отсюда ложные отказы в самый неподходящий момент. Из этого не следует, что guardrails не нужны: без них модель охотно поможет собрать рабочий эксплойт. Речь о том, что бинарная логика «отказать на всякий случай» бьёт по защитникам сильнее, чем по атакующим, которым достаточно найти модель без фильтров или запустить её локально.
OpenAI Daybreak Blue и локальные модели как обходной путь
OpenCode получила доступ к программе OpenAI Daybreak Blue: она даёт проверенным пользователям модели, менее склонные отказывать в запросах на защитную безопасность. По словам Dax Raad, доступ улучшил расследование.
Схема рабочая, но у неё есть цена: верификация создаёт неравенство доступа. Крупная компания с публичным инцидентом получает верифицированный канал, небольшой разработчик или независимый исследователь остаётся с фильтрами и отказами.
Второй путь это открытые модели с локальным запуском. Вы контролируете системный промпт и политики, внешних отказов нет, данные не покидают машину. Ограничения тоже реальные: требования к железу, отсутствие «страховки» от собственных ошибок и ответственность за безопасность на вас. Локальная модель не «безопаснее», у неё другая модель рисков.
Оценка без иллюзий: фильтры нужны, но текущий формат отказов вредит защитникам. Программы доступа для проверенных пользователей это компромисс, а не решение проблемы асимметрии.
Практические выводы: как защитить свои API-ключи и не попасть в следующий инцидент
Инцидент с Console сводится к одной мысли: секрет, лежащий на чужом сервере, зависит от чужой гигиены безопасности. Секрет, лежащий у вас, зависит от вашей. Вторая модель обычно управляемее.
Мини-чек-лист безопасности API-ключей для AI-агентов
- Отдельный ключ на каждый инструмент и проект. Один ключ на всё превращает любую утечку в тотальную ротацию.
- Лимит расходов и алерт у провайдера. Порог в несколько долларов на тестовом ключе ловит аномалию за часы, а не за неделю.
- Ротация по графику и сразу после инцидентов. Даже если вас не было в списке затронутых, ротация дешевле разбора.
- Локальное хранение там, где возможно. Ключ в CLI или десктопе не уезжает на чужой сервер; ключ в веб-панели уезжает.
- Проверка usage-логов раз в неделю. Смотрите не только на сумму, но и на профиль запросов: чужие модели, непривычные объёмы, ночные всплески.
- Готовый сценарий отзыва за минуты. Заранее знать, где лежат все копии ключа и в какие конфиги он вписан.
Ограничения этого списка стоит признать честно. Лимиты и алерты снижают ущерб, но не предотвращают утечку. Локальное хранение переносит риск на вашу машину. Ротация без учёта всех копий ключа оставляет старый секрет живым в забытом скрипте.
И последнее, что стоит вынести из истории с отказами моделей. Для чувствительных разборов (инциденты, вредоносный код, логи атак) инструмент выбирают до того, как он понадобился: верифицированная программа доступа либо локальная модель с настроенной политикой. Общий подход к безопасности AI-систем и типичные провалы в изоляции агентов разобраны в материале про потерю контроля над AI-моделями и уроки безопасности.
Начните с двух действий сегодня: отзовите ключ в панели провайдера, если он когда-либо вставлялся в стороннюю веб-панель, и выставьте лимит расходов на новый.