Что произошло и почему это важно
22-23 мая 2026 года в PHP-сообществе появился серьезный инфоповод: исследователи сообщили о supply chain-атаке на сторонние пакеты Laravel-Lang, которые распространяются через Composer и Packagist. Это не уязвимость самого фреймворка Laravel, а компрометация популярной экосистемной зависимости для переводов и локализации. Для бизнеса разница формальная: если пакет попал в проект через `composer install` или `composer update`, риск оказывается внутри рабочего контура приложения, CI/CD и серверов.
По открытым разборам, атака была опасна не только тем, что затронула известные пакеты. Важнее механизм: злоумышленники использовали перепривязку git-тегов, из-за чего привычная версия пакета могла указывать не туда, куда команда ожидала. Для разработчика это выглядит как обычное обновление зависимости. Для инфраструктуры это может стать запуском вредоносного кода через Composer autoload и утечкой секретов из окружения.
Если у компании есть Laravel-проект, личный кабинет, CRM, портал партнеров или интернет-магазин на PHP, такой инцидент нельзя закрывать фразой «нас это, наверное, не касается». Нужно быстро проверить факты: есть ли Laravel-Lang в `composer.lock`, когда выполнялся деплой, откуда взяты пакеты, какие секреты могли быть доступны процессу и какие следы остались в логах.
Какие проекты в зоне риска
В первую очередь стоит проверить проекты, где используются пакеты `laravel-lang/lang`, `laravel-lang/http-statuses`, `laravel-lang/attributes` или связанные зависимости Laravel-Lang. Сам факт наличия пакета еще не доказывает компрометацию, но является поводом для аудита. Особенно внимательно нужно смотреть на окружения, где после 22 мая 2026 года запускались свежие `composer install`, `composer update`, сборки Docker-образов или CI jobs с очисткой vendor/cache.
Риск выше, если сборка выполнялась с доступом к `.env`, production-переменным, токенам GitHub, ключам облачного хранилища, SMTP, платежным интеграциям, Redis, S3, очередям или приватным Composer-репозиториям. В типовой поддержке Laravel-сайта эти данные часто лежат рядом: код обновляется в CI, деплой получает секреты окружения, приложение стартует с автозагрузчиком Composer, а логи размазаны между сервером, контейнером и внешними сервисами.
Отдельная проблема в том, что многие компании считают `composer.lock` достаточной защитой. Lock-файл действительно фиксирует версии и ссылки, но при атаке на теги и источники пакетов его одного мало. Нужно смотреть конкретные reference/hash, содержимое установленного `vendor`, историю cache Composer, время деплоя и то, откуда именно был скачан архив или исходники.
Быстрая проверка за первый час
Начать стоит с инвентаризации. В каждом репозитории проверьте `composer.json` и `composer.lock` на наличие пакетов Laravel-Lang. Затем сопоставьте это с календарем деплоев: были ли установки зависимостей 22 мая 2026 года и позже, запускались ли ночные сборки, пересобирались ли Docker-образы, чистился ли Composer cache, поднимались ли новые staging или production-контейнеры.
Дальше проверьте установленный код. В `vendor` не должно быть неожиданных файлов, которые выполняются через `autoload.files`, особенно если они не совпадают с проверенным состоянием пакета. Полезно сравнить содержимое зависимости с чистой доверенной копией, проверить `composer show -t`, `composer validate`, `composer audit`, а также сохранить копии подозрительных файлов до удаления, если есть признаки инцидента. Удалять следы до первичного анализа рискованно: можно потерять источник для понимания масштаба.
Параллельно посмотрите логи CI/CD. Нужны не красивые отчеты, а точные ответы: какой job запускался, под каким пользователем, какие переменные были доступны, какие внешние соединения были разрешены, попадали ли в сборку production-секреты. Если деплой выполнялся вручную с рабочего компьютера разработчика, проверьте и локальную машину: такие атаки часто бьют не только по серверу, но и по цепочке сборки.
Что делать, если пакет мог быть установлен
Если есть вероятность установки скомпрометированной версии, не ограничивайтесь `composer update`. Сначала заморозьте деплой и зафиксируйте текущее состояние: lock-файл, список пакетов, логи установки, список переменных окружения без раскрытия значений, сетевые логи и время последних сборок. Затем пересоберите окружение из доверенного источника, очистите Composer cache и проверьте, что зависимость больше не тянет подозрительный код.
Следующий шаг — ротация секретов. В Laravel-проекте это не только пароль к базе. Обычно нужно оценить `APP_KEY`, доступ к БД, Redis, очередям, S3 или совместимому хранилищу, SMTP, API платежных систем, CRM, webhook-секреты, GitHub/GitLab tokens, deploy keys, SSH-ключи, OAuth credentials и токены мониторинга. Менять `APP_KEY` нужно аккуратно: он влияет на шифрованные данные, cookies и сессии, поэтому для production лучше заранее понимать последствия и подготовить окно работ.
После ротации проверьте приложение на вторичные изменения: новые cron-задачи, неизвестных пользователей, модифицированные `.php` файлы вне vendor, странные исходящие запросы, новые SSH-ключи, web shell, изменения `.htaccess` или nginx-конфигурации. Для интернет-магазина и личного кабинета дополнительно проверьте платежные callback, формы авторизации, выгрузки заказов и интеграции с CRM.
Почему это не обычное обновление Laravel
Обычное обновление фреймворка закрывает известную версию и проверяет совместимость кода. Инцидент с цепочкой поставки требует другого подхода: нужно восстановить доверие к процессу сборки. Если проект просто «починили на сервере», но CI продолжает ставить зависимости из неконтролируемого источника, проблема может вернуться при следующем деплое.
Для зрелой поддержки Laravel-проекта после такого случая стоит ввести несколько правил. Зависимости должны обновляться через pull request и проверку lock-файла, Composer plugins и scripts должны быть осознанно разрешены, production-секреты не должны попадать в сборочные jobs без необходимости, а CI должен иметь минимальные права. Плюс нужен регулярный аудит зависимостей: Composer, npm-пакеты фронтенда, Docker base images, GitHub Actions и сторонние SDK. Laravel-приложение редко живет только в PHP-коде, поэтому смотреть нужно на всю цепочку поставки.
Техническая поддержка сайта в такой ситуации ценна не количеством часов, а дисциплиной. Команда должна быстро отличить ложную тревогу от реального риска, не сломать production поспешной ротацией, оставить понятный отчет и закрыть слабые места процесса. Это особенно важно для проектов, где сайт связан с заявками, оплатами, личными кабинетами, CRM или мобильным API.
Как OpenStart может помочь
OpenStart подключается к таким задачам как к техническому аудиту и аварийной поддержке. Мы проверяем Composer-зависимости и lock-файлы, оцениваем историю деплоев, смотрим CI/CD, помогаем пересобрать окружение из доверенных источников и составить план ротации секретов без лишнего простоя. Если проект на Laravel давно не обновлялся, параллельно можно оценить версию PHP, состояние пакетов, очереди, кеш, права на сервере и безопасность интеграций.
Для бизнеса результат должен быть практичным: понятно, затронут ли проект, какие действия уже выполнены, какие секреты поменяны, где остался риск и как не повторить проблему. После первичного восстановления полезно перейти к регулярной поддержке: обновления зависимостей по регламенту, проверка Composer и npm, мониторинг ошибок, резервные копии, тестовый стенд и понятная очередь доработок.
Если у вас Laravel-сайт, CRM или личный кабинет и вы не уверены, запускался ли Composer после 22 мая 2026 года, лучше проверить это сейчас. Чем раньше найден риск в цепочке поставки, тем меньше вероятность, что обычная зависимость превратится в простой, утечку доступов или срочное восстановление сайта в самый неудобный момент.