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 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.
# 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 é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.
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
.envfájlt, a konfigurációs gyorsítótárat, astorageés apublicmappá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.
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.