Na kratko: Ranljivost Laravel, ki jo zdaj išče veliko razvijalcev, je PHP2Shell in je v samem PHP. Posodobitev Laravel je ne zapre. Pomembni so popravljen PHP, ponovni zagon vseh procesov, vključno z delavci čakalne vrste in Octane, ter pregled .env, storage in public.
Kaj PHP2Shell pomeni za aplikacije Laravel
Laravel je temelj številnih lastnih razvojev: portalov za kupce, notranjih orodij, sistemov za rezervacije, API-jev za aplikacije. Ranljivosti PHP CVE-2026-109618 in CVE-2026-109619 po navedbah ekipe PHP omogočata izvajanje škodljive kode na daljavo brez prijave. Kako čista je koda Laravel, pri tem ni pomembno.
Prizadeti so načini delovanja PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Laravel Octane lahko kot strežnik uporablja FrankenPHP; takrat je PHP vdelan v program FrankenPHP ali v sliko containerja in se posodobi z njim. Kako je to pri FrankenPHP, opisuje prispevek Zaščita FrankenPHP.
Ranljivost Laravel: preverite različico PHP in procese
V ukazni vrstici php artisan about prikaže različico PHP, različico Laravel in pomembne nastavitve, kot sta okolje in način odpravljanja napak. To pa je različica PHP CLI. Spletne zahteve obdeluje PHP-FPM ali Octane, in to je lahko druga različica. Če ste v dvomu, naj upravljavec potrdi, katero stanje paketa teče na vseh poteh.
Odpravljene različice izvorne kode so 8.5.12, 8.4.27, 8.3.36 in 8.2.35, backporti lahko nosijo starejše številke. Katere različice PHP podpira vaša različica Laravel, preverite v sistemskih zahtevah v dokumentaciji na laravel.com.
Po posodobitvi pride del, ki se pri Laravelu najpogosteje pozabi: dolgoživi procesi.
# Prikaži različice in konfiguracijo
php artisan about
# Delavcu čakalne vrste naroči, naj se konča po trenutnem opravilu
php artisan queue:restart
# Končaj Horizon, da ga upravitelj procesov znova zažene
php artisan horizon:terminate
Delavci se nato znova zaženejo samo, če jih nadzira upravitelj procesov, kot sta Supervisor ali systemd. Strežnike Octane in containerje je treba popolnoma znova zagnati oziroma uvesti z novo sliko. Za postavitve s containerji velja prispevek Popravljanje PHP v containerjih Docker.
Kje so aplikacije Laravel ranljive
| Mesto | Vsebina | Točka preverjanja |
|---|---|---|
.env |
APP_KEY, podatkovna zbirka, pošta, ključi API |
Nikoli ne sme biti dosegljiva prek spleta |
bootstrap/cache/config.php |
Predpomnjena konfiguracija s skrivnostmi | Pravice, datum spremembe |
public/ |
Korenska mapa dokumentov z index.php |
Dodatne datoteke PHP |
storage/app/public |
Nalaganja, dosegljiva prek public/storage |
Brez datotek PHP |
storage/logs/ |
laravel.log, pogosto s podatki zahtev |
Zavarovati, ne javno |
vendor/ |
Paketi Composer | composer audit, primerjava s composer.lock |
Mapa storage/app/public je dosegljiva prek simbolične povezave pod public/storage. Tam odložena datoteka PHP se lahko glede na konfiguracijo strežnika izvede neposredno. To blokirajte na ravni spletnega strežnika.
APP_DEBUG mora biti v produkciji nastavljen na false. Stran z napako z izpisom za odpravljanje napak lahko pokaže spremenljivke okolja, poti in dele kode ter vsakemu napadalcu olajša delo.
Skrbniški vmesniki in paketi kot tveganje
Aplikacije Laravel nimajo enotnega skrbniškega vmesnika. Pogosto so to lastna območja ali paketi, kot sta Filament ali Nova. Preverite, kdo ima skrbniške pravice, ali ima prijava stopnjo z dvema faktorjema in ali morajo biti skrbniške poti dosegljive od zunaj. Tudi žetone API, na primer iz Sanctum ali Passport, je treba ob sumu preklicati in izdati znova.
Preverite tudi, ali so v produkciji dosegljiva razvojna orodja, na primer vrstice za odpravljanje napak, Telescope ali testne poti. Pogosto kažejo zahteve, poizvedbe in konfiguracijo ter sodijo za prijavo ali pa jih je treba v celoti odstraniti iz produkcijskega okolja.
Paketi Composer so drugi velik sklop. Vsaka odvisnost prinese lastno kodo, paketi brez vzdrževanja pa pozneje blokirajo nadgradnje PHP. composer audit prikaže znane ranljivosti, vendar ne nadomešča preverjanja lastne kode.
Kaj posodobitev Laravel zmore in česa ne
Posodobitev Laravel ali posameznih paketov zapre znane napake v tej kodi. PHP ne popravi, ne zažene znova delavcev, ne obnovi iztekle APP_KEY in ne odstrani datotek iz storage ali public. Ali se je pred popravkom kaj zgodilo, je mogoče razjasniti samo s pregledom dnevnikov, datotek in podatkovne zbirke.
Za ekipe s cevovodom za uvajanje velja: posodobitev PHP sodi tudi v okolje gradnje in v osnovne slike, sicer naslednje uvajanje spet prinese staro različico. Preverite tudi, ali so okolja staging ali review javno dosegljiva. Pogosto tečejo z APP_DEBUG=true in pravimi podatki ter se pri varnostnih posodobitvah zlahka spregledajo.
Kako PHP SOS pomaga konkretno?
- Preverimo PHP za splet, CLI in delavce vaše aplikacije Laravel ter spremljamo urejen ponovni zagon vseh procesov.
- Dnevnike od 20. 10. 2026, podatkovno zbirko in stanje kode zavarujemo ter ga uskladimo z vašim repozitorijem.
- Preverimo
.env, predpomnilnik konfiguracije,storage,public, skrbniške račune in žetone API. - Za globlji pregled lastne kode posredujemo varnostni pregled ali penetracijski test prek specializiranih partnerjev.
Pogosta vprašanja
Ali moram zaradi PHP2Shell posodobiti Laravel?
Posodobitev Laravel PHP2Shell ne zapre, ker je ranljivost v interpreterju PHP. Laravel kljub temu ohranjajte aktualen. Za PHP2Shell potrebujete popravljen PHP in ponovni zagon vseh procesov PHP, tudi workerjev.
Zakaj pri Laravelu ponovni zagon PHP-FPM pogosto ne zadošča?
Delavci čakalne vrste, Horizon, Octane in Scheduler tečejo kot lastni procesi PHP prek ukazne vrstice. PHP naložijo enkrat ob zagonu in nato delajo naprej s staro različico v pomnilniku, dokler se ne zaženejo znova.
Kaj storiti, če je datoteka .env morda iztekla?
Takrat obnovite APP_KEY, geslo podatkovne zbirke in vse ključe za zunanje storitve. Upoštevajte, da nov APP_KEY konča obstoječe seje in podatkov, šifriranih s starim ključem, ni več mogoče brati; to načrtujte z razvijalci.