Инцидент короткий по времени и показательный по механике. Гем strutil-core версии 1.0.1 опубликовали 1 ноября в 04:05 UTC. Через 70 секунд его пометили как вредоносный, но фактически удалили только в 09:13 — то есть около пяти часов пакет был доступен для установки.
Вредоносная логика срабатывала при установке, а не при вызове библиотеки. Это важная деталь: gem install в CI-пайплайне или на машине разработчика — уже достаточный триггер, даже если код потом не используется.
Что делал червь
По данным Socket, payload собирал учётные данные и токены, которые открывают доступ к сборочным конвейерам и облакам, и пытался распространяться дальше — через npm, PyPI, JFrog Artifactory, GitHub и GitLab, используя украденные SSH- и Git-креденшелы. Дополнительно он оставлял Python-бэкдор для закрепления.
Схема типичная для современного supply-chain: одна скомпрометированная машина разработчика превращается в способ отравить репозитории, утащить облачные секреты или изменить сборки. И для этого не нужен эксплойт — достаточно, чтобы пакет поставился.
Что делать
Если strutil-core 1.0.1 мог попасть в зависимости, считайте машину скомпрометированной: перевыпустите SSH-ключи, токены Git и доступы к реестрам, проверьте историю пушей и изменения в CI-конфигурациях за 1 ноября.
Отдельно стоит проверить lock-файлы: если версия зафиксирована в Gemfile.lock, установка могла повториться позже, даже после удаления гема из индекса — из кеша или зеркала.
The incident is short in duration and instructive in mechanics. Version 1.0.1 of the strutil-core gem was published on 1 November at 04:05 UTC. It was flagged as malicious 70 seconds later, but actually removed only at 09:13 — so the package was installable for about five hours.
The malicious logic ran at install time, not when the library was called. That detail matters: gem install in a CI pipeline or on a developer machine is already a sufficient trigger, even if the code is never used.
What the worm did
According to Socket, the payload harvested credentials and tokens that unlock build pipelines and clouds, and tried to spread further — through npm, PyPI, JFrog Artifactory, GitHub and GitLab — using stolen SSH and Git credentials. It also left a Python backdoor for persistence.
The pattern is typical of modern supply-chain attacks: one compromised developer machine becomes a way to poison repositories, steal cloud secrets or tamper with builds. No exploit is required — the package only has to be installed.
What to do
If strutil-core 1.0.1 could have entered your dependencies, treat the machine as compromised: reissue SSH keys, Git tokens and registry credentials, and review push history and CI configuration changes for 1 November.
Check lock files as well: if the version is pinned in Gemfile.lock, installation may have repeated later, even after the gem was pulled from the index — from a cache or a mirror.