Laravel Lang: как теги пакетов подменяют доверие

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

Snyk сообщает, что злоумышленник заново опубликовал сотни вредоносных исторических версий для четырех поддерживаемых сообществом пакетов локализации Laravel в пространстве имен laravel-lang на Packagist.

Активность пришлась на 22 и 23 мая 2026 года. По ранним подсчетам исследователей, число отравленных версий было около 233. По данным Snyk, текущие отчеты говорят примерно о 700 исторических версиях в затронутых пакетах: злоумышленник продолжал публиковать теги.

Эти пакеты используют Laravel-приложения для строк перевода, сообщений валидации, описаний HTTP-статусов, имен атрибутов и локализованных строк в стиле действий. Это пакеты сообщества, а не часть официального Laravel framework, но они могут находиться глубоко в обычных деревьях зависимостей Laravel-приложений.

Snyk называет четыре затронутых пакета laravel-lang, включая:

• laravel-lang/lang
• laravel-lang/http-statuses
• laravel-lang/attributes
• laravel-lang/actions

По данным advisory, Packagist снял пакеты с публичного листинга на время исправления.

Главное: вредоносные релизы появились не из коммитов, отправленных в официальные исходные репозитории. Злоумышленник использовал сам механизм публикации пакетов.

Как сработала компрометация#

Злоумышленник воспользовался тем, как Packagist разрешает GitHub-теги.

По данным Snyk, Git-тег, созданный внутри организации, может указывать на коммит во внешнем fork за пределами этой организации. Packagist принял такие теги и обработал коммиты из fork как релизы официальных пакетов.

Это важно, потому что Composer устанавливает пакеты на основе метаданных Packagist. Если новая установка разрешала одну из вредоносных исторических версий, она могла подтянуть код из fork под контролем атакующего, хотя в официальном репозитории не было соответствующего вредоносного изменения.

Именно поэтому инцидент полезен не только для Laravel-сообщества. Многие команды до сих пор воспринимают версию пакета как стабильный факт. Здесь исторические release-теги были опубликованы заново, но уже с другим кодом за ними. Слабым местом оказался не только код пакета, а вся цепочка, которая связывает имена, теги, репозитории и поведение установки в объект доверия для build-системы.

Что делал payload#

Вредоносный код добавили через файл src/helpers.php.

Этот файл подключался в Composer через composer.json в секции autoload.files. Composer автоматически требует файлы, перечисленные там. На практике это значит, что вредоносный PHP мог запускаться на раннем этапе жизненного цикла приложения сразу после установки пакета.

Snyk пишет, что внедренная первая стадия была легковесной. Она создавала маркер заражения во временной директории конкретного хоста, чтобы не заражать один и тот же хост повторно. Затем она обращалась к:

• https://flipboxstudio[.]info/payload

Загруженная вторая стадия запускалась в фоне. Snyk описывает launcher как кроссплатформенный: в нем была логика для Linux, macOS и Windows.

Вторая стадия была стилером учетных данных и секретов. В advisory сказано, что она искала, среди прочего:

• cloud-учетные данные и profile-файлы провайдеров вроде AWS, GCP и Azure
• Kubernetes kubeconfig-файлы
• токены HashiCorp Vault
• CI/CD-секреты из окружения
• приватные SSH-ключи
• application .env-файлы
• учетные данные баз данных, API и сервисов
• cookies браузеров, историю и сохраненные логины
• vault-файлы менеджеров паролей, доступные на диске
• файлы и keystore криптовалютных кошельков
• messaging-токены для инструментов вроде Slack, Discord и Telegram

Собранные данные шифровались и отправлялись на:

• https://flipboxstudio[.]info/exfil

После exfiltration стилер пытался удалить сброшенные файлы, чтобы усложнить восстановление и анализ. На Windows-системах, по данным Snyk, на зараженных хостах наблюдались launcher script и исполняемый артефакт app.exe.

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

Это не узкая проблема библиотеки переводов.

Пакеты локализации часто выглядят низкорисковыми: от них ждут текстовые ресурсы, а не чувствительные пути выполнения. Но в Composer зависимость может зарегистрировать autoloaded files. После этого пакет, который внешне поставляет языковые строки, может выполнять PHP внутри runtime приложения, CLI-команд, workers и queue handlers.

