Накратко: Уязвимостта в Laravel, която много разработчици търсят в момента, е PHP2Shell и е в самия PHP. Актуализация на Laravel не я затваря. Важни са пачнат PHP, рестартиране на всички процеси, включително queue worker и Octane, както и проверка на .env, storage и public.
Какво означава PHP2Shell за приложенията на Laravel
Laravel е основата на много собствени разработки: клиентски портали, вътрешни инструменти, системи за резервации, API за приложения. PHP уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват според екипа на PHP изпълнение на злонамерен код от разстояние без вход в системата. Колко чист е кодът на Laravel, няма значение за това.
Засегнати са режимите на работа PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Laravel Octane може да ползва FrankenPHP като сървър; тогава PHP е в програмата FrankenPHP или в образа на контейнера и се актуализира заедно с нея. Как стои въпросът при FrankenPHP, описва Защита на FrankenPHP.
Уязвимост на Laravel: проверка на версията на PHP и на процесите
В командния ред php artisan about показва версията на PHP, версията на Laravel и важни настройки като средата и режима за дебъгване. Това обаче е версията на CLI PHP. Уеб заявките обработва PHP-FPM или Octane, а това може да е друга версия. При съмнение поискайте от оператора да потвърди кое състояние на пакета работи по всички пътища.
Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35, backport-овете могат да носят по-стари номера. Кои версии на PHP поддържа Вашата версия на Laravel, проверете според системните изисквания в документацията на laravel.com.
След актуализацията идва частта, която при Laravel най-често се забравя: дълго живеещите процеси.
# Показване на версиите и конфигурацията
php artisan about
# Нареждане на queue worker да приключи след текущата задача
php artisan queue:restart
# Спиране на Horizon, за да го рестартира мениджърът на процеси
php artisan horizon:terminate
Worker процесите се рестартират след това само ако ги наблюдава мениджър на процеси като Supervisor или systemd. Сървърите на Octane и контейнерите трябва да се рестартират напълно, респективно да се разгърнат с нов образ. За настройки с контейнери важи Пачване на PHP в Docker контейнери.
Къде приложенията на Laravel са уязвими
| Място | Съдържание | Какво да проверите |
|---|---|---|
.env |
APP_KEY, база данни, поща, API ключове |
никога не бива да е достъпен през уеб |
bootstrap/cache/config.php |
кеширана конфигурация с тайни | права, дата на промяна |
public/ |
коренна директория с index.php |
допълнителни PHP файлове |
storage/app/public |
качвания, достъпни през public/storage |
без PHP файлове |
storage/logs/ |
laravel.log, често с данни от заявки |
запазете, не е публично |
vendor/ |
пакети на Composer | composer audit, сравнение с composer.lock |
Папката storage/app/public е достъпна чрез символна връзка под public/storage. Оставен там PHP файл може според конфигурацията на сървъра да бъде изпълнен директно. Блокирайте това на ниво уеб сървър.
APP_DEBUG трябва да е false в продукция. Страница с грешка и изход за дебъгване може да покаже променливи на средата, пътища и части от кода и улеснява работата на всеки нападател.
Административни интерфейси и пакети като риск
Приложенията на Laravel нямат единен административен интерфейс. Често това са собствени зони или пакети като Filament или Nova. Проверете кой има админ права, има ли входът стъпка с двуфакторно удостоверяване и трябва ли админ маршрутите да са достъпни отвън. И API токените, например от Sanctum или Passport, трябва да се отменят и да се издадат наново при подозрение.
Проверете освен това дали инструменти от разработката са достъпни в продукция, например дебъг ленти, Telescope или тестови маршрути. Те често показват заявки, запитвания и конфигурация и трябва да са зад вход или изцяло премахнати от продукционната среда.
Пакетите на Composer са вторият голям блок. Всяка зависимост носи собствен код, а пакетите без поддръжка по-късно блокират надграждането на PHP. composer audit показва известни уязвимости, но не заменя проверката на собствения код.
Какво може актуализацията на Laravel и какво не
Актуализация на Laravel или на отделни пакети затваря известни грешки в този код. Тя не пачва PHP, не рестартира worker процеси, не подновява изтекъл APP_KEY и не премахва файлове от storage или public. Дали преди пача нещо се е случило, може да се изясни само чрез проверка на логове, файлове и база данни.
За екипи с deployment pipeline важи: актуализацията на PHP принадлежи и в средата за билд и в базовите образи, иначе следващият deployment отново донася стара версия. Проверете освен това дали staging или review среди са публично достъпни. Те често работят с APP_DEBUG=true и с реални данни и лесно се пропускат при актуализации за сигурност.
Как помага PHP SOS конкретно?
- Проверяваме уеб, CLI и worker PHP на Вашето приложение на Laravel и съпровождаме подреденото рестартиране на всички процеси.
- Запазваме логове от 20.10.2026 г. нататък, базата данни и състоянието на кода и го сравняваме с Вашето хранилище.
- Проверяваме
.env, кеша на конфигурацията,storage,public, админ акаунтите и API токените. - За по-дълбока проверка на собствения код посредничим за одит на сигурността или тест за проникване чрез специализирани партньори.
Често задавани въпроси
Трябва ли да актуализирам Laravel заради PHP2Shell?
Актуализацията на Laravel не затваря PHP2Shell, защото уязвимостта е в интерпретатора на PHP. Все пак дръжте Laravel актуален. За PHP2Shell Ви трябват пачнат PHP и рестартиране на всички PHP процеси, включително на worker процесите.
Защо рестартирането на PHP-FPM при Laravel често не стига?
Queue worker, Horizon, Octane и Scheduler работят като отделни PHP процеси през командния ред. Те зареждат PHP веднъж при стартиране и след това продължават да работят със старата версия в паметта, докато не бъдат рестартирани.
Какво да направя, ако файлът .env може да е изтекъл?
Тогава трябва да смените APP_KEY, паролата на базата данни и всички ключове за външни услуги. Имайте предвид, че нов APP_KEY прекратява съществуващите сесии и прави шифрованите със стария ключ данни нечетими; планирайте това с Вашите разработчици.