# Laravel уязвимост PHP2Shell: как да защитите правилно приложенията

> Защитете Laravel след PHP2Shell: проверете PHP с artisan about, рестартирайте queue worker и Octane, контролирайте .env, APP_KEY и storage.

Източник: https://phpsos.de/bg/plattformen/laravel/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Уязвимостта в 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](https://phpsos.de/bg/server/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 най-често се забравя: дълго живеещите процеси.

```bash
# Показване на версиите и конфигурацията
php artisan about
# Нареждане на queue worker да приключи след текущата задача
php artisan queue:restart
# Спиране на Horizon, за да го рестартира мениджърът на процеси
php artisan horizon:terminate
```

Worker процесите се рестартират след това само ако ги наблюдава мениджър на процеси като Supervisor или systemd. Сървърите на Octane и контейнерите трябва да се рестартират напълно, респективно да се разгърнат с нов образ. За настройки с контейнери важи [Пачване на PHP в Docker контейнери](https://phpsos.de/bg/php2shell/docker-container-patchen/).

## Къде приложенията на 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 токените.
- За по-дълбока проверка на собствения код посредничим за [одит на сигурността или тест за проникване](https://phpsos.de/bg/leistungen/sicherheitsaudit-penetrationstest/) чрез специализирани партньори.


## Често задавани въпроси

**Трябва ли да актуализирам 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 прекратява съществуващите сесии и прави шифрованите със стария ключ данни нечетими; планирайте това с Вашите разработчици.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [Laravel](https://laravel.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
