Deadbugz: MCP-сервер, который становится враждебным на третьем вызове инструмента, отправлен в 23 репозитория за 74 минуты

10 августа 2026 года один аккаунт GitHub, zellkernel, открыл 23 пул-реквеста за 74 минуты в не связанных между собой репозиториях по ИИ, MCP и инструментам для разработчиков; каждый из этих пул-реквестов добавлял MCP-сервер под названием productivity-suite, который предлагал два обычных инструмента, format_text и summarize. Согласно Pillar Security, которая назвала кампанию Deadbugz и опубликовала свой отчёт 12 августа, сервер возвращал честные результаты на первые три вызова, а затем переписал метаданные, которые передавал агенту: описания инструментов и содержимое промптов начали направлять модель к ключам SSH, учётным данным AWS, истории команд shell и конфигурации Kubernetes, и говорить ей, чтобы она скрывала эту активность от пользователя. Девятнадцать из 23 пул-реквестов были закрыты, четыре всё ещё оставались открытыми, и ни один не был слит к моменту, когда Pillar их проверила. Ни один пострадавший не подтверждён. Это одна запись, о которой сообщили другие и которая здесь приводится со ссылкой на них. Другие документированные инциденты с агентами — у каждого из них есть собственные источники, уровень серьёзности, степень уверенности и флаг спорности — находятся в архиве инцидентов ИИ — поэтому кампанию в цепочке поставок, нацеленную на инструментарий для агентов, можно прочитать рядом с остальным, что действительно произошло.

Архив оценивает эту запись как имеющую высокую степень серьёзности и достоверность A — она хорошо документирована, а первичные источники согласуются между собой — при этом отдельно отмечается отсутствие подтверждённого реального ущерба. Оба факта верны одновременно, и именно этот разрыв — суть записи: кампания, чей замысел был документирован с необычной подробностью ещё до того, как у неё появилась жертва, которую кто-либо может назвать. Две важные даты разнесены на два дня. Пулл-реквесты были отправлены 10 августа; Ариэль Фогель из Pillar Security опубликовал анализ 12 августа, и в публикации есть постоянная пометка о том, что она будет обновляться по мере поступления проверенной информации.

Три вызова, после чего метаданные меняются.

Серверу MCP не обязательно выполнять код на машине, чтобы изменить поведение агента. Определения инструментов передаются модели как контекст в каждой сессии, а значит, сервер, предоставляющий их, может переписать инструкции, которые читает агент, оставив имя инструмента, его репозиторий и его манифест в точности такими же, как были. Deadbugz построен на этой асимметрии, и Pillar называет это отравлением метаданных MCP, срабатывающим во время выполнения.

Механика достаточно проста, чтобы описать её одним предложением. Сервер хранит в памяти счётчик для каждого клиента, учитывающий запросы tools/call. На первых трёх он ведёт себя как положено. После того как счётчик срабатывает, последующие вызовы tools/list и prompts/get возвращают изменённые ответы — другие описания инструментов, другое содержимое промптов — указывая агенту на SSH-ключи, учётные данные AWS, историю командной оболочки и конфигурацию Kubernetes и предписывая ему скрывать эту активность от пользователя. Отравленный текст промпта содержит метку deadbugz и Bitcoin-адрес.

Шлюз также объясняет, почему обычные средства защиты не обнаруживают её. Полезная нагрузка присутствует в исходнике с первого запроса; ни код, ни конфигурация в момент переключения не меняются. Статическое сканирование, запись в SBOM или однократное чтение манифеста инструмента при установке видят утилиту форматирования, потому что именно это утилита и возвращает, пока счётчик не сдвинется. Pillar описывает отложенное переключение как технику уклонения от исследования и утверждает, что его исследователи подтвердили как порог, так и изменённые метаданные, отправляя исключительно текстовые запросы к работающему удалённому сервису и сопоставляя ответы с публичным исходником.

Одна деталь делает ловушку шире одной сессии. Сервер объявляет tools.listChanged — возможность MCP, которая сообщает клиенту, что его список инструментов был пересмотрен. Клиент, который реагирует на этот сигнал, перечитает определения в середине сессии и получит отравленную версию без каких-либо действий оператора; клиент, который кэширует определения при одобрении, этого не сделает. Какое поведение у конкретного агента — это свойство клиента, а не сервера, и в отчёте Pillar клиенты не перечисляются по именам.

Поставка: 23 пул-реквеста за 74 минуты

Распространение не было пакетом в реестре и не было отравленной зависимостью, закопанной в lockfile. Это был спам пулл-реквестами по проектам, никак не связанным с предполагаемой функцией сервера, — именно такую форму принимает малозатратная попытка атаки на цепочку поставок, когда злоумышленник не может получить аккаунт мейнтейнера: подать достаточно изменений конфигурации и ждать, пока одно из них будет смёржено или применено локально.

