Хробак Shai-Hulud поширився через зламану сесію AI-асистента кодування

AI-асистенти кодування стали буденністю: вони дописують код, пропонують бібліотеки та «допомагають» з рутиною кожному розробнику. Але у вересні 2026 року команда Mandiant (підрозділ Google Cloud із розслідування кіберінцидентів) оприлюднила кейс, який показує зворотний бік цієї зручності. Зловмисник отримав контроль над активною сесією AI-асистента кодування в одній SaaS-компанії, змусив його порекомендувати отруєне програмне забезпечення і в підсумку поширив хробак Shai-Hulud приблизно на 100 внутрішніх репозиторіїв. Украли секрети репозиторіїв і вихідний код продуктів компанії.

Це не гіпотетичний сценарій «злої машини», а реальна атака, яка демонструє найслабше місце нових інструментів розробки: AI-помічник працює з тими самими правами, що й розробник, і довіряє тому, що йому підсовують. Розбираємо, як саме все сталося, чим небезпечний Shai-Hulud і як захистити свою команду.

Що сталося: отруєна рекомендація AI-асистента

Кейс описано у вересневому звіті Mandiant. Йдеться про неназваного постачальника програмного забезпечення як сервісу (SaaS), у якого зловмисник перехопив контроль над активною сесією AI-асистента кодування. Важливо, що публічний опис кейсу не розкриває, коли саме стався інцидент і яким конкретно способом атакуючий заволодів сесією, — але наслідки описані детально.

Ланцюжок виглядав так. Спочатку асистент порекомендував розробнику програмне забезпечення, яке зловмисник заздалегідь отруїв, і ця рекомендація була прийнята. Інакше кажучи, атакуючий не «зламував» репозиторій безпосередньо — він використав довіру розробника до AI-підказок, щоб підсунути шкідливий компонент.

Далі, вже маючи доступ до активної сесії розробника, зловмисник встановив інформаційний стілер (infostealer) через отруєний PyPI-пакет, а також викрав OAuth-токени GitHub. Після цього він розгорнув саморозповсюджуваний хробак Shai-Hulud приблизно на 100 внутрішніх репозиторіях коду. Хробак викрав секрети репозиторіїв і вихідний код продуктів компанії.

Як працювала атака: від сесії до хробака

Ключова деталь, яку підкреслює Mandiant: зловмисник не обмежився однією жертвою. Він також отруїв пакет у офіційному namespace компанії. Коли інший співробітник завантажив уже скомпрометовану версію цього пакета, відбулося друге зараження — без жодного «злому» з боку атакуючого, лише через звичний робочий процес.

Це класична схема атаки на ланцюжок постачання (supply chain), тільки з новим «переносником» — AI-асистентом. Традиційно зловмисники покладаються на те, що розробник скопіює команду зі шкідливого сайту або встановить сумнівний пакет. Тепер достатньо, щоб AI-помічник, якому розробник звик довіряти, сам порекомендував потрібний компонент. Людина в ланцюжку перестає бути точкою перевірки — вона стає точкою автоматичного виконання.

Послідовність атаки можна звести до п'яти кроків:

• Захоплення сесії — зловмисник отримує контроль над активною сесією AI-асистента кодування.
• Отруєння пакета — шкідливий компонент заздалегідь готують і публікують.
• Рекомендація — асистент пропонує отруєне ПЗ, розробник приймає пропозицію.
• Розширення доступу — через сесію встановлюється infostealer і викрадаються OAuth-токени GitHub.
• Розповсюдження — хробак Shai-Hulud розходиться репозиторіями, забираючи секрети та вихідний код.

Що таке Shai-Hulud і чому він небезпечний

Shai-Hulud — це саморозповсюджуваний хробак для атак на ланцюжок постачання. За даними бази MITRE ATT&CK (ідентифікатор S9008), вперше його задокументували у вересні 2025 року. Хробак поширюється через репозиторії коду, зокрема GitHub та npm-пакети, і використовує залежності CI/CD-конвеєрів, щоб переходити від жертви до жертви.

Потрапивши в середовище, Shai-Hulud краде облікові дані та токени доступу зі скомпрометованих облікових записів репозиторіїв і виводить їх на сервери атакуючого через закодовані робочі процеси GitHub Actions. Відомі також випадки, коли він публікував викрадені облікові дані у відкритих GitHub-репозиторіях — тобто втрата доступу може перетворитися на публічний витік.

