Мы разобрали WordPress, Битрикс, Tilda, Astro и OpenCart. Во всех этих разборах у нас была одна и та же главная претензия: чужой код, который владелец сайта ставит себе сам через админку и который получает полный доступ ко всему.
Сегодня разбираем Laravel — и этой претензии не будет. Потому что Laravel стоит по нашу сторону забора.
Чем Laravel принципиально отличается от CMS
Laravel — не система управления сайтом, а каркас для написания приложения. Разница для безопасности оказывается громадной, и состоит она в одном: в Laravel нет плагинов, которые можно поставить из админки.
Вспомним, как это выглядит в WordPress или OpenCart. Владелец заходит в панель, находит нужный модуль, жмёт «установить» — и внутри его сайта начинает работать чужой PHP-код с полным доступом к базе и файлам. Обновление приезжает само или не приезжает вовсе. Автор модуля может его забросить, продать или быть взломанным, и сайт узнает об этом последним.
В Laravel пакеты ставит разработчик, с рабочей машины, командой в терминале, и результат попадает на сервер как часть выкладки. Админка такой возможности не даёт вообще. Это закрывает целый класс атак, на котором построена вся индустрия массовых взломов: готовый эксплойт к популярному плагину, робот, обходящий интернет за ночь, и тысячи сайтов, упавших одновременно.
Это не мелкое отличие и не вопрос вкуса. Это разница между «ваш сайт сломали за компанию с ещё десятью тысячами» и «вашим сайтом надо заниматься отдельно».
Сказав это, переходим к тому, что у Laravel всё-таки болит.
Три строки, которые превращаются в двести пять пакетов
Мы поставили чистый Laravel сегодня, 6 октября 2026 года, и посчитали. Версия 13.35.0.
В файле composer.json, который описывает зависимости проекта, в рабочем разделе три строки: сам PHP, laravel/framework и laravel/tinker. Ещё семь строк в разделе для разработки. Итого десять осознанных решений.
Разворачиваются они вот во что:
| Что считаем | Сколько |
|---|---|
| Пакетов PHP в рабочем режиме | 76 |
| Пакетов PHP всего, с инструментами разработки | 109 |
| Разных поставщиков среди них | 34 |
| Пакетов npm для сборки стилей и скриптов | 96 |
| Всего чужого кода в пустом проекте | 205 пакетов |
Папка node_modules при этом весит 90 МБ и содержит 8 248 файлов — и это в проекте, где ещё не написано ни строчки.
Цифра выглядит пугающе, но мы обязаны сказать и вторую половину правды. Качественно эти 205 пакетов совсем не то же самое, что 205 пакетов из мира npm. Подавляющее большинство пакетов PHP здесь — это Laravel, Symfony, Doctrine, League, Monolog, Carbon. Организации с процессом выпуска версий, с историей, с репутацией. Тридцать четыре поставщика — это не тридцать четыре случайных человека из интернета.
Для сравнения: в разборе Astro мы насчитали 194 пакета от 71 автора в чистой установке. Числа похожие, а природа разная.
Composer против npm: PHP действительно безопаснее?
Отвечаем честно: да, но по трём разным причинам, и только одна из них — заслуга.
Причина первая — архитектура, и это настоящая заслуга. В Composer имя пакета всегда состоит из поставщика и названия: laravel/framework. Пространство поставщика закрепляется за ним навсегда. Из-за этого атака «подмена зависимости», когда злоумышленник публикует пакет с именем вашего внутреннего и сборка подтягивает чужой, в Packagist структурно невозможна — в отличие от npm, PyPI и RubyGems.
Второе: в npm любой пакет при установке по умолчанию может выполнить свой скрипт. Именно так работали все черви 2025–2026 годов. В Composer выполнять код при установке могут только плагины, и они должны быть явно перечислены в списке разрешённых. В чистом Laravel таких записей ровно две.
Третье: пакеты в Packagist берутся прямо из меток в репозитории, а не из отдельно загруженной сборки. И проверка на известные уязвимости включена по умолчанию, а не по отдельной команде, как npm audit.
Причина вторая — масштаб внимания, и это не заслуга. В Packagist около 472 тысяч пакетов, в npm — около 4,46 миллиона, то есть почти в десять раз больше. А вот записей о вредоносных пакетах в открытой базе OSV: у npm 222 314, у Packagist — одна. Реестр больше в десять раз, а вредоносов в двести двадцать тысяч раз. Так не бывает от одной только хорошей архитектуры. Злоумышленники идут туда, где лежат токены сборочных конвейеров и облачные ключи, а это мир JavaScript.
Причина третья — его просто не считали. Это важная оговорка, и мы не видели, чтобы её делали. Автоматическое обнаружение вредоносных пакетов появилось в Packagist только в марте 2026 года. Главный отраслевой отчёт о вредоносных пакетах, на который все ссылаются, следит за Maven, PyPI, npm и NuGet — Packagist в его периметр не входит вообще. Единица в базе OSV означает «существует одна запись», а не «был один случай».
И 2026 год показал, что защита не абсолютная. В апреле впервые появился червь, задевший сразу npm, PyPI и Packagist. В мае злоумышленник с доступом к репозиторию переписал все метки версий у четырёх пакетов проекта laravel-lang — это часть кампании, затронувшей более семисот репозиториев на GitHub. Через день нашли ещё восемь пакетов Packagist с вредоносной нагрузкой, причём спрятанной не в коде PHP, а в package.json рядом с ним.
У Packagist, в отличие от PyPI, до сих пор нет обязательной двухфакторной аутентификации для авторов. Все инциденты последних лет — это угнанные учётные записи и украденные токены, а не дыры в самом реестре.
И последнее, что честность требует назвать. По количеству обычных уязвимостей на пакет Composer выглядит хуже всех: 0,86 против 0,15 у npm в академическом исследовании, с первым местом по межсайтовому скриптингу. Меньше атак, но больше ошибок в расчёте на пакет.
Собственные уязвимости Laravel
Здесь Laravel выглядит хорошо, и это надо сказать прямо. В базе NVD к самому фреймворку привязано девять записей за всю историю, с почти пустым промежутком с конца 2021 до конца 2024 года. Для системы, на которой работает больше шестисот тысяч сайтов, это мало.
| Уязвимость | Суть |
|---|---|
| CVE-2018-15133 | Исполнение кода через подделанную куку — но только если злоумышленник знает ключ приложения. Запомните эту оговорку, дальше всё крутится вокруг неё. В каталоге активно эксплуатируемых уязвимостей CISA с января 2024 года. |
| CVE-2021-3129 | Исполнение кода без авторизации через страницу отладки. Оценка 9,8. Единственная уязвимость Laravel, которую CISA помечает как использованную в программах-вымогателях. Работает только при включённом режиме отладки. |
| CVE-2024-52301 | Через строку запроса можно переключить, в каком окружении приложение обрабатывает конкретный запрос, — например, в отладочное. Нужна настройка register_argc_argv, которая выключена в стандартном PHP, но включена на части хостингов. |
| CVE-2026-48019 | Самая неприятная из свежих: через поле электронной почты в обычной форме можно подменить содержимое письма и превратить сайт в рассыльщик спама. Оценка 8,9, исправлено в июне 2026 года. |
Полезный побочный урок. Уязвимость CVE-2025-27515 в базе NVD получила оценку 9,8 — «критическая», а разработчики Laravel в своём же предупреждении оценили её в 6,9 — «умеренная». Обе оценки настоящие: первую автоматически посчитала база, вторую поставил тот, кто знает код. Когда вам присылают выгрузку «на вашем сайте 14 критических уязвимостей», стоит помнить, откуда берутся такие числа.
И ещё одна деталь, которую мы считаем говорящей: три из восьми предупреждений Laravel за 2024–2026 годы достижимы только при включённом режиме отладки. То есть заметная часть собственной уязвимой поверхности фреймворка находится в коде, которого в рабочем режиме быть не должно.
Где ломают на самом деле
А теперь главное. Статистика взломов Laravel-сайтов почти не про уязвимости Laravel. Она про три файла и одну строку.
Ключ приложения
У каждого приложения Laravel есть APP_KEY — ключ, которым шифруются куки и сессии. Кто знает ключ, тот, по сути, владеет приложением: именно это превращает CVE-2018-15133 из теории в работающий взлом.
В 2025 году вышли два исследования, и их цифры стоит привести.
Первое: из публичных репозиториев GitHub с 2018 года извлечено около 260 тысяч ключей Laravel. Из пар «ключ плюс адрес сайта» примерно десятая часть оказалась действующей. Около шестисот приложений можно было захватить, примерно сто двадцать — с исполнением произвольного кода. 63% утечек пришлись на файл .env.
И деталь, от которой холодеет: 50 ключей были удалены из репозитория, но продолжали работать на боевых серверах. Разработчик стёр коммит и решил, что проблема решена. Удаление из истории — это не смена ключа.
Второе исследование измеряло не GitHub, а сам интернет. В мае 2025 года собрано 625 059 открытых кук Laravel; 22 212 из них расшифрованы подобранным ключом; 1 091 сервер оказался напрямую пригоден для захвата. Годом раньше таких было 1 326 — то есть ситуация улучшается, но медленно.
И вот пункт, который прямо касается российского малого бизнеса. Ключ не создаётся заново, если он уже прописан в файле настроек. Поэтому компании, продающие готовые решения на Laravel — складские системы, кассы, системы бронирования, CRM, — нередко поставляют один и тот же ключ всем своим клиентам. В исследовании самый популярный повторяющийся ключ встретился 1 650 раз. На третьем месте — строка-заглушка из документации, 518 раз.
Если вы купили готовую систему на Laravel у интегратора, есть заметный шанс, что ваш ключ стоит ещё у сотни компаний и, возможно, уже лежит в публичном наборе.
Файл .env и режим отладки
Файл .env хранит пароль от базы, ключ приложения, ключи почтовых и платёжных сервисов. Если он доступен из интернета, обсуждать больше нечего.
Масштаб: вымогательская кампания 2024 года просканировала 230 миллионов адресов, собрала 110 тысяч файлов .env и больше 90 тысяч уникальных переменных, включая 1 185 ключей доступа к облаку. Оговоримся честно: это исследование не выделяло Laravel отдельно — файл .env используют многие. Но именно Laravel приносит его в проект по умолчанию.
Режим отладки добавляет второй путь к тем же данным: достаточно отправить что-нибудь некорректное и прочитать настройки прямо со страницы ошибки. Сколько сайтов работают с включённой отладкой, никто достоверно не измерял — мы искали и не нашли.
Никто не выбирает ваш сайт
Ботнет AndroxGh0st, о котором ФБР и CISA выпустили совместное предупреждение в январе 2024 года, занимается ровно одним: обходит интернет, ищет файлы .env и известные пути Laravel, забирает ключи. По оценке Fortinet, на тот момент в нём было около 40 тысяч заражённых узлов.
Сайт с пятью посетителями в день сканируется ровно так же часто, как крупный. Незаметность — не защита.
Часы, о которых заказчику не говорят
Это, пожалуй, самое полезное для владельца бизнеса, и в коммерческом предложении этого никогда не пишут.
У каждой версии Laravel есть срок: 18 месяцев исправления ошибок и 24 месяца исправлений безопасности. Новая основная версия выходит раз в год. Долгоживущих версий не существует с 2019 года.
| Версия | Состояние на октябрь 2026 |
|---|---|
| Laravel 10 и старше | не получают ничего |
| Laravel 11 | умерла 12 марта 2026 года |
| Laravel 12 | только безопасность, до 24 февраля 2027 |
| Laravel 13 | полная поддержка |
Сайт, сделанный на Laravel 11 весной 2024 года, перестал получать исправления безопасности семь месяцев назад. Никакого сообщения об этом владельцу не пришло: сайт работает ровно так же, как вчера. В этом и состоит ловушка — нет ни одного видимого признака того, что защита кончилась.
Под фреймворком тикают вторые часы — сам PHP. Версии 8.0 и 8.1 уже не поддерживаются никем, у 8.2 поддержка заканчивается 31 декабря 2026 года. Через три-пять лет без обслуживания получается приложение без поддержки на языке без поддержки на системе без поддержки, и выбираться придётся из всех трёх слоёв одновременно.
Справедливости ради: сами обновления у Laravel сделаны аккуратно. В руководстве по переходу с 12 на 13 версию стоит честная оценка «10 минут» и перечислено 19 изменений, из них три значимых. Разработчики пишут: «мы стремимся к тому, чтобы переход на новую основную версию занимал не больше одного дня». Для небольшого приложения с тестами это похоже на правду — но относится только к самому фреймворку, а не к сторонним пакетам, где боль обычно и живёт.
И в Laravel 13 появились два хороших изменения ровно по мотивам всего, что мы описали выше: запрет на восстановление произвольных объектов из кэша по умолчанию и проверка источника запроса при защите форм.
Насколько быстро чинят на практике
Лучший пример — не сам Laravel, а Livewire: библиотека, которая стоит практически в каждой современной админке на Laravel.
Уязвимость с исполнением команд без авторизации, оценка 9,8. Исправлена 17 июля 2025 года. Обновление — одна строка.
В марте 2026 года CISA внесла её в каталог активно эксплуатируемых. А в мае 2026 года, по данным исследователей Imperva, была обнаружена кампания, в ходе которой пострадало 6 167 приложений: похищено больше 1 850 полных выгрузок баз данных, свыше 14 тысяч действующих паролей от баз, 188 ключей платёжной системы и 381 учётная запись облачного сервиса. Эти цифры мы приводим по единственному источнику и не смогли их перепроверить — относитесь к ним как к порядку величины.
Главное в этой истории не цифры, а срок. Между выходом исправления и началом массовой эксплуатации прошло десять месяцев. Фреймворк свою работу сделал. Шесть тысяч приложений — нет.
Сколько стоит держать такой сайт живым
Laravel требует от сервера больше, чем обычный сайт на PHP. Нужен Composer, нужен Node.js для сборки стилей и скриптов, нужна запись в расписании задач раз в минуту, а для фоновых задач — служба, которая следит за постоянно работающими процессами. Выкладка — это не загрузка файлов по FTP, а сборка.
На российском виртуальном хостинге (244–806 ₽ в месяц у Timeweb, 420–790 ₽ у Beget) Laravel запустить можно, и провайдеры это документируют. Но на части тарифов запрещены символические ссылки, и штатная работа с загруженными файлами ломается, а постоянно работающие процессы недоступны — очередь приходится разгребать по расписанию, что заметно менее надёжно. Поэтому реальный ответ для приложения с фоновыми задачами — виртуальный сервер: 200–400 ₽ в месяц у Selectel, 900–1 800 ₽ у Timeweb Cloud.
Дальше начинается то, что обычно и становится сюрпризом, — сопровождение. Российские студии публикуют вполне согласованные цены:
- Пакеты поддержки: от 27 000 ₽ в месяц за 10 часов до 250 000 ₽ за 90 часов.
- Разовые работы: 2 300–3 500 ₽ в час.
- Разработка: от 3 000 ₽ в час; типовые пакеты — 180 000 ₽ за минимальную версию за три недели, 450 000 ₽ за вариант с интеграциями.
Для сравнения: средний разработчик PHP в России стоит около 170 тысяч рублей в месяц по медиане вакансий. Пакет поддержки на 10 часов — это примерно шестая часть одного сотрудника. Понятно, почему такие пакеты существуют.
Вывод простой: у приложения на Laravel обязательно должен быть живой разработчик. Не «на всякий случай», а постоянно. Это не минус Laravel — это условие задачи, которое стоит знать до начала проекта, а не через два года.
Где проходит граница с нашим подходом
Мы не будем делать вид, что Laravel — плохой выбор. Это хороший инструмент, и для многих задач — правильный. 64% разработчиков PHP работают с ним, и у этого есть причины: скорость разработки, предсказуемая структура, большая экосистема, лёгкость найти исполнителя.
Разница между Laravel и тем, что делаем мы, проходит не по безопасности, а по количеству движущихся частей и по сроку жизни без обслуживания.
- У нас нет часов поддержки. Мы пишем на PHP без фреймворка, и обновлять нечего: нет версии, у которой кончается срок, нет ежегодного перехода, нет 205 пакетов, которые кто-то должен сопровождать.
- Нет этапа сборки. Нет Node.js на сервере, нет
node_modules, нет шага, который может сломаться при выкладке. - Нет фоновых служб. Обычного виртуального хостинга хватает.
- Код читается любым разработчиком PHP без изучения фреймворка — это важно именно для сценария «подрядчик пропал».
И честно о том, чем мы за это платим. Мы пишем руками то, что в Laravel уже готово: аутентификацию, работу с базой, маршрутизацию, проверку форм. Это дольше. Мы не получаем бесплатно улучшений, которые приходят с новой версией фреймворка, — вроде тех двух, что появились в Laravel 13. И наш код проверен только нами, а код Laravel — шестьюстами тысячами сайтов.
Поэтому рекомендация у нас такая. Если у вас есть работающее приложение на Laravel и есть разработчик, который его ведёт, — ничего не переписывайте. Это тот случай, когда переделка не окупается. Наш подход имеет смысл там, где сайт должен жить годами без обслуживания, где его надо поставить в сеть без интернета, или где по условию задачи движущихся частей должно быть как можно меньше.
Что сделать с существующим сайтом на Laravel
Порядок действий, если сайт у вас уже есть. Первые четыре пункта — на один вечер, и они закрывают почти всё, что ломают в реальности.
- Проверьте, не открыт ли
.env. Просто откройте в браузере адрес вашего сайта со/.envна конце. Если что-то скачалось — считайте все пароли и ключи скомпрометированными и меняйте их сегодня. - Убедитесь, что отладка выключена. В
.envдолжно стоятьAPP_DEBUG=false. Это одна строка, и она закрывает три из восьми последних уязвимостей фреймворка. - Смените ключ приложения, если сайт делал подрядчик, если это готовое решение от интегратора, или если вы просто не знаете его историю. Учтите, что после смены ключа разлогинятся все пользователи, а зашифрованные в базе поля, если они есть, придётся перешифровать, — это делается не на бегу, но делается.
- Выясните, какая у вас версия Laravel и когда у неё кончается поддержка. Если это 11-я или старше — поддержки уже нет.
- Попросите разработчика запустить проверку зависимостей и показать результат. Команда одна, занимает секунды, и показывает все известные уязвимости в установленных пакетах.
- Убедитесь, что у вас есть доступы ко всему: репозиторий с кодом, учётные записи хостинга и домена, инструкция по выкладке. Если проект передадут другому разработчику, это и будет разницей между «неделя» и «переписываем заново».
Коротко
- В Laravel нет плагинов, устанавливаемых из админки, — это снимает тот класс массовых взломов, о котором мы писали в разборах WordPress и OpenCart.
- Чистая установка — 205 сторонних пакетов из трёх строк в настройках. Но поставщиков всего 34, и это в основном крупные проекты с процессом.
- Composer действительно устроен безопаснее npm — и одновременно он просто менее интересен злоумышленникам, а до марта 2026 года вредоносные пакеты в нём никто и не искал.
- Собственных уязвимостей у Laravel мало, и их быстро чинят.
- Ломают не фреймворк, а установку: открытый
.env, включённая отладка и утёкший или общий для всех клиентов ключ приложения. - У каждой версии есть срок: 18 месяцев на ошибки, 24 на безопасность. Laravel 11 умерла в марте 2026 года, и владельцам сайтов об этом никто не сообщил.
- Приложению на Laravel нужен постоянный разработчик. Это не недостаток, а условие, которое лучше знать заранее.
Посмотреть со стороны, что ваш сайт рассказывает о себе каждому посетителю, можно нашей бесплатной проверкой — она показывает, на чём он сделан, каким чужим сервисам передаёт данные и что сообщает о себе сервер. Никаких проб на прочность.
А если нужен честный разбор конкретного проекта и ответ на вопрос, стоит ли вообще что-то менять, — напишите на info@g3a.ru. Вполне возможно, что достаточно сменить ключ и выключить отладку, и мы об этом скажем прямо.
Источники
- Замеры чистой установки Laravel 13.35.0 сделаны нами 6 октября 2026 года и воспроизводятся командами
composer create-project laravel/laravelиnpm install. - Сроки поддержки версий и руководства по переходу: официальная документация Laravel.
- Уязвимости: база NVD, предупреждения безопасности в репозитории laravel/framework, каталог активно эксплуатируемых уязвимостей CISA.
- Утечки ключей приложения: исследование GitGuardian от 10 июля 2025 года и исследование Synacktiv от 7 октября 2025 года.
- Сбор файлов
.env: отчёт Unit 42, Palo Alto Networks, август 2024 года. - Безопасность Packagist и инциденты 2026 года: официальный блог Packagist.
- Распространённость: BuiltWith (614 661 сайт в мире, 12 748 в России — четвёртое место), опрос JetBrains «The State of PHP 2025».
- Цены на хостинг и сопровождение взяты с публичных страниц Timeweb, Beget, Selectel и российских студий, октябрь 2026 года.