17 октября 2026 года стало известно о взломе OpenCode Console, дополнительной облачной службы, что привело к утечке учетных данных сторонних поставщиков, хранившихся пользователями. Этот инцидент вызвал повсеместную путаницу, поскольку многие пользователи по ошибке приняли взлом за локальный OpenCode CLI из-за общего названия. Взлом затронул ключи поставщиков (например, OpenAI, Anthropic), сохраненные в рабочей области Console, а не ключи, хранящиеся локально в CLI. Пострадавшим пользователям было рекомендовано отозвать и заменить эти ключи, а также просмотреть их использование.В заявлении поставщика подтвержден несанкционированный доступ к "устаревшей системе" и содержится призыв к пользователям отозвать скомпрометированные ключи. Электронное письмо клиента OpenAI подтвердило инцидент, отметив, что их затронутый ключ уже был отключен. Отсутствие ясности в первоначальном объявлении о том, какой именно продукт был скомпрометирован, вызвало значительное разочарование.Для пользователей локального кодирующего агента учетные данные хранятся на их машине, а запросы маршрутизируются в соответствии с их конфигурацией. Это означает, что если их конфигурация указывала на локальный шлюз (например, 127.0.0.1:8787), их ключи не были раскрыты через облачную службу Console. Однако, если их конфигурация направляла на облачный шлюз поставщика, отзыв ключей был необходим.Автор провел четыре проверки: проверка аутентификации конечной точки, подсчет учетных данных на диске, сканирование на наличие дубликатов ключей и проверка ключей, зафиксированных в репозитории конфигурации. Проверка конечной точки, идентифицирующая локальную маршрутизацию, подтвердила, что ключи автора не были напрямую затронуты взломом Console. Однако локальное хранение ключей в открытом тексте по-прежнему представляет угрозу безопасности.Автор также отметил, что отозванные ключи могут по-прежнему находиться в резервных файлах, а общедоступный репозиторий конфигурационных файлов представляет риск, если учетные данные будут случайно зафиксированы. Для всех, кто использует облачную службу ключей, автор рекомендует пять шагов: определить используемый продукт, отозвать скомпрометированные ключи у поставщика, просмотреть графики использования, сканировать на наличие дубликатов ключей и, в идеале, использовать настройку, при которой агент никогда напрямую не хранит ключ. Ключевой вывод заключается в том, чтобы убрать учетные данные из прямого доступа агента, чтобы минимизировать радиус поражения в случае компрометации.