Технічний почерк хробака добре задокументовано. MITRE ATT&CK фіксує, що Shai-Hulud створює в скомпрометованому обліковому записі репозиторій, який зберігає зібрану інформацію про систему, змінні середовища та викрадені секрети у вигляді JSON-дампа; для пошуку секретів він завантажує і запускає інструмент TruffleHog; а для ексфільтрації використовує, серед іншого, сервіс webhook.site. Також відомо, що хробак маскувався під легітимний інсталятор Bun і придушував попередження npm, щоб зараження лишалося непомітним. Усе це свідчить: перед нами зрілий інструмент, а не одноразова витівка.

Назва відсилає до гігантських піщаних хробаків із «Дюни» Френка Герберта, і аналогія точна: як і вигаданий монстр, це шкідливе ПЗ «рухається» під поверхнею інфраструктури розробки, поглинаючи все цінне, що трапляється на шляху.

Чому це важливо: AI-асистент має права розробника

Головний урок кейсу не в конкретному зразку шкідливого ПЗ, а в архітектурній проблемі. AI-асистенти кодування працюють із тими самими правами доступу до файлової системи, мережі та репозиторіїв, що й розробник, який їх запускає. Це означає, що будь-яка вразливість або компрометація асистента одразу дає зловмиснику ті самі можливості, що й викрадений обліковий запис людини.

Додайте до цього другий фактор — сліпу довіру до рекомендацій. Коли асистент пропонує бібліотеку, багато розробників приймають її без додаткової перевірки: це ж «зручно» і «так і має бути». Саме на цю звичку і зіграли атакуючі в описаному кейсі.

Для українських команд цей ризик особливо відчутний. З одного боку, AI-тулінг стрімко входить у повсякденну розробку, включно з невеликими продуктовими командами, які не мають виділених фахівців із безпеки. З іншого — компанії, що працюють на оборону, фінтех чи критичну інфраструктуру, є постійною мішенню, і витік вихідного коду чи токенів доступу може мати наслідки далеко за межами одного репозиторію. Перевірити, чи не опинилися ваші облікові дані у витоках, можна через інструмент перевірки витоків cyberpeople.tech.

Ширший контекст: Mini Shai-Hulud і атаки на AI-тулінг

Shai-Hulud — не єдиний і не останній у своєму «сімействі». У базі MITRE ATT&CK окремо описано Mini Shai-Hulud (S9043) — похідного хробака, якого угруповання TeamPCP використовує проти CI/CD-робочих процесів щонайменше з 2026 року.

Цікаво, що Mini Shai-Hulud став першим задокументованим зразком, який використовує конфігураційні файли AI-агентів кодування як механізм закріплення. Хробак модифікує `.claude/settings.json` (для Claude Code) та `.vscode/tasks.json` (для VS Code), щоб повторно запускатися щоразу, коли розробник відкриває проєкт — навіть якщо заражений пакет уже видалили. Інакше кажучи, шкідливий код «ховається» в налаштуваннях інструментів, якими розробник користується щодня, і переживає очищення залежностей.

Це означає, що загроза для AI-тулінгу розробки — не поодинокий інцидент, а тренд. Зловмисники вже адаптували свої методи під новий ландшафт: там, де раніше були лише npm-пакети та build-скрипти, тепер з'явилися AI-асистенти та їхні конфігураційні файли.

Чому середовища розробки стали пріоритетною мішенню

Атака, описана Mandiant, не випадкова — вона вказує на структурне зрушення в цілях зловмисників. Середовища розробки сьогодні концентрують одразу кілька найцінніших активів компанії: вихідний код продуктів, секрети й токени доступу, а також автоматизовані конвеєри збірки та доставки, які за замовчуванням мають широкі права. Якщо зловмисник компрометує CI/CD або репозиторій, він часто отримує шлях до прод-інфраструктури без додаткових зусиль.

Додайте до цього швидкість поширення: через ланцюжок постачання один отруєний компонент може заразити десятки чи сотні проєктів, як це сталося з репозиторіями у кейсі Shai-Hulud. На відміну від класичної атаки на сервер, де потрібен окремий пролом для кожної системи, тут один крок «розмножується» автоматично. Саме тому такі атаки дедалі частіше фігурують у звітах про найбільш руйнівні інциденти, а захист середовищ розробки перестав бути «темою для великих корпорацій».

