Червеят в npm и вашият сайт: стъпката на сглобяване вече е граница на сигурността
На 4 август 2026 г. самовъзпроизвеждащ се червей стигна до кеширащата библиотека keyv и нейните спътници и за часове се разпространи към стотици npm пакети, които заедно правят милиарди инсталации месечно. Това беше третата и най-голяма вълна на кампанията, известна като Shai-Hulud, и се случи седмица преди този текст да бъде написан.
Повечето собственици на бизнес ще приемат това за проблем на разработчиците. Не е, и причината е конкретна: ако сайтът ви е изграден със съвременен фронтенд инструментариум, машината, която го сглобява, изтегля и изпълнява код от стотици автори при всяко build. Стъпката на сглобяване е граница на сигурността и доскоро почти никой не се отнасяше към нея така.
Какво точно се случи
Схемата беше една и съща във всички вълни и си струва да се разбере веднъж, защото детайлите обясняват защо обичайните предпазни мерки не помогнаха.
- Кодът се изпълнява, преди да сте използвали пакета. Зловредният код тръгва по време на инсталацията, в кука от жизнения цикъл, а не когато приложението ви извика библиотеката. Достатъчно е да инсталирате.
- Събира идентификационни данни. Променливи на средата, облачни ключове, токени по машината — тоест точно това, което един build сървър има по дефиниция.
- Преиздава сам себе си. С откраднат публикационен токен качва зловредни версии на други пакети, които жертвата поддържа. Точно това го прави червей, а не инцидент, и затова стотици пакети падат за часове.
- Изнася данните открито. По-ранните вълни трупаха откраднатото в десетки хиляди новосъздадени публични хранилища — шумно, ефективно и трудно за почистване.
Вълната от ноември 2025 г. компрометира няколкостотин пакета и създаде десетки хиляди зловредни хранилища; публикуваните анализи описват механизма подробно. Августовската вълна на 2026 г. беше още по-голяма и стигна до пакети, които почти всеки JavaScript проект издърпва косвено.
Неудобната аритметика: никой не е инсталирал keyv съзнателно. Той идва като зависимост на зависимост на инструмент, който вие наистина сте избрали. Типичен фронтенд проект се разгръща в няколкостотин пакета, от които разработчикът е избрал съзнателно може би петнадесет. Всеки от останалите може да изпълни код на машината за сглобяване, а броят поддръжници, чието компрометиране стига до вас, е същите няколкостотин.
Дали това засяга вашия сайт
Три случая, три различни нива на риск. Намерете своя, преди да решавате каквото и да е.
| Как е изграден сайтът | Експозиция | Какво има значение |
|---|---|---|
| Класическа тема на WordPress без build | Ниска за точно тази атака | Рискът ви са плъгините, не npm |
| WordPress с компилирана тема или блокове | Реална, но ограничена до времето на сглобяване | Кой сглобява, на каква машина, с какви достъпи |
| Headless, SPA или JavaScript рамка | Висока | Всеки деплой е свежа инсталация на стотици пакети |
| Конструктор или хостната платформа | Наследена | Веригата на доставки на платформата вече е и ваша |
Обърнете внимание на втория ред. Много сайтове на WordPress имат стъпка на сглобяване — тема, компилирана от изходен код, персонализирани блокове, пакетиран административен скрипт — и я пуска често изпълнител на лаптоп, на който стоят и достъпите на клиенти. Точно този лаптоп е целта.
Какво наистина намалява риска
Пет мерки, подредени по ефект спрямо усилието. Нито една не изисква отдел по сигурност.
- Сглобявайте някъде за изхвърляне. Контейнер или CI изпълнител, който се създава за build-а и се унищожава след него. Откраднат достъп е полезен само ако съществува на машината; чист изпълнител с тясно обхванати тайни свежда последиците от всеки компрометиран пакет до тази една задача.
- Изключвайте install скриптовете, където можете. Настройката пакетният мениджър да пропуска куките от жизнения цикъл блокира точно механизма, който тези вълни ползват. Част от пакетите наистина се нуждаят от тях, така че става дума за кратък бял списък, а не за глобален ключ — но това превръща тихото изпълнение в съзнателно решение.
- Фиксирайте и комитвайте lock файла, после отлагайте обновяванията. Повечето такива кампании биват хванати за часове до дни. Политика да не се инсталира версия, публикувана през последните седемдесет и два часа, извън поправки по сигурността, премахва по-голямата част от експозицията почти без разход.
- Спрете с дълготрайните публикационни токени. npm отне класическите токени през декември 2025 г. и ограничи гранулираните токени с права за запис до деветдесет дни, заменяйки ги със сесийна автентикация. Ако публикувате пакети, минете към trusted publishing през вашия CI; практическият ориентир са насоките на OpenJS.
- Разделяйте достъпите по предназначение. Токенът, който деплойва, не бива да е токенът, който чете базата ви, и никой от двата не бива да живее в профила на обвивката на разработчик. Това е същият принцип като регистъра на достъпите от материала за това какво всъщност искат клаузите за сигурност на клиента.
Въпросите към изпълнителя
Ако някой друг сглобява и деплойва сайта ви, четири въпроса установяват реалната ви експозиция. Това са уместни въпроси и компетентен доставчик ще има готови отговори.
„Къде се изпълнява build-ът?“ Назована CI услуга е добър отговор. „На моята машина“ е честен отговор и означава, че рискът е хигиената на един лаптоп.
„Какви достъпи има на машината за сглобяване?“ Търсите кратък списък, ограничен до деплоя, а не лаптоп с достъп до продукционна база и ключовете на още пет клиента.
„Комитвате ли lock файл и преглеждате ли обновяванията на зависимости?“ Комитнат lock файл, който рядко се променя без преглед, е разликата между детерминиран build и лотария.
„Какво става, ако утре някоя зависимост се окаже зловредна?“ Отговорът трябва да включва ротация на достъпите, пресглобяване от известно добро състояние и проверка докъде е стигала машината за сглобяване. Ако отговор няма, това е пропускът.
Ако смятате, че сте засегнати
Скоростта тежи повече от сигурността в извода. Приемете компрометиране и действайте в този ред.
Сменете всички идентификационни данни, съществували на засегнатата машина или в засегнатия конвейер: npm токени, облачни ключове, ключове за деплой, пароли за бази, API ключове към външни услуги. Ротацията е евтина и обратима; разследването преди ротация не е нито едното, нито другото.
После проверете докъде са стигали тези достъпи. Ключ за деплой, който пише само в staging кофа, е съвсем различен инцидент от административен ключ към продукционна база.
Пресглобете от чист клон на чиста машина, вместо да „премахвате лошия пакет“. Зловредният код вече се е изпълнил; деинсталирането маха пакета, не последиците.
Накрая търсете какво е оставил: нови хранилища във вашата организация, нови ключове за деплой, нови сътрудници, неочаквани файлове с работни потоци. Тези кампании оставят артефакти и именно по артефактите се потвърждава обхватът. Това е и моментът, в който резервно копие с тестван възстановяващ пробег престава да е документация, по причините от материала за какво да тествате, преди да ви потрябва.
Същият сценарий извън npm
npm е най-шумният пример, защото е най-големият регистър и този, който по подразбиране изпълнява чужд код още при инсталиране. Но формата на атаката — компрометираш един поддържащ и наследяваш всички, които зависят от него — не е особеност на JavaScript. За един обикновен бизнес сайт три съседни случая имат по-голямо значение от червей в конвейера за сглобяване, защото стигат до продукцията директно, а не през лаптопа на разработчик.
WordPress плъгини. Плъгин със сто хиляди инсталации се продава, наследява или тихо се предава на други хора, а каналът за обновления тръгва заедно с него. Кодът, който пристига в автоматично обновление, има точно правата на кода, който сте прегледали в деня на инсталацията: пълен достъп до сайта и базата данни. Затова въпросът „кой публикува този плъгин сега и това ли са хората, които са го написали?“ заслужава да стои до номера на версията при всяка проверка. Изоставените плъгини са по-бавната версия на същия проблем — никой не е нужно да е злонамерен, за да се превърне неподдържан плъгин във входна точка. Работи не дългият списък, който никой не е чел от пускането насам, а кратък опис, който някой наистина поддържа; такъв опис е едно от нещата, за които съществува истинска договорка за поддръжка.
Разширения за браузър. Същият сценарий с изкупуване важи и за разширенията, а тук обхватът на пораженията включва всяка администраторска сесия, отворена в този браузър. Браузърът на разработчика често е най-слабо контролираната машина с достъп до вашата продукция — и единственото място, където за компрометиране не е нужна никаква стъпка на сглобяване.
Всичко, което се изтегля при сглобяване или при зареждане на страницата и не е пакет. Шрифтове, набори икони, фрагменти за аналитика и скриптове от CDN, заредени от чужд адрес, са зависимости без lock-файл: файлът зад този адрес може да се смени без никаква промяна на номер на версия и нищо във вашия процес няма да го забележи. Хостването им при вас затваря наведнъж два въпроса — за подмяната и за поверителността.
Общото е доверие, дадено веднъж и никога преразгледано. Всеки от тези канали някога е бил одобрен от някого, който вече не го гледа. Това е проблем на поддръжката, преоблечен като проблем на сигурността.
Какво променя това в начина, по който се строят сайтове
Две измествания вече се виждат и двете засягат по-скоро доставчиците, отколкото кода.
Броят зависимости вече е разход, а не неутрален факт. Рамка, която издърпва триста пакета, за да покаже сайт визитка, носи риск, какъвто по-простият стек няма. Този аргумент някога беше за теглото на страницата, а сега е за експозицията — съображение, което стои редом с тези от материала за какво се чупи в набързо генерираните сайтове, където зависимостите се трупат по-бързо, отколкото някой ги преглежда.
И средата за сглобяване вече е част от предаваната работа. Договор, който описва сайта, но не казва нищо за това къде се компилира, с какви достъпи и от кого, е пропуснал точно частта, в която се целят тазгодишните атаки. Дописването на тези три реда при подписа струва нула, а вграждането им по време на инцидент е почти невъзможно.
Накратко
- Августовската вълна на 2026 г. беше най-голямата досега, стигайки до
keyvи стотици свързани пакети за часове чрез саморазпространение. - Зловредният код се изпълнява при инсталация, не при работа на приложението, така че самото инсталиране е достатъчно.
- Ако сайтът ви има стъпка на сглобяване, вие сте в обхвата — включително много сайтове на WordPress с компилирани теми или персонализирани блокове.
- Мерките с най-висока стойност: среди за сглобяване за еднократна употреба, изключени install скриптове с кратък бял списък, комитнати lock файлове, отложени обновявания и никакви дълготрайни публикационни токени.
- npm отне класическите токени през декември 2025 г. и ограничи гранулираните токени с права за запис до деветдесет дни; предвидената замяна е trusted publishing през CI.
- Ако сте засегнати, първо ротация, после разследване, след това чисто пресглобяване и търсене на хранилища, ключове и сътрудници, които не сте създавали.








