У вівторок зловмисник отримав контроль над обліковим записом GitHub розробника, який підтримує Keyv – невелику бібліотеку для зберігання даних за ключем, яку npm використовує приблизно 127 мільйонів разів на тиждень. Протягом кількох годин заражені версії Keyv та супутніх пакунків для кешування з’явилися на npm, несучи черв’яка, що викрадає облікові дані. До обіду компанія з кібербезпеки Aikido нарахувала щонайменше 868 скомпрометованих пакунків у 1 381 версії, загальна кількість щомісячних установок яких перевищує два мільярди і продовжує зростати. JFrog незалежно відстежила кампанію, яка охопила понад 400 пакунків і 1 700 заражених версій.
Найбільше має турбувати кожну команду безпеки не кількість завантажень, а документація. Початкові заражені релізи мали дійсні цифрові підписи провенієнсності – криптографічне підтвердження, яке індустрія створила для доказу того, що пакунок походить з того джерела, яке заявлено. Черв’як не підробляв цей підпис. Він заробив його, як це робить легітимний реліз.
Днем раніше CrowdStrike опублікував свій звіт “2026 Threat Hunting Report” і передбачив саме такий тип атаки. Розділ під назвою “Атаки на ланцюжок постачання програмного забезпечення еволюціонують” вказує на саму екосистему розробників, пакункові реєстри, конвеєри безперервної інтеграції, контейнерні реєстри та розширення, які розробники завантажують до своїх редакторів коду, як поверхні, що стають прямою ціллю зловмисників. npm-пакунки знаходяться в центрі цієї зміни, становлячи 87% загроз від шкідливих програмних реєстрів, відстежених CrowdStrike за першу половину року. Черв’як Keyv перетворив це виявлення на реальний інцидент протягом 24 годин.
Для CISOs та архітекторів безпеки ці дві події читаються як одне повідомлення. Сигнали довіри, вбудовані в ланцюжок постачання програмного забезпечення, можуть бути задоволені зловмисником, який володіє правильним обліковим записом, а часовий проміжок між виявленням та експлуатацією скоротився настільки, що його неможливо охопити щомісячними патчами.
Як черв’як заробив свою провенієнсність
Розглянемо механізм, і стане зрозуміло, чому провенісність не допомогла. Згідно з аналізом Aikido, зловмисник завантажив шкідливі файли безпосередньо до основної гілки кожного репозиторію, який контролював розробник, а потім негайно випустив новий реліз. Оскільки реліз проходив через власний робочий процес розробника GitHub Actions, npm згенерував для нього легітимне підтвердження провенієнсності. Для будь-кого, хто перевіряв цілісність ланцюжка постачання, заражена збірка виглядала автентичною. Wiz незалежно підтвердив шлях релізу, і в одному цільовому шляху, задокументованому JFrog, черв’як зайшов далі. Всередині запуску GitHub Actions, пов’язаного з opensearch-js, він запросив OIDC-токен, обміняв його на publish token і створив Sigstore bundle через Fulcio та Rekor, щоб шкідливий tarball мав провенісність, згенеровану з довіреного контексту робочого процесу.
Те, що перетворило одноразове захоплення облікового запису на подію всереєстрового масштабу, – це поширення. Як тільки заражений пакунок потрапляв до середовища розробника або до білд-раннера, його корисне навантаження викрадало всі облікові дані, до яких воно могло дістатися, а потім використовувало будь-які знайдені npm publish tokens для розміщення бекдорів в інших пакунках, які контролював потерпілий. Кожен скомпрометований розробник ставав несвідомим вузлом розповсюдження, і Aikido спостерігав, як десятки нових заражених пакунків з’являються кожні кілька хвилин. Шкідливе програмне забезпечення виводило викрадені секрети до публічних репозиторіїв GitHub з тегом “Shai-Hulud: Here We Go Again”, що і дало назву кампанії.
Цей масштаб поширення вийшов далеко за межі маловідомих утиліт. Оскільки Keyv є транзитивною залежністю багатьох популярних інструментів, черв’як використовував ці ланцюжки для проникнення до пакунків у корпоративних npm-скоупах, серед підтверджених жертв опинилися релізи, пов’язані з Deliveroo, Qlik та Picsart. Розробники цих компаній ніколи не встановлювали Keyv навмисно. Вони просто залежали від чогось, що залежало від нього, на багато рівнів нижче в структурі, яку ніхто не переглядає вручну.
Екстрактори облікових даних у складі корисного навантаження розкривають, що насправді шукали зловмисники, і це ніколи не були бібліотеки для кешування. JFrog, який відстежив компрометацію Keyv та Cacheable, і Wiz виявили, що шкідливе програмне забезпечення викрадає ключі доступу до хмари, секрети CI та токени, що автентифікують виробничу інфраструктуру. Компрометація пакунка була транспортним засобом, а хмара за ним – завжди призначенням. CrowdStrike виявив, що злочинна діяльність, пов’язана з хмарними технологіями, зросла на 171% за першу половину 2026 року, і компрометація ланцюжка постачання є одним із шляхів, що живлять її.
Ціллю стали власні інструменти розробника
Викрадення було не кінцем, адже черв’як також осідав там, де працюють розробники. Wiz виявив, що шкідливе програмне забезпечення розміщує постійні корисні навантаження у двох каталогах на машинах, до яких воно отримує доступ: один для Visual Studio Code, а інший – .claude, робочий каталог для агента Claude Code від Anthropic. Файли налаштування, розміщені там, означають, що корисне навантаження може запускатися, коли розробник відкриває заражений проект у своєму редакторі або починає сеанс кодування зі ШІ, а не лише під час встановлення. Це саме та екосистема розробників, яку назвав CrowdStrike, вражена точно: редактор та помічник зі штучним інтелектом, яким розробник довіряє найбільше і перевіряє найменше.
Виправлення нічого не коштує
Один засіб контролю міг би послабити черв’яка, і він нічого не коштує. Адам Майерс, керівник відділу протидії ворожим операціям у CrowdStrike, виклав це в попередньому інтерв’ю під ембарго. “Захистіть ланцюжок постачання програмного забезпечення”, – сказав він. “Прості речі, як-от заборона будь-яким вашим інструментам завантажувати найновіші залежності, але, можливо, залежності минулого тижня”. Затримка – це вся суть. “Ви все ще матимете досить актуальні речі, але ви не матимете ризику завантажити щось, що було оновлено кілька хвилин тому, і тепер ви просто впровадили якесь шкідливе інструментування”. Реліз, затриманий на тиждень, дає спільноті безпеки час для виявлення зараження, яке інакше поширилося б на кожну наступну збірку за лічені хвилини.
Ця рекомендація не є гіпотетичною. npm запровадила цю можливість у лютому 2026 року з версією CLI 11.10.0 як налаштування під назвою min-release-age. pnpm зробив це за п’ять місяців до цього з minimumReleaseAge. Будь-який з них дозволяє команді відхилити будь-яку версію пакунка, опубліковану пізніше встановленого порогу. Черв’як Keyv є аргументом для його увімкнення.
Майерс поєднує “період охолодження” з другою дисципліною. Патчте те, що експлуатують зловмисники, перш за все. “Вам потрібно зосередити свої зусилля з пом’якшення вразливостей та патчингу навколо експлойтів, які відомі зловмиснику”, – сказав він VentureBeat. Він вказав на ресурс, яким більшість команд використовують недостатньо. “CISA тут, у Сполучених Штатах, публікує так званий Каталог відомих експлуатованих вразливостей”, який щотижня оновлюється підтвердженими активно атакованими помилками, підтримується урядом і є безкоштовним. “Якщо ви спочатку виправте ці вразливості, ви, ймовірно, будете в безпеці”.
Майерс навів конкретні цифри щодо проблеми швидкості – цифри, які не з’являються в опублікованому звіті. Весь 2025 рік налічував приблизно 48 200 вразливостей, зареєстрованих як CVE. Коли він перевіряв тиждень перед брифінгом, у 2026 році вже було 43 000.
Такий обсяг руйнує щомісячні цикли патчингу. “Вони не можуть працювати в 30-денних вікнах патчингу”, – сказав він VentureBeat. “Як тільки вразливість стає відомою, їм потрібно рухатися до виправлення або пом’якшення цієї конкретної проблеми”. Звіт CrowdStrike зіставляє цю траєкторію зі знахідкою про те, що 88% експлуатації, спостережуваної проти вразливостей з публічним доказом концепції, відбулося протягом 48 годин після публікації коду.
GitHub вирішив половину проблеми
GitHub, якій належить npm, провела останній рік, посилюючи захист реєстру від саме такого класу атак. Платформа зробила двофакторну автентифікацію обов’язковою для публікації, відкликала старі токени доступу, що ніколи не закінчуються, і додала довірену публікацію, щоб системи збірки працювали без збережених облікових даних. Потім у версії npm 12, випущеній у середині 2026 року, вона змінила найбільш значущу за замовчуванням. Хуки preinstall, install та postinstall, на які спирається більшість шкідливих програм реєстру для виконання в момент завантаження пакунка, тепер вимагають явного дозволу.
Ця зміна має пряме значення тут, оскільки черв’як Keyv виконується через скрипт preinstall, а npm 12 працює в обох напрямках. JFrog підтвердив, що на npm 12 або новіших версіях, де хуки preinstall вимкнені за замовчуванням, шкідливе програмне забезпечення не запускається під час встановлення. Усі організації, що залишилися на старих версіях npm, а більшість підприємств оновлюються повільно, залишалися під загрозою.
Захисні заходи GitHub посилили неправильну половину атаки більше, ніж правильну, ускладнюючи виконання шкідливого пакунка після його прибуття, але менше роблячи для зупинки зловмисника від отримання права на публікацію. Захоплення облікового запису залишається першопричиною. Кіран Радж, інженер з безпеки в Endor Labs, сказав, що бачив ту ж закономірність – крадіжку та повторне використання npm publish token – у більшості випадків, токен CI або облікового запису служби, викрадений з білд-раннера, який сам встановив заражену залежність. Черв’як ніколи не мав потреби долати провенієнсність. Йому потрібен був один набір дійсних облікових даних, а власна автоматизація публікації npm зробила решту.
Атестація провенієнсності відповідає на питання, чи походить пакунок з конвеєра, який він заявляє. Вона не відповідає на питання, чи мав право запускати цей конвеєр людина або токен. Управління ідентифікацією, хто може публікувати та до чого мають доступ їхні облікові дані, є слабшим контролем. CrowdStrike називає зловживання законними ідентичностями розробників як основну точку входу для компрометації ланцюжка постачання. Майерс висловився просто. “Вони входять, а не зламують”, – сказав він. Обліковий запис підтримки Keyv був цією ідентичністю, а механізм довіреної публікації зробив решту від імені зловмисника.
Чому наступною буде рада директорів
Тиск щодо виправлення цього виходитиме не лише зі звітів про загрози. Він скоро надійде через контракти. Кейн МакГладрі, старший член IEEE, сказав VentureBeat в ексклюзивному інтерв’ю, що підприємства починають перекладати зобов’язання щодо безпеки програмного забезпечення на постачальників та розробників у своєму ланцюжку постачання. “Ми почнемо бачити, як компанії намагатимуться контрактно перекласти відповідальність на інші сторони в їхньому ланцюжку постачання”, – сказав він VentureBeat. “Ми використовуємо вашу технологію, але ми хочемо, щоб ви забезпечили її безпеку”.
Він порівняв це з тим, як Міністерство оборони змусило своїх постачальників підвищити рівень гри через програму сертифікації CMMC. “Станьте кращими в кібербезпеці, якщо хочете продавати нам щось”. Для будь-якої компанії, що розповсюджує програмне забезпечення на основі відкритих залежностей, це перетворює провенієнсність, ідентифікацію та дисципліну патчингу на контрактний ризик.
Що робити в понеділок вранці
Для команди безпеки, яка вирішує, що робити з цим у понеділок вранці, дії поділяються на п’ять кроків, що відповідають п’яти способам роботи цього класу атак. Кожне з них є управлінським рішенням, яке рада директорів може фінансувати та контролювати, а не інструментом, який розробник встановлює самостійно.
|
Як працює атака |
Що показав черв’як Keyv |
Що фінансує та контролює рада директорів |
|
Екосистема розробників є ціллю. |
CrowdStrike називає пакункові реєстри, конвеєри CI/CD, контейнерні реєстри та розширення IDE як поверхні, що прямо вражаються зловмисниками. Корисне навантаження Keyv розмістило постійні хуки в каталогах редактора розробника та інструментів ШІ, а не лише в пакунку. |
Вимагати атестацію провенієнсності та довірену публікацію перед тим, як будь-яка залежність або розширення редактора потрапить до збірки. Надати раді директорів постійний облік реєстрів, компонентів конвеєра та розширень у сфері дії. Розглядати інструменти розробника як категорію аудитованих постачальників. |
|
Автоматизація робить поширення швидким. |
Один викрадений обліковий запис запустив каскад, який охопив щонайменше 868 пакунків і два мільярди щомісячних установок за кілька годин, переходячи між організаціями кожні кілька хвилин. Черв’як працював через скрипт preinstall, який за замовчуванням npm v12 вимикає. |
Увімкнути min-release-age npm, щоб інструменти завантажували версії минулого тижня, а не релізи, опубліковані кілька хвилин тому. Вимагати npm v12 або блокування install-скриптів у всьому середовищі збірки. Планувати одночасну компрометацію кількох пакунків під час тестування стійкості. |
|
Ідентифікація є точкою входу. |
Атака почалася з одного захопленого облікового запису підтримки GitHub. Провенісність підписала заражені релізи, оскільки вони проходили через власний конвеєр підтримки. Дію здійснили дійсні облікові дані, а не зламаний контроль. |
Призначити обов’язковою фішингостійку багатофакторну автентифікацію для кожного розробника з правами публікації. Надавати перевагу короткоживучим обмеженим токенам над довгоживучими. Звітувати раді директорів про охоплення ідентичності розробників та машин як прораховану відповідальність. |
|
Хмара – справжнє призначення. |
Корисне навантаження містило цільові екстрактори для ключів доступу до хмари, секретів CI та токенів виробничої інфраструктури. Компрометація пакунка була транспортним засобом. Злочинна діяльність, пов’язана з хмарними технологіями, зросла на 171% за першу половину 2026 року. |
Класифікувати робочі станції розробників та CI-раннери як активи рівня нуль зі стандартами ротації контролерів домену. Документувати ротацію хмарних облікових даних протягом годин після будь-якого виявлення компрометації ланцюжка постачання. Звітувати про довгоживучі хмарні ключі з цілями скорочення. |
|
Вікно патчингу скоротилося. |
CrowdStrike спостерігав 88% експлуатації з публічним доказом концепції протягом 48 годин. Майерс поставив реєстрації CVE за 2026 рік на рівні 43 000 на кінець липня проти 48 200 за весь 2025 рік. Черв’як Keyv був активний протягом кількох годин, без CVE, на який можна було б чекати. |
Переглянути рівні обслуговування патчингу для систем, доступних з Інтернету, з днів до годин і фінансувати безперервний екстрений патчинг як бюджетну операцію. Надати аудиторському комітету час від виявлення до пом’якшення як постійний показник. Побудувати захист на задокументованих компенсуючих контролях до патчингу. |
Кількість пакунків відображає дані Aikido та JFrog від 4 серпня і продовжувала зростати на момент преси.
Черв’як Keyv буде локалізований. Скомпрометовані версії будуть видалені, викрадені токени замінені, заражені пакунки перевипущені як чисті. Але форма викриття, яку він виявив, не зміниться. Екосистема розробників тепер є основною ціллю, автоматизація, яка робить її продуктивною, є тією ж автоматизацією, що робить черв’яка швидким, а сигнали довіри, призначені для її безпеки, можуть бути задоволені будь-ким, хто має правильні облікові дані.
За матеріалами: venturebeat.com