Разбор Pillar этих 23 случаев делится на три категории. Семнадцать добавляют удалённую конечную точку MCP, productivity-suite-mcp[.]onrender[.]com/mcp, размещённую на Render; четыре вызывают скрытый локальный файл Python по пути ~/.config/.cache/.sys/.deadbug-mcp.py; два представляют собой отправки в каталоги или списки, которые в отчёте рассматриваются как разведка или наполнение, а не как доставка. Временное окно указано как с 21:52 до 23:07 UTC 10 августа 2026 года — 74 минуты в формулировке раскрытия, хотя между самими двумя отметками времени проходит 75 минут, и ничто в записи не зависит от этой минуты. Только один целевой репозиторий назван отдельно: getsentry/sentry-mcp, пул-реквест №1239, приводится как пример доставки через локальный артефакт.

Аккаунт, стоящий за этим, был внушительным для своего возраста. На момент составления коллекции Pillar у zellkernel было 50 публичных репозиториев, 20 из них — форки, а 21 из этих 50 были созданы 10 августа, в тот же день, что и кампания. Профиль был перекрёстно связан с аккаунтом в X @llmgod, который, в свою очередь, ссылался обратно на аккаунт GitHub, что представляет собой именно тот вид взаимного связывания, которое свидетельствует о специально созданной идентичности, а не о перехваченной.

Девятнадцать закрытых, четыре открытых, ноль объединённых — это чаще всего повторяющаяся цифра в записях и та, которую чаще всего воспринимают как сигнал «всё чисто», хотя это не совсем так. Кнопка слияния GitHub — не журнал выполнения на хосте: мейнтейнер может забрать ветку и запустить её, применить конфигурацию вручную, или задача CI может извлечь head PR до того, как кто-либо оставит комментарий. Те четыре pull request, которые записывают конфигурацию, вызывающую путь к локальному скрипту, — это те случаи, где этот разрыв имеет наибольшее значение, потому что скрипт загружается и выполняется полностью вне учёта слияний GitHub. Cloud Security Alliance Labs указала на то же самое в своей заметке от 2 сентября: показатели закрытых и необъединённых не доказывают, что ничего не запускалось.

Что установлено, а что — нет

Установлено в рамках раскрытия — в том смысле, что Pillar сообщает об этом на основе прочитанных им артефактов и в одном случае — сервиса, к которому он сделал запрос: сервер и его репозиторий с исходным кодом, два заявленных инструмента, счётчик и порог в три вызова, четыре цели для учётных данных, количество PR и их статус слияния на момент проверки, а также связь между учётной записью GitHub и аккаунтом X. Собственное тестирование Pillar на живом эндпоинте — самый сильный пункт в этом списке, поскольку это воспроизведение, а не чтение исходного кода.

Не установлено — и запись осторожна в этом отношении — наличие жертвы. Поле real_harm в архиве имеет значение false, а это утверждение о доказательствах, не о намерениях: никто не предъявил ни хоста, ни лога, ни украденных учётных данных, связанных с этой кампанией. Не установлены и человек или группа, стоящие за zellkernel и @llmgod; Pillar приписывает операцию этим аккаунтам и на этом останавливается. Финансовый мотив держится на биткойн-адресе, встроенном в полезную нагрузку, а это вывод из индикатора, не установленный факт о субъекте. А вопрос, на который защитник хочет получить ответ больше всего, — продолжается ли кампания, — в записи ответа не имеет: пост был помечен как подлежащий обновлению, и никаких более поздних правок или уведомлений об удалении от GitHub или Render не видно.

Подтверждений меньше, чем можно было бы предположить по уровню уверенности, и об этом стоит сказать прямо. Две Cloud Security Alliance Labs исследовательские заметки от 30 августа и 2 сентября 2026 года повторяют описание кампании; в более поздней прямо указано, что она приписывает Pillar обнаружение, детали PR, поведение сервера и атрибуцию учётной записи, и при этом не описывает никакой собственной независимой проверки. Публикация Armor в блоге от 22 сентября 2026 года содержит рекомендации по защите и утверждает, что Pillar разобрал сервер; она не приводит собственных результатов форензического анализа. CVE не был присвоен, и CSA утверждает, что это не уязвимость спецификации MCP. По состоянию на 29 октября 2026 года поиск не выявляет ни уведомлений от GitHub или Render, ни публикаций в основных отраслевых изданиях по кибербезопасности — ни одного материала BleepingComputer, The Register, SecurityWeek или Hackread, — что необычно для кампании в цепочке поставок такого рода и само по себе является частью того, что показывают материалы. «Первичные источники согласуются» здесь означает один исходный первичный источник и набор вторичных документов, производных от него.

