OpenAI заявила, что два устройства сотрудников были скомпрометированы во время недавней supply-chain кампании, связанной с TanStack, которая затронула сотни npm и PyPI packages. Компания сообщила, что обнаружила активность, направленную на credentials, в ограниченном наборе внутренних source code repositories, но не нашла доказательств того, что были затронуты customer data, production systems, intellectual property или deployed software.
Важно не то, что OpenAI была единственной целью. Это не так. Инцидент является частью более широкой кампании «Mini Shai-Hulud», которую в отчете связывают с extortion gang TeamPCP. Кампания использовала доверенные package ecosystems и CI/CD пути, чтобы добраться до разработчиков, украсть credentials и публиковать malicious package versions через каналы релизов, выглядящие как обычные.
Что, по словам OpenAI, произошло#
Согласно отчету BleepingComputer, OpenAI опубликовала security advisory, в котором сообщила, что два устройства сотрудников были скомпрометированы в рамках активности, связанной с кампанией Mini Shai-Hulud.
OpenAI заявила, что наблюдала поведение, соответствующее публичным описаниям malware. Оно включало unauthorized access и credential-focused exfiltration activity в ограниченном наборе внутренних source code repositories, доступных пострадавшим сотрудникам.
Компания сообщила, что из этих repositories были украдены только ограниченные credentials. Также OpenAI заявила, что у нее нет доказательств использования этих credentials в последующих атаках.
Заявленная реакция OpenAI включала изоляцию затронутых systems и accounts, отзыв sessions, rotation credentials во всех затронутых repositories, а также временное ограничение deployment workflows. Компания также привлекла стороннюю incident response firm для forensic investigation.
Такой шаблон реагирования важен. В кампаниях такого типа первая скомпрометированная машина часто не является конечной целью. Developer laptops, GitHub tokens, npm tokens, CI secrets, cloud keys, SSH keys и environment files — все это stepping stones. Атакующий ищет пути, которые позволяют переходить от одной доверенной identity к другой.
Почему code-signing certificates стали проблемой, заметной пользователям#
OpenAI также сообщила, что в ходе инцидента были раскрыты code-signing certificates, используемые для ее продуктов на macOS, Windows, iOS и Android.
Компания заявила, что не обнаружила злоупотреблений этими certificates для подписи malicious software. Тем не менее OpenAI выполняет их rotation в качестве меры предосторожности.
У этой меры есть конкретное последствие для пользователей macOS. BleepingComputer сообщает, что пользователям macOS нужно обновить desktop applications OpenAI до 12 июня 2026 года. После этой даты приложения, подписанные старыми certificates, могут перестать запускаться или получать обновления из-за Apple notarization process.
Согласно отчету, пользователям Windows и iOS никаких действий предпринимать не требуется.
Это важное различие. Раскрытие certificate — не то же самое, что подтвержденная malicious signing. Но раскрытый signing material меняет trust model. Даже если известных злоупотреблений нет, безопасный шаг — вывести старые certificates из использования и перевести клиентов на builds, подписанные новым trust material.
Для пользователей практический вывод простой: если вы используете desktop apps OpenAI на macOS, обновите их до указанного срока. Не скачивайте replacement installers со случайных mirrors или из search ads. Используйте официальный путь обновления приложения или официальные download channels OpenAI.
Supply-chain атака на TanStack, стоящая за этим инцидентом#
Инцидент OpenAI связан с более широкой компрометацией open-source package infrastructure. Сообщается, что кампания сначала нацелилась на packages TanStack и Mistral AI, а затем распространилась на другие проекты, включая UiPath, Guardrails AI и OpenSearch.
В итоге кампания затронула сотни npm и PyPI packages, распространявшихся через legitimate repositories.
Механика атаки — главный урок. Согласно post-mortem TanStack в пересказе BleepingComputer, атакующие использовали слабости в GitHub Actions workflows и CI/CD configuration. Это позволило им выполнить malicious code, извлечь tokens из памяти и опубликовать malicious packages через обычный release pipeline TanStack.
Именно последний пункт делает supply-chain атаки сложными для обнаружения. Malicious package version может прийти через тот же registry, тот же maintainer namespace и ту же release automation, которым пользователи уже доверяют. Снаружи это может не выглядеть как очевидная подделка. Это может выглядеть как обычное обновление.
Сообщается, что malware Mini Shai-Hulud нацеливался на developer и cloud credentials, включая GitHub tokens, npm publish tokens, AWS credentials, Kubernetes secrets, SSH keys и .env files.
Исследователи также сообщили, что malware пытался закрепиться на developer systems, изменяя Claude Code hooks и VS Code auto-run tasks. Это позволяло ему сохраняться даже после удаления malicious package.
Затем кампания распространялась, используя украденные GitHub и npm credentials для компрометации maintainer accounts и внедрения payloads в packages, которые уже имели доверие downstream users.
Практический вывод для security и engineering teams#
Главный вывод из этого инцидента: нельзя считать release pipeline безопасным только потому, что он принадлежит легитимному проекту, maintainer account выглядит настоящим, а package пришел из официального registry.
Командам стоит проверить три зоны риска прямо сейчас.
Первая зона — developer endpoints. Если рабочая станция разработчика имеет доступ к source code, package publishing, cloud consoles или CI secrets, она должна рассматриваться как часть production attack surface. Нужны EDR/MDM coverage, быстрый revoke sessions, контроль persistence mechanisms, проверка IDE hooks, shell profiles, auto-run tasks и локальных credential stores.
Вторая зона — CI/CD permissions. GitHub Actions и похожие системы не должны иметь broad default tokens там, где достаточно read-only доступа. Publish jobs должны быть отделены от test jobs, secrets должны выдаваться только в минимально необходимом scope, а release workflows должны требовать дополнительного контроля для публикации в npm, PyPI, container registries и artifact repositories.
Третья зона — package intake. Организации, которые автоматически подтягивают latest versions, должны пересмотреть эту практику. Более безопасный подход включает lockfiles, dependency pinning, provenance checks, allowlists для critical packages, задержку auto-upgrades для high-risk dependencies и мониторинг неожиданного появления postinstall scripts, new maintainers, changed publish patterns или unusual network behavior during builds.
Минимальный набор действий после такой новости: найти использование затронутых packages и версий, пересобрать environments из чистых sources, проверить CI logs на неожиданные network calls и secret access, отозвать потенциально раскрытые developer tokens, пересоздать npm/PyPI/GitHub/cloud credentials и проверить repositories на suspicious workflow changes.
Для пользователей OpenAI на macOS действие конкретное: обновить desktop app через официальный канал до 12 июня 2026 года. Для организаций действие шире: провести ревизию того, какие developer credentials могут публиковать packages, запускать deployments или менять build workflows без дополнительного approval.
Этот инцидент не показывает, что open-source registries больше нельзя использовать. Он показывает, что доверие к registry, maintainer namespace и CI pipeline должно быть проверяемым, ограниченным и отзывным. В supply-chain атаках злоумышленник выигрывает не тогда, когда ломает cryptography, а когда получает доступ к уже доверенному пути доставки software.