Laravel-Lang: вредоносный код спрятали в release tags

Что известно#

Несколько PHP-пакетов организации Laravel-Lang, по сообщениям, были скомпрометированы в атаке на цепочку поставки ПО. Пользователям доставляли кроссплатформенный стилер учетных данных.

The Hacker News ссылается на исследования Socket, StepSecurity и Aikido Security. Среди затронутых пакетов Laravel-Lang указан laravel-lang/http-statuses; при этом The Hacker News описывает кампанию как нацеленную на несколько пакетов, принадлежащих Laravel-Lang.

Главная деталь не только в том, что вредоносный код попал в релизы пакетов. Важно, как именно он туда попал.

По данным Socket, исходный код проекта не меняли обычным способом. Вместо этого атакующий, предположительно, переписал существующие git tags в каждом репозитории так, чтобы они указывали на новый вредоносный commit. Эти переписанные tags добавляли вредоносный файл src/helpers.php в опубликованные версии.

Socket сообщила, что выявила более 700 версий, связанных с затронутыми пакетами. Tags публиковались быстро 22 и 23 мая 2026 года, многие версии появлялись с разницей всего в несколько секунд. Socket считает такой темп и паттерн признаком более широкого компромисса release-процесса организации Laravel-Lang, а не одним изолированным вредоносным релизом.

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

Почему опасна автозагрузка Composer#

Вредоносный файл, по сообщениям, добавили в карту Composer autoload.files.

Это ключевой риск.

В PHP-приложениях, которые используют Composer, файлы из autoload.files загружаются автоматически, когда приложение подключает autoloader Composer. В Laravel это обычно происходит при старте через vendor/autoload.php. Тот же механизм используют и другие PHP-фреймворки и инструменты.

StepSecurity описала эффект прямо: Laravel-приложения загружают autoloader Composer при старте, Symfony, PHPUnit и многие другие PHP-проекты делают то же самое, поэтому payload может выполниться без вызова класса, метода или специального маршрута разработчиком.

Это опаснее, чем вредоносная функция, спрятанная в редко используемом API. Скомпрометированная зависимость с автозагружаемым файлом может выполниться во время обычного запуска.

Socket сообщила, что backdoor создает уникальную метку для хоста через MD5-хеш, составленный из пути к директории, архитектуры системы и inode. Заявленная цель — сработать только один раз на машине. Это снижает число повторных запусков и может усложнить обнаружение после первого выполнения.

Затем dropper обращается к flipboxstudio[.]info, чтобы получить payload на PHP. Aikido Security описала его как стилер учетных данных примерно на 5 900 строк, разбитый на пятнадцать модулей-сборщиков. После сбора данные, по сообщениям, шифруются AES-256 и отправляются на flipboxstudio[.]info/exfil, после чего payload удаляет себя с диска, чтобы сократить следы для форензики.

На Windows, по данным Aikido, dropper доставляет launcher на Visual Basic Script и запускает его через cscript. На Linux и macOS стилер запускается через exec().

В итоге это PHP-инцидент в цепочке поставки, который выходит за границы одной операционной системы и одного runtime. Вредоносный пакет устанавливается как PHP-зависимость, но целевые данные находятся на рабочих станциях разработчиков, CI runners, в cloud-средах и на application hosts.

Что, по сообщениям, собирал стилер#

Заявленный охват сбора широкий. Цель — не один секрет приложения, а рабочая среда вокруг современной доставки ПО.

В исходных материалах перечислены попытки собрать, среди прочего:

• Cloud metadata, включая IAM roles и документы identity для instance.
• Учетные данные Google Cloud application default credentials.
• Microsoft Azure access tokens и профили service principal.
• Kubernetes service account tokens и конфигурацию Helm registry.
• Tokens для платформ вроде DigitalOcean, Heroku, Vercel, Netlify, Railway и Fly.io.
• CI/CD- и deployment-учетные данные из Jenkins, GitLab Runners, GitHub Actions, CircleCI, TravisCI и ArgoCD.
• Docker auth tokens, приватные SSH-ключи, Git credentials, файлы .env, историю shell, историю баз данных, конфигурацию Kubernetes, wp-config.php и docker-compose.yml.
• Учетные данные source control из файлов .gitconfig, .git-credentials и .netrc.
• Данные браузеров, cookies, сохраненные логины и данные браузерных расширений.
• Vault-файлы или данные расширений менеджеров паролей, включая 1Password, Bitwarden, LastPass, KeePass, Dashlane и NordPass.
• Файлы криптокошельков и материалы seed phrase, связанные с кошельками и расширениями, включая Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow, MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare и Rabby.
• Сохраненные сессии PuTTY и WinSCP, данные Windows Credential Manager, учетные данные FTP-клиентов и session tokens для приложений вроде Discord, Slack и Telegram.
• VPN-конфигурацию и файлы сохраненных логинов для OpenVPN, WireGuard, NetworkManager и коммерческих VPN, перечисленных в отчетах.

