Короткий ответ: что делать сейчас
Наличие Laravel-Lang в проекте еще не означает заражение. Но если после 22 мая 2026 года выполнялись composer install, composer update или пересборка контейнеров, сначала остановите новые деплои, сохраните логи и точное состояние зависимостей, а затем установите, какие версии и commit reference фактически попали в сборку.
Не начинайте с бездумного обновления пакетов и очистки
vendor. Это может уничтожить следы, по которым можно понять масштаб инцидента. Сначала зафиксируйте текущее состояние, после этого пересобирайте окружение из доверенного источника и планируйте ротацию доступов.
Что подтверждено к 12 сентября 2026 года
22 мая 2026 года в репозитории Laravel-Lang был зарегистрирован отчет о вредоносных тегах в пакетах laravel-lang/lang, laravel-lang/http-statuses и laravel-lang/attributes. В отчете описан добавленный файл src/helpers.php, который загружал и запускал внешний код. На странице laravel-lang/lang в Packagist на момент последней проверки также сохраняется предупреждение о версиях, отмеченных как вредоносные.
Это не уязвимость ядра Laravel и не доказательство того, что любой проект с Laravel-Lang заражен. Проверять нужно конкретную сборку: lock-файл, source reference, время установки, содержимое артефакта и доступные процессу секреты.
Сентябрьские изменения GitHub подтверждают, что защита цепочки поставки остается актуальной: платформа добавила отдельные ограничения доступа к кешу GitHub Actions, а npm распространил временную блокировку чувствительных операций после входа по recovery code на все учетные записи. Такие меры уменьшают отдельные риски, но не заменяют контроль внутри проекта.
Кому это актуально
Проверка нужна владельцам и техническим руководителям Laravel-проектов, если приложение связано с заявками, заказами, оплатой, CRM, личным кабинетом или мобильным API. Приоритет выше, когда нет точного журнала деплоев, сборка получает production-секреты или зависимости устанавливаются прямо на сервере.
Особенно внимательно стоит отнестись к ситуации, если:
- нужный пакет есть в
composer.lock, а после 22 мая выполнялась установка зависимостей; - пересобирались Docker-образы или очищался кеш Composer;
- CI/CD использовал ключи БД, хранилища, SMTP, платежей, CRM либо deploy key;
- после релиза появились неизвестные файлы, процессы, исходящие соединения или новые учетные записи;
- команда не может воспроизвести сборку и подтвердить происхождение каждого артефакта.
Если пакет отсутствует, спорных деплоев не было, а сборки воспроизводимы и изолированы от рабочих секретов, внутренней проверки по чек-листу обычно достаточно.
Какие риски закрывает проверка
Главный риск — не только вредоносный файл в vendor. Код зависимости мог выполниться во время сборки или автозагрузки и получить доступ к переменным окружения. Тогда простой замены пакета недостаточно: скомпрометированный токен продолжит работать и после очистки файлов.
В зоне внимания могут оказаться доступы к базе данных, Redis и очередям, объектному хранилищу, SMTP, CRM, платежным API, GitHub или GitLab, мониторингу и серверу. Перечень нужно строить по фактическим правам процесса, а не по универсальному списку.
Есть и второй риск — потеря доказательств. Если сразу удалить vendor, очистить кеш и перезапустить сервер, станет сложнее установить, какой код выполнялся, когда это произошло и какие секреты требовали замены.
Безопасная проверка проекта
1. Зафиксируйте состояние до изменений
Сохраните composer.json, composer.lock, список установленных пакетов, журналы Composer и CI/CD, идентификатор Docker-образа и время последних деплоев. Значения секретов копировать в отчет не нужно: достаточно зафиксировать их названия, область доступа и место использования.
2. Определите фактическую зависимость
Проверьте прямое и транзитивное присутствие Laravel-Lang с помощью composer show -t. Сопоставьте версию и source reference из lock-файла с доверенным состоянием репозитория. Один номер версии не дает полного ответа, если тег мог менять ссылку на commit.
3. Проверьте установленный артефакт и выполнение
Сравните содержимое пакета с доверенной копией, отдельно проверьте подключаемые через autoload.files файлы и журналы исходящих соединений. composer validate и composer audit полезны как часть проверки, но отсутствие предупреждений в одной команде не доказывает чистоту уже установленного кода.
4. Постройте карту доступов
Для каждого шага сборки ответьте на три вопроса: какие секреты были доступны, какие внешние адреса разрешены и с какими правами выполнялся процесс. Так ротация будет адресной, а не хаотичной.
Признаком подтвержденного инцидента может быть совпадение установленного кода с вредоносным артефактом, зафиксированный запуск подозрительного файла или необъяснимое использование доступов. Само наличие пакета — только основание для проверки.
Что делать, если риск подтверждается
Изолируйте затронутое окружение и сохраните материалы для разбора. Затем соберите приложение заново из проверенного commit и доверенных зависимостей, не перенося старый vendor и кеш. После этого меняйте только те секреты, которые действительно могли быть доступны, начиная с наиболее критичных и широких по правам.
С APP_KEY нужна отдельная осторожность: его замена влияет на зашифрованные данные, cookies и сессии. Для рабочего проекта порядок действий, окно обслуживания и возможность отката стоит определить до изменения ключа.
После восстановления проверьте не только главную страницу, но и критичные сценарии: вход, форму заявки, заказ, оплату, почтовые уведомления, обмен с CRM, очереди и фоновые задания. Исправление подтверждено, когда новая сборка воспроизводится из зафиксированных источников, подозрительный код отсутствует, затронутые секреты заменены, а контрольные сценарии и мониторинг не показывают повторных признаков.
Что запросить у подрядчика
Результат проверки должен быть проверяемым. Запросите:
- точный список затронутых пакетов, версий и source reference;
- шкалу времени деплоев и перечень окружений, где запускалась установка;
- список потенциально доступных секретов без публикации их значений;
- основания для вывода «затронут» или «не затронут»;
- перечень пересобранных артефактов и замененных доступов;
- протокол проверки форм, оплаты, интеграций и фоновых задач;
- меры, которые не дадут той же проблеме повториться при следующем релизе.
Формулировка «пакет обновили, сайт открывается» недостаточна. Она не подтверждает, что старый код не выполнялся и утекшие доступы потеряли силу.
Как снизить риск повторения
Зависимости стоит обновлять через отдельный pull request с проверкой lock-файла и состава изменений. Сборка должна получать минимально необходимые права, а рабочие секреты — только на тех шагах, где без них нельзя обойтись.
Для GitHub Actions полезно явно ограничить GITHUB_TOKEN, разрешить только нужные действия и закреплять сторонние actions полным commit SHA: официальный справочник GitHub отдельно предупреждает, что тег можно переместить на другой код. Для кеша задавайте минимальный режим доступа и не разрешайте недоверенному workflow записывать данные в кеш доверенной сборки.
Также заранее определите срок жизни токенов, владельца ротации и место хранения журнала релизов. Автоматический сканер помогает обнаруживать известные проблемы, но решение о выпуске должно опираться на проверяемый артефакт и понятный процесс.
Как это решает OpenStart
Внутренняя команда может провести проверку сама, если у нее есть история сборок, доступ к журналам и полномочия безопасно менять секреты. Внешняя помощь оправданна, когда production связан с оплатой или CRM, журналов недостаточно, неизвестно происхождение артефакта либо остановка и ошибочная ротация сами создают высокий риск.
OpenStart подключается к таким ситуациям как к технической диагностике: помогает зафиксировать состояние, проверить Composer и CI/CD, определить границы доступа, пересобрать окружение и составить проверяемый план восстановления. При признаках вредоносного кода подходит сценарий проверки и восстановления сайта; для планового контроля зависимостей — регулярная поддержка.
Частые вопросы
Нужно ли удалять Laravel-Lang из всех проектов?
Нет. Сначала установите, какие версии и commits реально использовались и выполнялась ли их установка в опасный период. Решение должно опираться на факты конкретной сборки.
Достаточно ли команды composer audit?
Нет. Она полезна для известных advisories, но не заменяет сравнение установленного кода, lock-файла, source reference, журналов сборки и доступов процесса.
Нужно ли сразу менять все секреты?
Не вслепую. Сначала определите, какие секреты были доступны затронутому процессу, затем меняйте их по риску. При подтвержденном выполнении вредоносного кода затягивать с критичными доступами нельзя.
Когда нужен внешний специалист?
Когда нет воспроизводимой сборки, затронут production, есть необычная активность, секреты дают доступ к оплате или данным либо внутренняя команда не может безопасно сохранить следы и провести ротацию.
Источники
- Отчет о скомпрометированных тегах Laravel-Lang, 22 мая 2026 года.
- Страница пакета laravel-lang/lang в Packagist, проверено 12 сентября 2026 года.
- Рекомендации GitHub по защите организации и GitHub Actions, проверено 12 сентября 2026 года.
- Ограничение доступа к кешу GitHub Actions, 10 сентября 2026 года.
- Защитная задержка npm после входа по recovery code, 9 сентября 2026 года.