Як захиститися: три контролі від Mandiant і практичні поради

Mandiant у своєму звіті пропонує три базові контролі для AI-асистованої розробки, і їх варто впровадити незалежно від розміру команди:

1. Перевіряйте залежності за контрольними сумами та затвердженими списками. Будь-яка бібліотека, рекомендована AI-асистентом, має пройти ту саму перевірку, що й та, яку розробник знайшов самотужки: криптографічна контрольна сума та наявність у дозволеному переліку. Рекомендація AI — це не дозвіл, а лише сигнал.
2. Тримайте секрети подалі від досяжності розширень. Сирі API-ключі, довгоживучі OAuth-токени та інші секрети не повинні лежати там, де їх може прочитати AI-асистент або його розширення. Використовуйте менеджери секретів і змінні середовища з мінімальним часом життя.
3. Спрямовуйте трафік залежностей через внутрішні репозиторії. Внутрішнє проксі-сховище (artifact registry) дозволяє контролювати, звідки беруться пакети, і блокувати підозрілі версії до того, як вони потраплять у збірку.

До цих трьох пунктів варто додати практичні звички, які закривають більшість подібних сценаріїв:

• Не автовиконуйте код із рекомендацій. Перш ніж прийняти підказку асистента, що тягне за собою встановлення пакета чи виконання скрипта, прочитайте, що саме він пропонує.
• Розділяйте права. AI-асистент не повинен працювати з повними правами власника репозиторію; налаштуйте окремий контекст із мінімальними дозволами.
• Моніторте робочі процеси GitHub Actions. Саме через них Shai-Hulud виводив викрадені дані, тож аномальні workflow-запуски мають викликати негайну перевірку.
• Регулярно скануйте секрети в репозиторіях. Інструменти на кшталт TruffleHog (який, до речі, сам Shai-Hulud використовує для пошуку секретів) допомагають знайти випадково закомічені токени раніше, ніж їх знайде зловмисник.
• Навчайте команду. Базове розуміння того, що AI-підказка може бути скомпрометована, — найдешевший захист. Більше про системне навчання команд — у нашому матеріалі «Кібербезпека: навчання з нуля».

Що робити, якщо атака вже сталася

Якщо ви підозрюєте, що ваше середовище розробки вже скомпрометоване, перші кроки мають бути швидкими і спрямованими на обмеження шкоди:

• Відкликайте токени негайно. OAuth-токени GitHub та API-ключі, які могли потрапити до зловмисника, треба відкликати першими — саме вони дають подальший доступ.
• Ізолюйте уражені репозиторії. Призупиніть робочі процеси CI/CD і заблокуйте запуск підозрілих workflow, поки не зрозумієте масштаб.
• Перевірте залежності. Шукайте нещодавно додані або змінені пакети, особливо в офіційному namespace вашої організації, і звіряйте їх із відомими доброякісними версіями.
• Залучіть фахівців. Для інциденту такого масштабу варто звернутися до спеціалізованої команди реагування (або вашого security-вендора), як радить і сам Mandiant.

Головне правило при реагуванні — не «чистити» наосліп, а спершу зрозуміти, скільки облікових записів і секретів зачеплено. Інакше хробак, який закріпився у конфігураційних файлах або робочих процесах, повернеться після першого ж «очищення».

Висновок

Інцидент, описаний Mandiant, — це не про «шкідливий AI», а про те, що новий інструмент у руках розробника успадкував старі ризики ланцюжка постачання і додав до них новий фактор довіри. AI-асистент кодування став ще однією поверхнею атаки, і зловмисники вже навчилися нею користуватися.

Головне, що варто винести: довіра до рекомендації AI-асистента не повинна замінювати перевірку. Контрольні суми, затверджені списки, внутрішні репозиторії та подалі прибрані секрети — це не бюрократія, а мінімальний бар'єр, який відділяє зручний тулінг від скомпрометованої інфраструктури. Для українських команд, які все активніше використовують AI у розробці, це навичка, яку варто опанувати раніше, ніж вона знадобиться у реальному інциденті.