Что произошло и почему это важно
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 года, лучше проверить это сейчас. Чем раньше найден риск в цепочке поставки, тем меньше вероятность, что обычная зависимость превратится в простой, утечку доступов или срочное восстановление сайта в самый неудобный момент.