$APP_KEY — и вы root: Laravel снова можно взломать одной строкой

Специалисты GitGuardian и Synacktiv обнаружили критическую уязвимость в Laravel — популярном PHP-фреймворке, на котором работают сотни тысяч веб-приложений. Проблема связана с утечкой APP_KEY — ключа, генерируемого при установке Laravel и необходимого для шифрования чувствительных данных. Если злоумышленники получают этот ключ, они могут выполнить удалённый код на сервере, эксплуатируя механизм десериализации во встроенной функции decrypt().

GitGuardian провела анализ репозиториев на GitHub за период с 2018 года по конец мая 2025 года. За это время в открытом доступе было найдено более 260 тысяч APP_KEY, при этом около 10 тысяч ключей были уникальными, а 400 из них подтверждены как действующие. Оценка показала, что более 600 веб-приложений на Laravel уязвимы к атакам через эти ключи.

Особенность уязвимости заключается в том, что Laravel после расшифровки данных автоматически десериализует результат, что даёт злоумышленнику возможность внедрить заранее подготовленный вредоносный объект. Если одновременно открыт доступ к функции decrypt(), можно добиться выполнения произвольного кода на сервере.

Ранее похожая проблема уже фиксировалась под идентификатором CVE-2018-15133 , затрагивая версии Laravel до 5.6.30. Однако в актуальных версиях угроза сохраняется при определённых конфигурациях, например, когда используется SESSION_DRIVER=cookie, что было подтверждено через недавно зарегистрированную уязвимость CVE-2024-55556 .

Более половины — 63% — всех случаев утечек APP_KEY произошли через открытые .env-файлы, которые часто содержат не только ключи шифрования, но и другие чувствительные данные: доступы к облачным хранилищам, базы данных, токены от ИИ-сервисов, систем поддержки и платформ электронной коммерции.

Особо опасна ситуация, когда одновременно утекли APP_KEY и APP_URL — базовый адрес приложения. Таких случаев GitGuardian зафиксировала около 28 тысяч, причём 10% из них оказались действительными. Это означает, что не менее 120 приложений подвержены прямой атаке: с помощью известного URL и APP_KEY злоумышленники могут извлекать и расшифровывать cookie-файлы сессий, получая доступ к внутренним данным.

Стирание ключей из репозиториев не спасает, если копии уже попали в кэш сторонних сервисов или CI-сборки. GitGuardian подчёркивает, что при обнаружении утечки необходимо срочно провести ротацию APP_KEY, обновить ключ на всех рабочих серверах и внедрить непрерывный мониторинг секретов во всех окружениях — от контейнеров до логов сборки.

Подобные уязвимости укладываются в общую категорию PHP-десериализаций. Сторонние инструменты, такие как phpggc, позволяют создавать так называемые gadget chain — последовательности объектов, которые активируют вредоносные действия при загрузке. В связке с уязвимым Laravel и скомпрометированным APP_KEY такие гаджеты дают злоумышленнику полный контроль над приложением, не требуя взлома маршрутов или логики.

Как выяснили специалисты, проблема выходит далеко за рамки Laravel. Исследование GitGuardian в DockerHub показало , что более 100 тысяч действующих секретов — от AWS, Google Cloud до GitHub-токенов — лежат прямо в публичных контейнерах. Анализ 80 тысяч образов, проведённый компанией Binarly, выявил 644 уникальных секрета, включая API-ключи, JSON Web Token, пароли и авторизационные заголовки. Причём утечки происходят даже через бинарные файлы и встроенные в контейнеры Git-репозитории — область, которую большинство сканеров просто игнорируют.

Дополнительным вектором риска стали MCP-серверы — инфраструктура, активно применяемая в enterprise-решениях с агентными ИИ. GitGuardian зафиксировала утечку как минимум одного секрета в 202 из таких серверов, что составляет 5,2% от всех MCP-репозиториев. Это выше среднего уровня по всем публичным репозиториям (4,6%) и сигнализирует о новой тенденции в области угроз.

Сегодня основной риск — это не одна уязвимость, а систематическая небрежность в работе с секретами. Организациям стоит не только следить за безопасностью .env-файлов, но и внедрять централизованное сканирование секретов, использовать руководства по защите Laravel и продумывать архитектуру приложений с учётом минимизации таких рисков.