управление секретами
22 статей с этим тегом
Инцидент безопасности Fireworks AI (октябрь 2026): затронуты платёжные данные, а также часть наборов данных и весов моделей; компания связывает его со взломом облачного провайдера. Что делать клиентам
Fireworks AI, предоставляющая инфраструктуру инференса моделей ИИ, опубликовала 9 ноября 2026 года обновление об инциденте безопасности, который впервые раскрыла 9 октября. По словам компании, об изначальном инциденте, обнаруженном 6 октября, было известно лишь то, что затронуты секреты, хранящиеся в Fireworks (например, используемые в заданиях оценки); позже она выявила влияние на информацию об учётных записях и платежах, а у ограниченного набора аккаунтов ещё и на секреты, наборы данных и неполные веса моделей. По её рассказу, у стороннего облачного провайдера, на котором размещались её машины для НИОКР, 23 октября произошёл инцидент безопасности, а 24 октября неавторизованная третья сторона воспользовалась этим, чтобы добраться до машин разработки Fireworks и запустить несанкционированную нагрузку, что привело к дополнительному затрагиванию данных клиентов. Компания обнаружила это в тот же день и по состоянию на 25 октября не обнаружила новых свидетельств успешного несанкционированного доступа к платформе, которой пользуются клиенты. Она говорит, что свидетельства указывают на связь с финансово мотивированной киберпреступной группой. Номера платёжных карт компания не хранит, и они не затронуты. Влияния на Inference, Training SDK и Nexus, где по умолчанию нулевое хранение данных, не обнаружено. На время расследования самостоятельная загрузка наборов данных и их скачивание отключены. Наше мнение: клиентам стоит составить перечень того, что они хранили на платформе, и сменить это; операторам важно отделять среды разработки от систем с платёжными данными и данными клиентов.
Взлом NEAR AI через уязвимость движка инференса (данные учётных записей около 100 пользователей): что подтверждено и что делать пользователям и операторам инфраструктуры ИИ
NEAR AI, предоставляющая ИИ-чат и агентов, раскрыла несанкционированный доступ к части инфраструктуры в официальной записи блога от 9 ноября 2026 года. По словам компании, причиной стала уязвимость удалённого выполнения кода в SGLang, движке инференса с открытым кодом на её серверах: злоумышленник выполнил код на одном сервере инференса и оттуда добрался до другой инфраструктуры. Компания подтверждает следующее. Из внутренней системы за ранее выведенным из работы Private Chat похищены данные учётных записей около 100 пользователей (адреса электронной почты, имена, а для части записей сведения о тарифе и балансе). Похищены история чатов, настройки и журналы 18 устаревших агентов, которые не работали в среде конфиденциальных вычислений (TEE). Отдельно ключи API NEAR AI Cloud двух клиентов Cloud попали в журналы (отозваны; о том, что они похищены, не сказано). 8 ноября злоумышленник мог видеть пользовательские запросы, обрабатывавшиеся на скомпрометированном сервере, включая запросы в конфиденциальном режиме. Признаков доступа к сохранённым разговорам Private Chat или загруженным файлам компания не нашла. Она сообщает, что заменила учётные данные, устранила уязвимость и восстановила доступ к NEAR AI Cloud (Private Chat остаётся отключённым). В официальном отчёте номера CVE нет. Наше мнение: операторам инфраструктуры ИИ важно отделять серверы инференса от внутренних систем, не оставлять устаревшие среды и не допускать секретов в журналах.
В Ethersphere bee-js 13.3.0 и Swarm Desktop 0.56.2 попала вредоносная программа (ноябрь 2026): затронутые версии и что делать пользователям
В версии 13.3.0 npm-пакета @ethersphere/bee-js от Ethersphere, разработчика децентрализованной сети хранения Swarm, находился вредоносный код. Бюллетень GitHub (GHSA-hh7j-5m3j-23pf), опубликованный 9 ноября 2026 года, называет затронутой только версию 13.3.0 и сообщает, что исправленной версии нет. В нём сказано, что любой компьютер, на котором пакет установлен или запущен, следует считать полностью скомпрометированным, а все секреты и ключи на нём немедленно сменить с другого компьютера. Удаление пакета может не устранить всё вредоносное ПО, которое появилось при установке. Для Swarm Desktop в примечаниях к выпуску Ethersphere сказано, что версия 0.56.3, выпущенная 9 ноября, заменяет скомпрометированную 0.56.2. По анализу компании по безопасности, bee-js 13.3.0 появился в npm около 00:09 UTC 9 ноября (09:09 по японскому времени) и был удалён примерно через 75 минут. Swarm Desktop 0.56.2 был доступен около 8,5 часа, а на Windows x64 и Apple Silicon доставлялся и автообновлением. О том, что bee-js 13.2.0 и более ранние версии, а также Swarm Desktop 0.56.1 не затронуты, сообщается. Тот же анализ говорит, что целью были файл конфигурации узла Bee (в нём пароль в открытом виде) и ключ кошелька, а учётные данные, которыми пользуется официальная автоматизация выпусков, использовались злоумышленником. Наш вывод: пересоберите любую машину или среду CI, где была установлена затронутая версия, перенесите кошелёк на новый ключ и переведите средства, смените учётные данные с другой машины.
Эксплуатация уязвимости сервера MCP у mittwald: скомпрометированы 56 клиентских проектов (ноябрь 2026): опубликованная хронология и что делать пользователям и операторам интеграций ИИ
Немецкая компания веб-хостинга mittwald сообщила в официальной записи блога, что уязвимость её сервера MCP, подключающего ИИ-помощников клиентов к панели управления mStudio, была использована, и 56 клиентских проектов скомпрометированы. По словам компании, злоумышленник впервые проверил уязвимость 21 октября, с 23 октября начал действовать как обычный пользователь с тестовыми учётными записями, а 27 октября в 15:03 использовал уязвимость через другую учётную запись. Все данные начиная с 27 октября компания считает скомпрометированными. 4 ноября обнаружено необычное поведение, и в тот же день компания определила сервер MCP как точку входа и отключила его. 6 ноября она провела криминалистическое исследование 56 скомпрометированных проектов и сервера MCP, не нашла других скомпрометированных проектов и сообщает, что сейчас не обнаруживает активности злоумышленника. Пароли не считывались; считывались токены сеансов пользователей, и все они отозваны, говорит компания. Центр клиентов и управляемые в нём сайты не пострадали. Сервер MCP остаётся отключённым, вернётся ли он, решат после расследования. Компания считает, что по скорости действий злоумышленника можно подозревать использование инструментов ИИ; это подозрение компании. На следующей неделе она обещает опубликовать подробный рассказ. Наше мнение: для серверов MCP, которые подключают ИИ-помощников к хостингу или производственной среде, ключевое — узкие по правам краткоживущие токены и мониторинг, способный уловить стадию разведки.
Инцидент безопасности Trigger.dev (ноябрь 2026): корневые ключи API и переменные окружения затронуты у 0,66 % клиентов, перегенерируйте ключи и смените секреты
Trigger.dev, платформа для запуска фоновых задач и ИИ-агентов, раскрыла инцидент безопасности 1 ноября 2026 года и опубликовала дополнительный отчёт 6 ноября. Компания сообщает, что оповещения инфраструктуры 1 ноября указали на аномальную активность, она сочла её вредоносной и заблокировала злоумышленника. Инцидент затронул 0,66 % всех клиентов. Злоумышленник получил корневые ключи API для некоторых клиентских сред; корневой ключ даёт полный доступ к настройкам среды, включая её переменные окружения. В некоторых средах он также запрашивал списки последних запусков, развёртываний и расписаний, и в ответ получал идентификаторы, названия задач, ключи идемпотентности запусков, статус запусков, теги, метаданные развёртываний и ошибки, внешние идентификаторы расписаний и метаданные запусков. Компания не нашла доказательств доступа к другим данным клиентов, другим сервисам, собственным производственным базам данных или аккаунтам клиентов в панели управления. Вектор атаки она не раскрывает, чтобы защитить расследование и клиентов. Затронутым клиентам писали по электронной почте (1 и 2 ноября) и показывали баннер в панели управления (время не указано), а потенциально затронутые ключи API были отозваны. Затронутым клиентам нужно перегенерировать ключи API и сменить учётные данные в затронутых средах, например пароли баз данных и сторонние ключи API, отозвав старые у поставщика. Компания заявляет, что клиенты, не получившие уведомления о воздействии, не затронуты, секреты подписи вебхуков не раскрыты, а самостоятельно размещённые развёртывания не затронуты. Вывод этого сайта: сначала проверьте почту и баннер в панели управления, а при затронутости перегенерируйте ключи и смените учётные данные, как просит компания.
Инцидент безопасности Northflank (октябрь 2026): сохранённые переменные окружения считаются расшифрованными, сообщается о неправомерном использовании ключей API ИИ
30 октября 2026 года (UTC) облачная платформа развёртывания Northflank разместила на странице статуса сообщение об инциденте безопасности. Предупреждение об угрозе от поставщика средств безопасности поступило в 11:43 UTC; компания развернула патчи начиная с 12:02 UTC, в 13:40 UTC попросила клиентов сменить переменные окружения, а в 13:58 UTC — считать расшифрованными все переменные окружения. К 15:12 UTC на странице статуса уже было отмечено, что несколько пользователей сообщают об использовании их ключей ИИ, а в 23:38 UTC компания написала, что пользователи сообщили о несанкционированном использовании ключей API ИИ, хранящихся на платформе. 31 октября она включила журналы аудита для всех клиентов и по одному типу выпустила смену секретов для аддонов. В обновлении от 2 ноября (11:09 UTC, статус Monitoring) компания сообщила, что, по её оценке, остановила атаку в течение часа после первого предупреждения, что работающие нагрузки не затронуты и признаков доступа к нагрузкам или их данным она не видела, а атака, судя по всему, была направлена на секреты в плоскости управления. Независимые судебные аудиторы проводят проверку, компания отозвала токены доступа, сессии, интеграции с VCS и межаккаунтные роли IAM (поэтому пользователям нужно войти снова и заново подключить интеграции) и пообещала опубликовать анализ первопричины, когда выводы будут подтверждены. В обновлении от 6 ноября (10:09 UTC) компания сообщила, что первая известная расшифровка секретов произошла между 02:39 и 03:08 UTC 30 октября, до первого предупреждения в 11:43 UTC; что эксплойт был закрыт в течение 60 минут после уведомления, а клиентов уведомили в течение двух часов; что доказательств доступа к рабочим нагрузкам клиентов или их данным она не нашла; и что она работала с вышестоящими поставщиками, чтобы по возможности отозвать учётные данные. Судебная проверка продолжается. Число затронутых клиентов, способ проникновения злоумышленника и то, какие поставщики ИИ были затронуты, не раскрыты. Вывод этого сайта: отзовите все секреты, которые вы хранили в Northflank, у сервиса, который их выдал, затем проверьте использование и счета каждого поставщика ИИ и установите лимиты расходов.
Взлом OpenCode Console (октябрь 2026, 1,4% пользователей Console): возможно раскрыты API-ключи поставщиков ИИ, и что делать
17 октября 2026 года OpenCode, ИИ-агент для написания кода с открытым исходным кодом, сообщил в своём официальном аккаунте в X, что прошлой ночью произошёл взлом, связанный с масштабной атакой дистилляции, который затронул 1,4% пользователей OpenCode Console. По словам компании, утром она отправила письма всем затронутым пользователям, те, кто письма не получил, не затронуты, а затронутые пользователи — это часть тех, у кого были подключены внешние поставщики. Компания сообщила, что инцидент продолжается, что она не может поделиться подробностями и что работает с соответствующими поставщиками ИИ. Согласно сообщениям СМИ о письме и заявлениях компании, API-ключи внешних поставщиков ИИ, которые пользователи хранили в рабочих пространствах Console, могли быть раскрыты через более старую систему, и затронутым пользователям было сказано отозвать и заменить эти ключи напрямую у каждого поставщика. Сооснователь заявил, что приложение с открытым исходным кодом и инструмент командной строки не затронуты. Мнение этого сайта: если вы получили письмо или у вас были подключены ключи поставщиков ИИ в OpenCode Console и вы не уверены, отзовите их сегодня в панели управления каждого поставщика и проверьте использование и счета начиная с 17 октября.
Инцидент безопасности Zeabur (октябрь 2026, прочитано 3,22 млн переменных окружения): какие секреты заменить и что делать пользователям
19 октября 2026 года платформа для развёртывания приложений Zeabur опубликовала предварительный отчёт об инциденте безопасности 14–15 октября (UTC). По словам компании, атакующий с помощью утёкших внутренних учётных данных Zeabur проник в общий кластер, часть выделенных серверов (Dedicated Servers) и внутренние системы, а затем, с 16:10 до 16:47 UTC 15 октября, прочитал базу данных платформы. Компания подтвердила, что прочитаны 3 218 965 записей переменных окружения (имена и значения) и данные 321 810 аккаунтов (электронная почта, имя пользователя, номер телефона и другое), а также 566 API-ключей zSend, которые она отозвала. Компания заявляет, что первопричина лежит на Zeabur: долгоживущие административные учётные данные хранились в открытом виде и могли использоваться из публичного интернета. Она просит всех пользователей заменить все пароли и ключи, хранящиеся в Zeabur, даже если они уже заменили их после отдельного инцидента в августе. 17 октября Zeabur объявила, что прекратит работу 31 декабря 2026 года, а 22 октября установила 30 ноября 2026 года крайним сроком подачи требований о возмещении убытков от инцидента. Мнение этого сайта: считайте, что каждый секрет, который вы когда-либо помещали в переменную окружения Zeabur, известен кому-то ещё, сначала отзовите его у выпустившего сервиса и проверьте счета и журналы начиная с 14 октября.
Возможная утечка переменных окружения Railway (октябрь 2026, до 1,85% рабочих пространств): какие секреты заменить и что делать пользователям
21 октября 2026 года (UTC) Railway сообщила, что обнаружила аномальную активность в системах, где хранятся переменные окружения клиентов, и что неавторизованная третья сторона могла получить доступ к зашифрованным переменным окружения и для части из них получить расшифрованное содержимое. Согласно предварительному отчёту от 22 октября (по данным страницы статуса, опубликован в 16:38 UTC 23 октября), атака длилась с 13:58 UTC 20 октября до 03:32 UTC 22 октября. Она началась с попыток повышения привилегий в инфраструктуре сборки; 21 октября были использованы учётные данные среды CI, и часть зашифрованных переменных окружения была расшифрована. Не более 1,85% всех рабочих пространств (около 100 000 рабочих пространств, по данным компании) имели переменные окружения, часть из которых могла быть скомпрометирована. Компания заявляет, что к учётным записям пользователей Railway доступа не было, и до выхода итогового отчёта не исключает доступ к исходному коду. По-видимому, атакующий искал API-ключи поставщиков ИИ. Railway рекомендует всем пользователям заменить секреты, сохранённые до 21 октября, закрыть публичный сетевой доступ к базам данных и проверить журналы аудита GitHub и реестров (например, Docker Hub). Вывод сайта: даже если с вами не связывались, считайте секреты, хранившиеся на Railway, раскрытыми, перевыпустите их у источника и выполните повторное развёртывание до отзыва старых значений.
В LiteLLM 1.107.0 оказался похититель учётных данных (октябрь 2026): затронутый релиз PyPI и образы Docker, что делать пользователям
21 октября 2026 года (UTC) BerriAI, компания-разработчик LiteLLM, сообщила, что её конвейер выпуска релизов был скомпрометирован и что был опубликован v1.107.0 с вредоносным ПО, которое похищает учётные данные и загружает инструменты удалённого выполнения кода. Затронуты litellm==1.107.0 на PyPI (с 11:39 до 13:23 UTC) и теги v1.107.0, latest, main-latest и main-stable на Docker Hub (с 11:46 до 14:20 UTC) и GHCR (с 11:46 UTC до снятия к 13:51 UTC, около двух часов). Официальный исходный тег v1.107.0 на GitHub не содержит вредоносных файлов; артефакты были собраны из похожего репозитория, контролируемого злоумышленником. Все более ранние версии вне этой компрометации, компания просит закрепить версию 1.106.2 или другую явную более раннюю версию. 24 октября (UTC) компания опубликовала 1.103.8, 1.104.6, 1.105.4 и 1.106.3; начиная с этих релизов образы Docker и Helm-чарты подписываются новым ключом cosign (прежний ключ их больше не проверяет). 23 октября компания опубликовала анализ первопричины и исправила своё первоначальное предположение о том, что токены были взяты из логов внутреннего развёртывания LiteLLM. Согласно анализу, файл конфигурации, ошибочно закоммиченный в публичный репозиторий 27 мая, содержал мастер-ключ внутренней платформы агентов; коммит перезаписали, но ключ не отозвали. 10 октября злоумышленник использовал этот ключ для вызова API платформы и получил токен GitHub CLI владельца организации GitHub, настроенный там. С его помощью злоумышленник вывел секреты CI и получил токены ещё двух мейнтейнеров, а 21 октября отключил защиту веток, изменил рабочий процесс выпуска и одобрил релиз. Вывод этого сайта: пересоберите любую среду, где 1.107.0 был установлен или запущен в течение окна, и замените все ключи, до которых она могла дотянуться, включая ключи провайдеров LLM, мастер-ключ прокси, пароль базы данных и облачные роли.
543 699 учётных данных, опубликованных на GitHub, всё ещё работали (исследование 2026 года): почему нужно отзывать, а не удалять, и что делать разработчикам
Компания по безопасности, продающая инструменты поиска секретов, изучила снимок примерно 224 миллионов публичных репозиториев, собранный для обучения LLM, и сообщила, что в конце июля 2026 года 543 699 учётных данных всё ещё проходили аутентификацию. Медианное время с момента раскрытия — 784 дня. Почти все токены npm и GitHub были аннулированы, тогда как 75–88% строк подключения к базам данных всё ещё работали. Более 199 000 действующих учётных данных появились уже после того, как GitHub включил push protection по умолчанию, и больше половины действующих относились к типам, которые push protection по умолчанию не блокирует. Вывод этого сайта: учётные данные, отправленные в публичный репозиторий, нельзя вернуть удалением файла или переписыванием истории, поэтому сначала их нужно отозвать. Отзываются ли утёкшие учётные данные автоматически, зависит от выпустившего их сервиса; строки подключения и многие API-ключи действуют, пока вы сами их не остановите.
Цепочка компрометаций TanStack, Nx Console и GitHub (май 2026): что проверить разработчикам
11 мая 2026 года пайплайн публикации репозитория Router/Start проекта TanStack был использован, чтобы выпустить код для кражи учётных данных в 42 пакетах npm, 84 версиях. У участника Nx, установившего один из них, украли токен GitHub CLI, и 18 мая было опубликовано подменённое расширение Nx Console (v18.95.0). В тот же день GitHub сообщил, что устройство сотрудника было скомпрометировано через заражённое расширение VS Code и что внутренние репозитории GitHub были выведены наружу. Во всех трёх случаях атака шла через легитимные аккаунты и каналы распространения, поэтому защита в том, чтобы одного украденного токена публикации не хватало для выпуска новой версии, и в том, чтобы проверить, что настроенные меры защиты действительно срабатывают.
Компрометация цепочки поставок Trivy (март 2026): что делать, если Trivy работает у вас в CI
19 марта 2026 года вышла вредоносная версия v0.69.4 сканера уязвимостей с открытым кодом Trivy, который разрабатывает Aqua Security, а теги GitHub Actions trivy-action (76 из 77) и setup-trivy (все 7) были перенаправлены на вредоносные коммиты. По словам Aqua, вредоносный код собирал секреты с раннеров CI и отправлял их наружу; причиной стали учётные данные, полученные при взломе, начавшемся в конце февраля: атакующий смог и дальше ими пользоваться, потому что ротацию 1 марта провели не одновременно. Взгляд этого сайта: урок не только в том, чтобы закреплять actions по ID коммита (SHA), а не по тегу. Action, закреплённый по SHA, всё равно может вызывать другой компонент по тегу, и через это проходит вредоносная версия. Утёкшие учётные данные нужно заменять все сразу, иначе атакующий продолжит ими пользоваться. Запускайте сканеры в заданиях, у которых нет секретов для развёртывания.
Черви в цепочке поставок npm: как учётные данные крадут при установке пакета и как защититься
Добавить зависимость — значит запустить чужой код с вашими правами, поэтому защищаться нужно в момент установки. Взгляд этого сайта: подписи и provenance эту кампанию не остановили, значит, на них нельзя строить доверие. Помогает другое: отключить скрипты установки по умолчанию, выжидать несколько дней перед переходом на новый релиз и делать токены короткоживущими и узкими по правам. Если есть подозрение на заражение, важен порядок отзыва.
Останавливайте секреты до коммита с gitleaks: ловите утечки API-ключей до push
Секреты нельзя «удалить после утечки». Раз закоммиченный, секрет остаётся в истории Git, а раз запушенный — его надо считать утёкшим: ключ нужно отозвать/сменить. gitleaks — бесплатный инструмент, сканирующий весь репозиторий и историю коммитов по regex/энтропии, чтобы найти API-ключи, приватные ключи и токены. Ядро защиты — две проверки: хук pre-commit, останавливающий локально до push, и CI/cron, ловящий то, что просочилось. .gitignore лишь предотвращает новое отслеживание — он не умеет обнаруживать, так что сканер всё равно нужен.
Безопасны ли менеджеры паролей? Как они работают, облако vs локально и как выбрать
Менеджер паролей помогает использовать отдельный надёжный пароль для каждого сервиса. Шифрование с нулевым разглашением призвано защищать содержимое даже при утечке зашифрованных данных у провайдера, но безопасность также зависит от силы мастер-пароля, настроек шифрования и защиты устройства. Используйте MFA против несанкционированного входа, а облачный или локальный вариант выбирайте по применению.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, тот же файл лежит на каждом сайте. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Базовая безопасность для инди-разработчиков и малых операторов: стандартные меры в порядке приоритета
База — это не «всё одинаково важно». Порядок приоритета этого сайта: 1) админ-аккаунты, домен и почта (MFA), 2) секреты и код, 3) само приложение, 4) патчи, обнаружение, восстановление. При конечном времени заполняйте сверху вниз. Большинство серьёзных взломов происходит не из-за новых атак, а из-за пробела в этих базовых мерах.
Инвентаризация безопасности: 7 проверок, которые упускают владельцы нескольких серверов
Для одиночек/малых операторов инциденты происходят не столько из отсутствующих мер, сколько из неотслеживаемого состояния. Граница — это ПК, хранящий ваши ключи. Расставьте приоритеты 2FA по тому, какой аккаунт может восстановить остальные (сначала почта), составьте список, какой SSH-ключ открывает какой сервер, и удалите дубликаты, неиспользуемые ключи и оставшиеся регистрации, уберите пароли открытым текстом из облака, устраняйте обратимо по одному и держите секреты вне реестра. Инвентаризация прежде добавления инструментов.
Самохостинг Git vs GitHub: что на самом деле безопаснее?
Самохостинг Git не делает вас «безопаснее» — он перемещает риск. Класс случайной публичной выставленности исчезает, но патчинг сервера, резервные копии и обнаружение секретов в pre-commit переходят на вас. Правильный выбор, если вы продолжаете выполнять эту работу; хуже GitHub, если её забрасываете. Взгляд этого сайта: самохостинг работает только в связке с компенсирующими мерами.
Безопасно ли хранить пароли в Google Drive? Как держать их правильно
Держать пароли в документе/таблице Google открытым текстом опасно: один аккаунт Google становится единой точкой отказа для каждого пароля — захват аккаунта, вредоносное подключённое приложение или фишинг утекают их все разом. Самый безопасный вариант — специализированный менеджер паролей (содержимое остаётся зашифрованным даже при синхронизации). Если вы обязаны использовать Drive, храните только зашифрованный файл хранилища и поставьте устойчивую к фишингу MFA на аккаунт.
Утечка Codecov (2021) — когда инструмент CI был изменён и утекли секреты
Доверенный инструмент CI (Bash Uploader на curl|bash) был изменён на стороне поставщика. Поскольку ваш собственный код не трогали, это оставалось незамеченным ~2 месяца, пока утекали секреты CI; поймала это проверка контрольной суммы. В вашем CI: проверяйте загружаемые артефакты, минимальные привилегии секретов, ротация, мониторинг исходящего трафика.