Īsi: Laravel ievainojamība, ko šobrīd meklē daudzi izstrādātāji, ir PHP2Shell un atrodas pašā PHP. Laravel atjauninājums to neaizver. Svarīgi ir ielāpots PHP, visu procesu, ieskaitot queue worker un Octane, pārstartēšana, kā arī .env, storage un public pārbaude.
Ko PHP2Shell nozīmē Laravel lietojumprogrammām
Laravel ir daudzu pašizstrādātu risinājumu pamats: klientu portāli, iekšējie rīki, rezervēšanas sistēmas, API lietotnēm. PHP ievainojamības CVE-2026-109618 un CVE-2026-109619 saskaņā ar PHP komandu ļauj izpildīt ļaunprātīgu kodu no attāluma bez pieteikšanās. Cik tīrs ir Laravel kods, tam nav nozīmes.
Skarti ir darbības veidi PHP-FPM, Apache ar mod_php, php-cgi, FrankenPHP un LiteSpeed. Laravel Octane var izmantot FrankenPHP kā serveri; tad PHP atrodas FrankenPHP programmā vai konteinera attēlā (image) un tiek atjaunināts kopā ar to. Kā tas izskatās FrankenPHP gadījumā, apraksta raksts FrankenPHP aizsardzība.
Laravel ievainojamība: PHP versijas un procesu pārbaude
Komandrindā php artisan about rāda PHP versiju, Laravel versiju un svarīgus iestatījumus, piemēram, vidi un atkļūdošanas režīmu. Tā tomēr ir CLI PHP versija. Tīmekļa pieprasījumus apstrādā PHP-FPM vai Octane, un tā var būt cita versija. Šaubu gadījumā likt operatoram apstiprināt, kāds pakotnes stāvoklis darbojas visos ceļos.
Labotās upstream versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35, backport labojumiem var būt vecāki numuri. Kuras PHP versijas atbalsta jūsu Laravel versija, pārbaudiet pēc sistēmas prasībām dokumentācijā vietnē laravel.com.
Pēc atjaunināšanas seko tā daļa, ko Laravel gadījumā aizmirst visbiežāk: ilgdzīvojošie procesi.
# Parādīt versijas un konfigurāciju
php artisan about
# Likt queue worker pēc pašreizējā darba beigt darbu
php artisan queue:restart
# Apturēt Horizon, lai procesu pārvaldnieks to startē no jauna
php artisan horizon:terminate
Worker pēc tam pārstartējas tikai tad, ja tos uzrauga procesu pārvaldnieks, piemēram, Supervisor vai systemd. Octane serveri un konteineri jāpārstartē pilnībā vai jāizvieto ar jaunu attēlu (image). Konteineru uzbūvēm ir spēkā PHP ielāpošana Docker konteineros.
Kur Laravel lietojumprogrammas ir ievainojamas
| Vieta | Saturs | Pārbaudes punkts |
|---|---|---|
.env |
APP_KEY, datubāze, pasts, API atslēgas |
Nekad nedrīkst būt izsaucams caur tīmekli |
bootstrap/cache/config.php |
Kešota konfigurācija ar noslēpumiem | Tiesības, izmaiņu datums |
public/ |
Dokumentu sakne ar index.php |
Papildu PHP faili |
storage/app/public |
Augšupielādes, pieejamas caur public/storage |
Nav PHP failu |
storage/logs/ |
laravel.log, bieži ar pieprasījumu datiem |
Saglabāt, nav publiski |
vendor/ |
Composer pakotnes | composer audit, salīdzināšana ar composer.lock |
Mape storage/app/public ir pieejama ar simbolisku saiti zem public/storage. Tur novietots PHP fails atkarībā no servera konfigurācijas var tikt izpildīts tieši. Bloķējiet to tīmekļa servera līmenī.
APP_DEBUG produkcijā jābūt false. Kļūdas lapa ar atkļūdošanas izvadi var parādīt vides mainīgos, ceļus un koda daļas un atvieglo darbu katram uzbrucējam.
Admin saskarnes un pakotnes kā risks
Laravel lietojumprogrammām nav vienotas admin saskarnes. Bieži tie ir pašu apgabali vai pakotnes, piemēram, Filament vai Nova. Pārbaudiet, kam ir admin tiesības, vai pieteikšanās ir ar divfaktoru pakāpi un vai admin maršrutiem vispār jābūt pieejamiem no ārpuses. Arī API pilnvaras (token), piemēram, no Sanctum vai Passport, pēc aizdomām būtu jāatsauc un jāizsniedz no jauna.
Pārbaudiet arī, vai izstrādes rīki produkcijā nav pieejami, piemēram, atkļūdošanas joslas, Telescope vai testa maršruti. Tie bieži rāda pieprasījumus, vaicājumus un konfigurāciju, un tiem jābūt aiz pieteikšanās vai pilnībā noņemtiem no produkcijas vides.
Composer pakotnes ir otrs lielais bloks. Katra atkarība atnes savu kodu, un pakotnes bez uzturēšanas vēlāk bloķē PHP jauninājumus. composer audit rāda zināmas ievainojamības, bet neaizstāj pašu koda pārbaudi.
Ko Laravel atjauninājums var un ko ne
Laravel vai atsevišķu pakotņu atjauninājums aizver zināmas kļūdas šajā kodā. Tas neielāpo PHP, nepārstartē worker procesus, nemaina noplūdušu APP_KEY un nenoņem failus no storage vai public. Vai pirms ielāpa kaut kas ir noticis, var noskaidrot tikai ar žurnālu, failu un datubāzes pārbaudi.
Komandām ar izvietošanas konveijeru (deployment pipeline) ir spēkā: PHP atjauninājums jāveic arī būvēšanas vidē un bāzes attēlos, citādi nākamā izvietošana atkal atnes veco versiju. Pārbaudiet arī, vai staging vai review vides nav publiski pieejamas. Tās bieži darbojas ar APP_DEBUG=true un īstiem datiem, un drošības atjauninājumos tās viegli palaist garām.
Kā PHP SOS palīdz konkrēti?
- Mēs pārbaudām jūsu Laravel lietojumprogrammas tīmekļa, CLI un worker PHP un pavadām sakārtotu visu procesu pārstartēšanu.
- Mēs saglabājam žurnālus no 20.10.2026, datubāzi un koda stāvokli un salīdzinām to ar jūsu repozitoriju.
- Mēs pārbaudām
.env, konfigurācijas kešatmiņu,storage,public, admin kontus un API pilnvaras. - Dziļākai paša koda pārbaudei mēs caur specializētiem partneriem starpnieciski nodrošinām drošības auditu vai penetrācijas testu.
Biežāk uzdotie jautājumi
Vai man PHP2Shell dēļ jāatjaunina Laravel?
Laravel atjauninājums PHP2Shell neaizver, jo ievainojamība atrodas PHP interpretatorā. Laravel tomēr uzturiet aktuālu. PHP2Shell gadījumā vajadzīgs ielāpots PHP un visu PHP procesu pārstartēšana, arī worker procesu.
Kāpēc Laravel bieži nepietiek ar PHP-FPM pārstartēšanu?
Queue worker, Horizon, Octane un Scheduler darbojas kā atsevišķi PHP procesi komandrindā. Tie PHP ielādē vienreiz startēšanas brīdī un pēc tam atmiņā turpina strādāt ar veco versiju, līdz tiek pārstartēti.
Ko darīt, ja .env fails varēja noplūst?
Tad jāmaina APP_KEY, datubāzes parole un visas atslēgas ārējiem pakalpojumiem. Ņemiet vērā, ka jauns APP_KEY beidz esošās sesijas un ar veco atslēgu šifrētus datus vairs nevar nolasīt; plānojiet to kopā ar saviem izstrādātājiem.