Атака на цепочку поставок Laravel-Lang: злоумышленники переписали все теги четырёх популярных пакетов

Уникальность этой атаки в том, что вредоносный код никогда не появлялся в основной ветке репозиториев. GitHub позволяет указывать теги на коммиты из любого форка того же репозитория. Этим и воспользовался атакующий. Он создал в своём форке коммиты с одинаковой структурой: добавлялся файл src/helpers.php и изменялся composer.json. После этого все старые теги принудительно перемещались (force push) на эти новые коммиты. Подпись автора во всех случаях - "Your Name" с адресом you@example.com, что указывает на использование одного и того же скомпрометированного токена.

Механизм заражения оказался крайне простым и эффективным. В composer.json в секцию autoload.files была добавлена запись, указывающая на src/helpers.php. Эта секция загружается не лениво (как PSR-4 или classmap), а сразу при вызове require vendor/autoload.php. Поскольку любое приложение на Laravel или Symfony выполняет этот вызов при старте, полезная нагрузка запускается автоматически. Никаких дополнительных действий пользователя не требуется.

Специалисты компании StepSecurity в своём отчёте детально описали цепочку заражения. Код в src/helpers.php - это дроппер, который скачивает второй этап с домена flipboxstudio.info (очевидный тайпсквот легитимного flipboxstudio.com). Дроппер записывает скрытый PHP-загрузчик в каталог /tmp/.laravel_locale/<12 hex chars>.php, а затем запускает его в фоновом режиме. Тот, в свою очередь, скачивает исполняемый ELF-файл без расширения в /tmp/.<8 hex chars> и запускает его. Через несколько секунд оба файла удаляются с диска, оставляя лишь процессы, которые переходят к init (ppid=1) и продолжают работу в памяти.

Полная детонация одного из пакетов (laravel-lang/http-statuses v3.4.5) в изолированном окружении GitHub Actions показала, что весь процесс от автозагрузки до самоуничтожения занимает около трёх секунд. Сеть фиксирует два HTTPS-запроса: GET к /payload и POST к /exfil. Второй запрос уносит собранные учётные данные.

Что именно похищает второй этап? Это примерно 5900 строк PHP-кода, организованных в пятнадцать модулей сборщика. Они сканируют окружение и файловую систему в поисках:

• облачных учётных данных (AWS, GCP, Azure, DigitalOcean, Heroku, Vercel и других);
• конфигураций инфраструктуры (kubeconfig, Vault-токены, Docker config.json);
• ключей разработчика (SSH-ключи, .git-credentials, .netrc, .npmrc, .composer/auth.json);
• паролей из браузеров на основе Chromium, Firefox, а также KeePass, 1Password, Bitwarden;
• файлов криптовалютных кошельков (Bitcoin, Ethereum, Monero и многих других);
• токенов коммуникационных платформ (Slack, Discord, Telegram);
• конфигураций VPN (NordVPN, ExpressVPN, WireGuard и так далее).

Все собранные данные шифруются алгоритмом AES-256 и отправляются на сервер атакующего.

После совершения атаки исследователи связались с мейнтейнерами Laravel-Lang и сообщили об инциденте через security-issue в каждом из четырёх репозиториев. Packagist оперативно отреагировал: вредоносные версии были удалены, а затронутые пакеты временно скрыты из выдачи, чтобы предотвратить новые установки. Тем не менее, любой проект, который выполнял composer install или composer update после 22:32 UTC 22 мая 2026 года, мог получить скомпрометированные теги.

Основная опасность заключается в том, что перезапись затронула все теги, включая старые. Поэтому сегодня невозможно безопасно зафиксировать версию через диапазон (например, ^3.4 или ~2.0) - любой вызов composer update приведёт к загрузке отравленного коммита. Единственный способ убедиться в безопасности - проверить SHA коммита, закреплённого в composer.lock, и сравнить его с известными "чистыми" значениями, полученными из клона до атаки или из зеркала Packagist. Если lock-файл не обновлялся после 22 мая, проект остаётся защищён.

Администраторам, которые подозревают компрометацию, необходимо:

• немедленно остановить выполнение composer update и composer install без проверенного lock-файла;
• проверить composer.lock на предмет попадания SHA из списка скомпрометированных коммитов;
• если установка произошла после указанной даты - считать все секреты, доступные в этом окружении (GITHUB_TOKEN, облачные ключи, пароли и т. д.), скомпрометированными и заменить их;
• проверить рабочие станции и CI-раннеры на наличие процессов php и безымянных ELF-процессов с ppid=1, а также артефактов в /tmp (каталог .laravel_locale и файл .<8 hex chars>), хотя они удаляются в течение нескольких секунд;
• добавить домен flipboxstudio.info в блок-листы DNS и межсетевых экранов.

Для организаций, использующих инструменты контроля целостности (например, Harden Runner от StepSecurity), поиск HTTPS-вызовов к flipboxstudio.info в журналах детонаций даст точный ответ о факте заражения.

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

Domains

• flipboxstudio.info

URLs

• flipboxstudio.info/exfil
• flipboxstudio.info/payload