Кампанія з шкідливими postinstall-хуками зачепила Packagist і проєкти на GitHub: код у метаданих пакета завантажував Linux-пейлоад із GitHub Releases. Для читачів Gridinsoft головний ризик не лише в конкретних пакетах. Небезпека в тому, що CI runner, сервер збірки або робоча станція розробника може виконати install-скрипт до того, як залежність помітять як шкідливу.
Кого це стосується?
Socket повідомила про кампанію 22 травня 2026 року та описала шкідливий postinstall hook у понад 700 репозиторіях GitHub, зокрема в PHP-пакетах на Packagist і Node.js-проєктах. The Hacker News окремо описали Packagist-частину як атаку на вісім пакетів і звернули увагу, що код був у package.json, а не в composer.json.
Це важлива деталь. PHP-проєкт може мати JavaScript-інструменти для фронтенду, тестів або збірки. Якщо перевірити лише Composer, небезпечний hook можна пропустити.
| Що зачеплено | GitHub-репозиторії, Packagist-пакети та Node.js-проєкти |
| Точка запуску | postinstall hook у package.json |
| Шлях пейлоада | Linux-бінарник із GitHub Releases |
| Кому перевіряти | Мейнтейнерам, адміністраторам CI, хостинг-командам і розробникам після нещодавніх install/rebuild |
| Що невідомо | Публічні звіти описують поведінку кампанії, але локальну експозицію треба підтверджувати за логами встановлення та історією репозиторію |
Це той самий тип проблеми довіри, який видно у випадках Laravel-Lang Composer credential stealer та Mini Shai-Hulud npm wave. Атакувальнику не обов’язково одразу ламати production, якщо install-процес має доступ до токенів збірки.
Що робити зараз
Почніть із машин, де реально виконувалися install-команди. Перевірте CI-логи, історію команд розробників, вивід npm lifecycle scripts і вихідні з’єднання до незвичних GitHub Release URL. Якщо runner зберігав токени, спершу ротуйте їх, а вже потім закривайте питання як просте очищення залежності.
У PHP-проєктах перевіряйте і composer.json, і package.json. Якщо є frontend tooling, Packagist-ризик не обмежується Composer metadata. Перегляньте свіжі оновлення залежностей, зміни lockfile і будь-який postinstall script, який прийшов не з вашого коду.
На shared hosting або self-managed серверах шукайте нові Linux-бінарники в директоріях проєкту, тимчасових папках і CI workspace. Підозрілі файли краще зберегти для аналізу, після чого перебудувати проєкт із чистого lockfile та довіреного джерела пакетів.
Незмінний номер релізу теж потребує перевірки: під час інциденту OVHcloud CLI 19 жовтня збережений SHA-256 виявив підмінені файли релізів GitHub, хоча тег коду не змінився. Перевіряйте сам завантажений файл, а не лише метадані пакета.
Пов’язана перевірка TrapDoor
Composer — не єдиний ризик package-manager екосистеми. TrapDoor використовує npm, PyPI і Crates.io пакети для крадіжки developer secrets та отруєння AI assistant context files.
FAQ
Чи всі Packagist-пакети тепер небезпечні?
Ні. Ризик стосується скомпрометованих або підкинутих пакетів і репозиторіїв. Але ця кампанія показує, що PHP-проєкти з JavaScript-інструментами треба перевіряти ширше.
Чи варто вимикати install scripts?
Під час термінової перевірки запуск install без lifecycle scripts може зменшити ризик, поки команда перевіряє залежності. Для постійного процесу краще дозволяти такі скрипти лише там, де зрозумілий пакет і шлях мейнтейнера. Іншу межу показують пакети npm із RedC2: програма для Linux запускається під час імпорту модуля, тому вимкнення скриптів встановлення не захищає наступні тести чи збірки.
Яка перша ознака експозиції?
Підозрілий postinstall, лог збірки із завантаженням бінарника з GitHub Releases або вихідні з’єднання runner під час встановлення залежностей.
Також по темі: після postinstall abuse варто переглянути й Megalodon у GitHub Actions, де шкідливі CI workflow ставлять під ризик repository secrets і package releases.
Джерела
- Socket Research Team, “Malicious Postinstall Hook Found Across 700+ GitHub Repositories, Including Packagist and Node.js Projects,” 22 травня 2026, оновлено 23 травня 2026. Звіт
- The Hacker News, “Packagist Supply Chain Attack Infects 8 Packages Using GitHub-Hosted Linux Malware,” 23 травня 2026. Публікація
Схожий захисний контекст: npm додав staged publishing та install-source controls, які допомагають мейнтейнерам перевіряти реліз до того, як пакет стане installable.
Схожий ланцюжок довіри: після postinstall malware у Packagist з’явилася кампанія з фейковими GitHub/SourceForge-завантаженнями Deno RAT. Читайте новину про Deno RAT у фейкових завантаженнях.