Ширина этого списка важна. Если публикации точны, речь не просто о компромиссе web-приложения. Это попытка pivot в cloud-аккаунты, CI/CD-системы, source control, кошельки, хранилища паролей и developer endpoints.

Один зараженный build host или компьютер разработчика может хранить учетные данные, которые переживут установку вредоносного пакета.

Чего нельзя утверждать сверх фактов#

Публичные материалы не доказывают, как атакующий получил доступ.

Быстрая публикация tags указывает на автоматизацию или компромисс release-процесса, но сама по себе не раскрывает initial access vector. Это могли быть учетные данные организации. Это могла быть скомпрометированная автоматизация. Это могла быть release-инфраструктура. Исходные материалы не закрывают этот вопрос.

Также отчеты не устанавливают, сколько downstream-приложений установили скомпрометированные версии, сколько систем выполнили payload и сколько данных было успешно exfiltrated.

Эти различия важны. Вредоносная версия пакета — это exposure. Выполнение зависит от того, был ли пакет установлен или обновлен в уязвимое окно и запустился ли вредоносный autoload-файл в реальной среде. Exfiltration зависит от доступности сети, содержимого хоста, прав и средств обнаружения или блокировки.

Командам стоит относиться к инциденту серьезно, но не добавлять уверенность там, где ее нет в доказательствах.

Что проверить командам сейчас#

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

Проверьте composer.lock, build logs, metadata артефактов, записи dependency cache и журналы package manager на наличие пакетов Laravel-Lang, установленных или обновленных около 22–23 мая 2026 года. Не ограничивайтесь текущими source branches. Если tags были переписаны, local caches, CI caches и собранные containers могут хранить скомпрометированный artifact даже после исправлений upstream.

Затем проверьте установленные vendor trees там, где это применимо. Ищите неожиданные файлы src/helpers.php в пакетах Laravel-Lang и смотрите, включен ли этот файл в autoload.files внутри composer.json пакета.

Полезна и сетевая телеметрия. Ищите в DNS, proxy, EDR и firewall logs обращения к:

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

Любое подтвержденное выполнение нужно рассматривать как инцидент с учетными данными, а не только как задачу по удалению malware.

Это значит: ротировать раскрытые секреты. В приоритете cloud access keys, CI/CD tokens, Git credentials, deployment tokens, SSH keys, Kubernetes tokens, registry credentials, .env secrets и любые учетные данные, находившиеся на затронутых машинах разработчиков или build hosts.

Для CI-систем по возможности инвалидируйте runner tokens и проверьте недавнее поведение pipelines. Для cloud-аккаунтов проверьте использование metadata-derived identity, необычные API calls, новые service principals, подозрительные access keys и неожиданные изменения ресурсов. Для source control проверьте deploy keys, personal access tokens, GitHub Actions secrets, GitLab variables и недавнюю активность с tags или releases.

Наконец, сохраните доказательства до переустановки или очистки систем. Payload, по сообщениям, удаляет себя после exfiltration, поэтому артефактов на диске может быть мало. Composer caches, container layers, CI workspaces, package lockfiles, proxy logs и endpoint telemetry могут оказаться самыми полезными источниками.

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

Этот инцидент показывает: release metadata входит в границу доверия.

Разработчики часто читают исходный код и считают tags стабильными указателями на этот код. В этом случае, по сообщениям, атакующий путь использовал tags и поведение Composer autoload. Видимые исходники проекта были не единственным важным объектом. Release object, который потребляют package managers, оказался важнее.

Для PHP-команд ближайший урок простой: компромисс зависимости может выполнить код при старте приложения. Для platform-команд вывод жестче: учетные данные на машинах разработчиков и CI runners — это production assets. Если зависимость может их прочитать, dependency chain входит в production attack surface.