Атака на Packagist: слепая зона смешанных PHP-сборок

Что произошло#

The Hacker News сообщил о скоординированной атаке на цепочку поставки, затронувшей восемь пакетов на Packagist — основном репозитории пакетов для проектов PHP Composer.

По данным The Hacker News со ссылкой на Socket, пакеты изменили: в них добавили вредоносный код, который должен был скачать и запустить Linux-бинарник по URL из GitHub Releases.

Важная деталь — место, куда вставили код. По словам Socket, вредоносный код добавили не в composer.json, привычный файл метаданных Composer, а в package.json.

Из-за этого меняется практическая модель риска. Речь о пакетах Composer, но вредоносный путь был нацелен на проекты, где рядом есть JavaScript-инструменты или связанные с ними workflow. Проще говоря: PHP-зависимость может стать проблемой через JavaScript-часть сборки или установки, если в проекте есть подходящие файлы и скрипты.

Публичное описание не подтверждает, сколько downstream-проектов реально выполнили код, во всех ли окружениях успешно скачался бинарник с GitHub и что именно он делал после запуска. Эти детали важны. Это стоит рассматривать как подтвержденный факт подмены пакетов, а не как доказательство, что каждая установка закончилась компрометацией.

Почему это важно#

Атаки на цепочку поставки часто срабатывают за счет неверных предположений. Команды могут проверять изменения в пакетах Composer через призму PHP и не заметить JavaScript-путь выполнения, лежащий рядом.

Именно в этом здесь слабое место. Затронутые пакеты находились в экосистеме Composer, но, по отчету, payload поместили в package.json. Для смешанных PHP- и JavaScript-проектов это реалистичная поверхность атаки. Многие приложения используют Composer для backend-зависимостей и npm, yarn, pnpm, build scripts или frontend-инструменты в том же репозитории.

Деталь с GitHub Releases тоже важна. Атакующие часто используют доверенные площадки хостинга, потому что исходящий трафик к ним выглядит обычным. Бинарник, скачанный по URL с GitHub, может легче пройти поверхностную проверку, чем файл с подозрительного домена. Это не делает GitHub причиной инцидента. Но после отравления пакета GitHub становится удобным каналом доставки.

Это еще одно напоминание: доверие к репозиторию не равно доверию к артефакту. Package manager разрешает и устанавливает то, что ему указали установить. Если поддерживаемый пакет изменили, передали другому владельцу, скомпрометировали или опубликовали с вредоносным содержимым, пользователь наследует этот риск — если в workflow нет проверок скриптов, lockfiles, provenance и поведения во время выполнения.

Что проверить#

Командам, которые используют Composer, не стоит ограничиваться composer.json, когда появляется сообщение об инциденте с зависимостью. Проверять нужно все содержимое пакета и любые файлы, которые могут запускать код в вашем окружении.

Практические проверки:

• Проверьте, встречается ли какой-либо из затронутых пакетов Packagist в ваших Composer lockfiles.
• Посмотрите недавние обновления зависимостей вокруг окна публикации отчета.
• Изучите содержимое установленных пакетов, а не только метаданные Composer.
• Ищите неожиданные скрипты package.json или lifecycle hooks в коде, поставляемом через vendor-зависимости.
• Проверьте build logs на скачивания из GitHub Releases, которые раньше не были известны и одобрены.
• Проверьте Linux-хосты и CI runners, которые устанавливают или собирают затронутые проекты.
• Если возможно, сравните содержимое пакетов с более ранними версиями, которые считались чистыми.

CI здесь особенно важен. Вредоносному бинарнику не обязательно сначала попасть на production-сервер. Build workers, test runners, release automation и staging-системы часто имеют учетные данные, сетевой доступ, а также пути к подписи или деплою. Поэтому они ценны для атакующего, даже если само приложение напрямую не выставлено наружу.

Чего не стоит утверждать без доказательств#

Доступное описание источника довольно узкое. В нем сказано, что затронуты восемь пакетов Packagist, а вредоносный код был вставлен в package.json, чтобы запустить Linux-бинарник из GitHub Releases.

Из предоставленного материала не следует, что эксплуатация широко прошла по всей экосистеме. В отрывке не названы затронутые пакеты. Нет подтвержденного числа жертв. Не описано полное поведение бинарника. Также не показано, что вредоносные скрипты запускались при любом сценарии установки.

Эти ограничения не формальность. У инцидентов с пакетами часто неровный blast radius. Отравленная зависимость может присутствовать, но ни разу не выполниться. Скрипт может запускаться только при определенных командах package manager. Linux-бинарник может не сработать на несовместимых системах. CI-среда может блокировать исходящие скачивания. Или ни одной из этих защит может не быть.

Правильная реакция — не паника, а инвентаризация и проверка.

Практический вывод#

Для разработчиков урок простой: проверка зависимостей должна идти по путям выполнения, а не по ярлыкам экосистемы.

Если пакет Composer содержит JavaScript-метаданные, относитесь к ним как к активному риску. Если установка пакета может скачать и запустить бинарник, место скачивания, hash и контекст выполнения становятся важными для безопасности. Если build-система имеет доступ в интернет и к секретам, считайте ее частью production-поверхности атаки.

Для maintainers это еще один повод держать release-процессы под жестким контролем: защищать publisher accounts, проверять содержимое пакетов перед публикацией, отслеживать неожиданные добавления файлов и не поставлять install scripts, которые создают лишние пути выполнения.

Для пользователей самый безопасный первый шаг — проверить, есть ли затронутые пакеты в вашем графе зависимостей, а затем изучить поведение сборки и установки. Опасность этого отчета не только в том, что пакеты изменили. Опасность в том, что маршрут payload может лежать там, куда PHP-команды смотрят реже.