# Laravel biztonsági rés, PHP2Shell: alkalmazások helyes védelme

> Laravel védelme a PHP2Shell után: PHP ellenőrzése artisan about-tal, queue workerek és Octane újraindítása, a .env, az APP_KEY és a storage átnézése.

Forrás: https://phpsos.de/hu/plattformen/laravel/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A Laravel biztonsági rése, amelyet jelenleg sok fejlesztő keres, a PHP2Shell, és magában a PHP-ben van. Egy Laravel-frissítés nem zárja le. A javított PHP, az összes folyamat, a queue workereket és az Octane-t is beleértve, újraindítása, valamint a `.env`, a `storage` és a `public` ellenőrzése a fontos.

## Mit jelent a PHP2Shell a Laravel-alkalmazások számára

A Laravel sok egyedi fejlesztés alapja: ügyfélportálok, belső eszközök, foglalási rendszerek, API-k appokhoz. A CVE-2026-109618 és a CVE-2026-109619 PHP-rések a PHP-csapat szerint lehetővé teszik kártékony kód távoli futtatását bejelentkezés nélkül. Az nem számít, mennyire tiszta a Laravel-kód.

Az érintett üzemmódok: PHP-FPM, Apache mod_php-vel, php-cgi, FrankenPHP és LiteSpeed. A Laravel Octane a FrankenPHP-t használhatja szerverként; ilyenkor a PHP a FrankenPHP programjában vagy a konténer-image-ben van, és azzal együtt frissül. Hogy ez hogyan néz ki a FrankenPHP-nél, azt a [FrankenPHP védelme](https://phpsos.de/hu/server/frankenphp/) oldal írja le.

## Laravel biztonsági rés: a PHP-verzió és a folyamatok ellenőrzése

A parancssorban a `php artisan about` megmutatja a PHP-verziót, a Laravel-verziót és a fontos beállításokat, például a környezetet és a hibakeresési módot. Ez azonban a CLI-s PHP verziója. A webes kéréseket a PHP-FPM vagy az Octane dolgozza fel, és az más verzió lehet. Kétség esetén az üzemeltetővel erősíttesse meg, mely csomagállapot fut az összes úton.

A javított upstream verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35, a backportok régebbi számot is viselhetnek. Hogy a Laravel-verziója mely PHP-verziókat támogatja, azt a rendszerkövetelmények szerint a laravel.com dokumentációjában ellenőrizheti.

A frissítés után jön az a rész, amelyről a Laravelnél leggyakrabban megfeledkeznek: a hosszú életű folyamatok.

```bash
# Verziók és konfiguráció megjelenítése
php artisan about
# A queue workerek utasítása, hogy az aktuális feladat után álljanak le
php artisan queue:restart
# A Horizon leállítása, hogy a folyamatkezelő újraindítsa
php artisan horizon:terminate
```

A workerek utána csak akkor indulnak újra, ha egy folyamatkezelő, például a Supervisor vagy a systemd felügyeli őket. Az Octane-szervereket és a konténereket teljesen újra kell indítani, illetve új image-dzsel kell kihelyezni. A konténeres felállásokra a [PHP javítása Docker-konténerekben](https://phpsos.de/hu/php2shell/docker-container-patchen/) érvényes.

## Hol sebezhetők a Laravel-alkalmazások

| Hely | Tartalom | Ellenőrzési pont |
|---|---|---|
| `.env` | `APP_KEY`, adatbázis, levelezés, API-kulcsok | soha nem lehet a weben keresztül lekérhető |
| `bootstrap/cache/config.php` | a gyorsítótárazott konfiguráció titkokkal | jogok, módosítás dátuma |
| `public/` | dokumentumgyökér az `index.php`-vel | további PHP-fájlok |
| `storage/app/public` | feltöltések, a `public/storage` alatt elérhetők | nincs PHP-fájl |
| `storage/logs/` | `laravel.log`, gyakran kéréseket tartalmaz | mentse, ne legyen nyilvános |
| `vendor/` | Composer-csomagok | `composer audit`, egyeztetés a `composer.lock` fájllal |

A `storage/app/public` mappa egy szimbolikus linken keresztül a `public/storage` alatt elérhető. Az ott elhelyezett PHP-fájl a szerverkonfigurációtól függően közvetlenül futtatható. Tiltsa le ezt webszerver-szinten.

> **Fontos:**
> Az `APP_DEBUG` értékének éles üzemben `false`-nak kell lennie. Egy hibakeresési kimenetet mutató hibaoldal mutathat környezeti változókat, útvonalakat és a kód részeit, és minden támadó munkáját megkönnyíti.

## Admin felületek és csomagok mint kockázat

A Laravel-alkalmazásoknak nincs egységes admin felületük. Gyakran saját területek vagy olyan csomagok, mint a Filament vagy a Nova. Ellenőrizze, kinek vannak admin-jogai, van-e a bejelentkezésnek kétfaktoros lépcsője, és kívülről elérhetőnek kell-e lenniük az admin útvonalaknak. Az API-tokeneket, például a Sanctumból vagy a Passportból, szintén vonja vissza és állítsa ki újra gyanú esetén.

Ellenőrizze azt is, hogy a fejlesztésből származó eszközök elérhetők-e az éles környezetben, például a debug sávok, a Telescope vagy a tesztútvonalak. Gyakran kéréseket, lekérdezéseket és konfigurációt mutatnak, és bejelentkezés mögé tartoznak, vagy teljesen el kell őket távolítani az éles környezetből.

A Composer-csomagok a második nagy blokk. Minden függőség saját kódot hoz, és a gondozás nélküli csomagok később blokkolják a PHP-frissítéseket. A `composer audit` ismert réseket mutat, de a saját kód ellenőrzését nem pótolja.

## Mit tud egy Laravel-frissítés, és mit nem

A Laravel vagy az egyes csomagok frissítése lezárja az ebben a kódban lévő ismert hibákat. A PHP-t nem javítja, workereket nem indít újra, az elszivárgott `APP_KEY`-t nem újítja meg, és a `storage` vagy a `public` mappából fájlokat nem távolít el. Hogy történt-e valami a javítás előtt, csak a naplók, a fájlok és az adatbázis ellenőrzésével tisztázható.

A telepítési folyamattal rendelkező csapatokra érvényes: a PHP-frissítésnek a build-környezetbe és az alap-image-ekbe is be kell kerülnie, különben a következő telepítés ismét régi verziót hoz magával. Ellenőrizze azt is, hogy a staging- vagy review-környezetek nyilvánosan elérhetők-e. Gyakran `APP_DEBUG=true` értékkel és valódi adatokkal futnak, és a biztonsági frissítéseknél könnyen átsiklanak rajtuk.

## Hogyan segít konkrétan a PHP SOS?

- Ellenőrizzük a Laravel-alkalmazása web-, CLI- és worker-PHP-ját, és kísérjük az összes folyamat rendezett újraindítását.
- Mentjük a naplókat 2026. 10. 20-tól, az adatbázist és a kódállapotot, és egyeztetjük az Ön tárolójával.
- Ellenőrizzük a `.env` fájlt, a konfigurációs gyorsítótárat, a `storage` és a `public` mappát, az admin-fiókokat és az API-tokeneket.
- A saját kód mélyebb ellenőrzéséhez szakosodott partnereken keresztül közvetítünk [biztonsági auditot vagy penetrációs tesztet](https://phpsos.de/hu/leistungen/sicherheitsaudit-penetrationstest/).


## Gyakori kérdések

**Frissítenem kell a Laravelt a PHP2Shell miatt?**  
Egy Laravel-frissítés nem zárja le a PHP2Shellt, mert a rés a PHP-értelmezőben van. A Laravelt ettől függetlenül tartsa naprakészen. A PHP2Shell ellen javított PHP-ra és az összes PHP-folyamat, a workerek újraindítására van szükség.

**Miért nem elég gyakran a PHP-FPM újraindítása a Laravelnél?**  
A queue workerek, a Horizon, az Octane és az ütemező külön PHP-folyamatokként futnak a parancssorból. A PHP-t egyszer, induláskor töltik be, majd a memóriában lévő régi verzióval dolgoznak tovább, amíg újra nem indítják őket.

**Mit tegyünk, ha a .env fájl elszivároghatott?**  
Ilyenkor újítsa meg az APP_KEY-t, az adatbázis jelszavát és a külső szolgáltatások összes kulcsát. Vegye figyelembe, hogy egy új APP_KEY megszünteti a meglévő munkameneteket, és a régi kulccsal titkosított adatokat olvashatatlanná teszi; ezt egyeztesse a fejlesztőivel.

## Források

- [php.net: biztonsági közlemények](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)