Инцидент также показывает, почему при supply-chain-событии фразы «репозиторий GitHub выглядит чистым» недостаточно. Snyk говорит, что отравленные релизы не происходили из официальных исходных репозиториев. Путь атаки находился на уровне тегов и разрешения пакетов.

Это меняет incident response. Командам нельзя ограничиваться просмотром текущего upstream-репозитория. Нужно проверить, что именно установили их системы, когда это произошло, какие версии были разрешены и обращался ли какой-либо хост к опубликованному command-and-control-домену.

Самая жесткая операционная рекомендация Snyk проста: каждую среду, которая подтянула одну из затронутых версий Laravel localization packages, нужно считать скомпрометированной, пока не доказано обратное.

Что проверить сейчас#

Начните с уровня зависимостей.

Проверьте composer.lock и dependency manifests во всех Laravel-проектах на ссылки на затронутые пакеты laravel-lang. Особое внимание — установкам и сборкам, которые разрешали версии пакетов 22 и 23 мая 2026 года.

Затем проверьте содержимое установленных пакетов. Ищите src/helpers.php и записи Composer autoload, которые подключают его через autoload.files. Наличие такого пути в затронутом пакете нужно считать серьезным сигналом, а не безобидным helper-файлом.

Ищите в сетевой и процессной телеметрии опубликованные индикаторы:

• исходящие запросы к flipboxstudio[.]info
• запросы к /payload или /exfil на этом домене
• фоновое выполнение PHP вскоре после Composer install или старта приложения
• выполнение cscript на Windows в таком контексте
• чтение из /var/run/secrets/
• чтение из /proc/*/environ
• подозрительный доступ к .env, SSH, cloud, browser, wallet или password-manager файлам

На Windows-хостах ищите наблюдавшийся исполняемый артефакт app.exe в местах, похожих на поведение сброшенного malware.

Если хост разрешил одну из вредоносных версий, не останавливайтесь на удалении пакета. Payload, описанный Snyk, предназначен для кражи учетных данных. Значит, исправление должно включать ротацию секретов и расследование последующего доступа.

Как минимум командам стоит рассмотреть ротацию:

• cloud access keys и service-account credentials
• Kubernetes credentials
• Vault tokens
• CI/CD secrets
• SSH-ключей, присутствовавших на затронутых хостах
• application secrets из .env-файлов
• credentials баз данных и API
• messaging и collaboration tokens

Точный объем ротации зависит от того, к чему хост мог получить доступ. Build-серверы, рабочие станции разработчиков, CI runners и production-ноды приложений имеют разные blast radius. Оценивайте каждый хост по секретам, которые он мог прочитать, а не только по установленному пакету.

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

В advisory сказано, что расследование Laravel-Lang maintainers, Packagist, Snyk и внешних исследователей продолжается. Это важно.

Не надо считать, что затронуто каждое Laravel-приложение. Проблема связана с конкретными community packages и конкретными разрешенными версиями. Не надо считать, что был скомпрометирован официальный Laravel framework. Snyk явно отделяет эти поддерживаемые сообществом localization libraries от Laravel core.

Также не надо считать, что чистый текущий репозиторий доказывает безопасность. Описанная атака использовала теги и разрешение Packagist, а не вредоносные коммиты в официальных исходных репозиториях.

Практическая позиция уже и жестче: если ваша среда установила одну из затронутых версий пакетов laravel-lang в релевантное окно, считайте систему подозрительной, пока не проверены логи, состояние пакетов и возможная утечка credentials.

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

Этот инцидент напоминает: package managers распространяют не только код. Они распространяют решения о доверии.

Имя зависимости, Git-тег, релиз Packagist и Composer install — разные объекты. Когда они расходятся, upstream-проект, который выглядит чистым, все равно может доставить в реальную систему враждебный код.

Для команд на Laravel срочная задача — проверить зависимости, поискать индикаторы и ротировать credentials там, где возможна экспозиция.

Для команд, работающих с любой языковой экосистемой, более широкий урок такой: за метаданными пакетов и происхождением релизов нужно следить так же серьезно, как за исходными коммитами. В этом случае source tree был не единственным местом, где произошла атака.