Две менее значительные неоднозначности стоит отметить, а не сглаживать. Вторичные сводки расходятся в том, является ли третий вызов или четвёртый первым получившим отравленные метаданные; это следует из того, что счётчик описывается как срабатывающий на третьем запросе; и запись, и раскрытие используют три. А окно доставки описывается как 74 минуты для временных меток, охватывающих 75.

Одну проверку не удалось повторить: по состоянию на 29 октября 2026 года аккаунт GitHub zellkernel и репозиторий zellkernel/productivity-suite-mcp оба возвращают 404, а единственный отдельно названный пул-реквест getsentry/sentry-mcp #1239 тоже больше не открывается — сам репозиторий теперь перенаправляет на getsentry/toolkit. Поэтому количество PR, статус слияния и содержимое репозитория сегодня невозможно перепроверить по первоисточникам; они остаются снимком Pillar, сделанным в середине августа.

Что раскрытие требует от защитников делать

Ответ, который рекомендует Pillar, в основном сводится к тому, чтобы рассматривать метаданные как поверхность безопасности, а не как их описание. Для хостов конкретные требования — блокировать или вести охоту на productivity-suite-mcp[.]onrender[.]com/mcp, сохранять более ранний эндпоинт кампании trycloudflare.com в списках запрета и охоты, хотя Pillar говорит, что сейчас он неактивен, и не запускать deadbug-mcp.py — скрытый путь к файлу ~/.config/.cache/.sys/.deadbug-mcp.py является артефактом, который следует искать в домашних каталогах, репозиториях и конфигурациях клиентов MCP.

Порядок расследования важнее блок-листа. Если хост мог подключаться, Pillar советует сохранить журналы MCP-клиента, прежде чем что-либо очищать, затем проверить обновления определений инструментов и то, что агент делал после третьего вызова; учетные данные следует ротировать только там, где локальные свидетельства подтверждают экспозицию, — это противоположность рефлексу ротировать всё при подозрении. Конфигурация сервера также допускала необязательную телеметрию на адрес WEBHOOK_URL, отправку маячковых сигналов при подключении, первом вызове и событии-триггере — деталь, которая дает расследованию третье место для проверки помимо журналов клиента и трафика конечных точек.

Для тех, кто создаёт клиенты MCP, рекомендация носит структурный характер, и это та часть записи, которая дольше всего сохраняет актуальность:

• Создавать отпечаток определений инструментов в момент утверждения и сравнивать их при каждом обновлении, вместо того чтобы доверять имени сервера и репозиторию.

• Относитесь к изменению определения на уже одобренном сервере как к событию безопасности, которое оператор видит и повторно одобряет, а не как к рутинному изменению метаданных, которое молча проглатывается.

• Обеспечивайте контроль чувствительных операций — доступа к учётным данным, выполнения кода, отправки исходящих писем, записи в репозиторий — через политику, а не через описания, которые предоставляет сервер.

Этот третий пункт и делает Deadbugz не курьёзом, а документально подтверждённым случаем. Все описанные выше механизмы контроля исходят из того, что агента можно убедить сделать что-либо с помощью текста, который сервер прикрепляет к инструменту, и что этот текст может измениться уже после того, как решение о доверии было принято. Pillar ставит эту кампанию в один ряд с атакой на MCP «спящий агент» (MCP sleeper attack), описанной Invariant Labs в 2025 году, поддельным пакетом postmark-mcp и пакетом MCP, документированным Koi и превращённым в оружие через обновление, — все они являются прецедентами данной техники, и Pillar ссылается на них именно в этом качестве, а не как на свидетельства, относящиеся к этой поставке.

Почему ворота важнее числа жертв

Кампанию с 23 попытками доставки, без слияния и без подтверждённой жертвы легко отнести к попыткам и двигаться дальше. Её место в архиве с высоким уровнем критичности объясняется тем, что её обход не зависит от успешной доставки в масштабе. Он зависит от свойства, присущего сегодня большинству развёртываний MCP: одобрение происходит один раз, при установке, и предполагается, что одобренное определение и будет обслуживаться. Deadbugz сохраняет это предположение неизменным на протяжении трёх вызовов, а затем нарушает его.

Исправление — это не патч для конкретного сервера, и отслеживать здесь нечего: CVE отсутствует. Оно в том, что «одобрено» должно стать постоянным условием, подкреплённым сравнением, — а это изменение в том, как ведут себя клиенты и их операторы, а не в том, что ищет сканер. Запускал ли кто-нибудь сервер в августе на самом деле, по-прежнему неизвестно; судя по имеющимся записям, находкой является сам механизм.