В npm выявили пакеты с червём, заражающим проекты через SSH-ключи
Исследователи SafeDep выявили девять npm-пакетов со встроенным самораспространяющимся Linux-червём. Пакеты были опубликованы аккаунтом dirtyblanket за 33 минуты 29 сентября 2026 года: вредонос использует SSH-ключи разработчика, записи known_hosts и токены npm, чтобы проникать в другие окружения и распространять себя через новые версии пакетов.
В той же подборке инцидентов StepSecurity сообщила о компрометации npm-пакета @subql/common версии 5.8.3. В него была добавлена скрытая нагрузка для сбора учётных данных и удалённого доступа; она запускается при установке и импорте пакета и ориентирована на рабочие станции разработчиков, CI-среды, GitHub Actions runners и доступные облачные сервисы.
Как распространяется червь
По данным SafeDep, червь устанавливает бэкдор systemd-fontd, выдавая его за службу шрифтов systemd. Это открытый инструмент удалённого доступа CHAOS: через сеть Tor он предоставляет оператору командную оболочку, доступ к файлам и возможность делать снимки экрана.
Для дальнейшего распространения вредонос перебирает все приватные SSH-ключи на машине, подключается с ними к хостам из файла known_hosts и запускает там собственную копию. Если ключи дают право публиковать пакеты в Arch User Repository, червь добавляет себя и в эти пакеты.
Отдельный механизм задействует токены npm, найденные на заражённой системе. С их помощью программа публикует новые версии пакетов разработчика уже с вредоносным кодом. Таким образом, компрометация одной рабочей станции может затронуть как связанные серверы, так и цепочку поставки программного обеспечения.
Другие вредоносные зависимости
SafeDep также зафиксировала аккаунт RubyGems reqthrottle_3474, разместивший 42 вредоносных gem-пакета, преимущественно для разработчиков криптовалютного ПО. В CI и песочницах они не выполняют активных действий, однако на машине разработчика выжидают от 20 до 40 минут.
После задержки 11 пакетов открывают обратную оболочку, а 31 загружает архив wgkit.tar.gz и запускает скрипт wg_install.sh. Такое разделение поведения затрудняет обнаружение при поверхностной проверке зависимостей и автоматических сборках.
Что проверить компаниям
Командам разработки стоит проверить журналы публикаций npm и AUR, инвентаризировать используемые зависимости и отозвать токены npm, доступные на рабочих станциях или в CI. Не менее важно пересмотреть SSH-ключи, права на публикацию и список доверенных хостов: именно эти данные червь использует для перехода в другие среды.
Инцидент показывает, что защита цепочки поставки требует контроля не только исходного кода пакетов, но и секретов разработчиков, которые позволяют вредоносной зависимости продолжить распространение за пределами одной машины.