Ukratko: Laravel sigurnosna ranjivost koju sada traže mnogi programeri jest PHP2Shell i nalazi se u samom PHP-u. Laravel ažuriranje je ne zatvara. Važni su zakrpani PHP, ponovno pokretanje svih procesa uključujući queue workere i Octane te provjera .env, storage i public.
Što PHP2Shell znači za Laravel aplikacije
Laravel je temelj mnogih vlastitih razvoja: korisničkih portala, internih alata, sustava rezervacija, API-ja za aplikacije. PHP ranjivosti CVE-2026-109618 i CVE-2026-109619 prema PHP timu omogućuju zlonamjerni kôd na daljinu bez prijave. Koliko je Laravel kôd čist, pritom nije važno.
Pogođeni su načini rada PHP-FPM, Apache s mod_php-om, php-cgi, FrankenPHP i LiteSpeed. Laravel Octane može koristiti FrankenPHP kao poslužitelj; tada je PHP u FrankenPHP programu ili u slici kontejnera i ažurira se zajedno s njom. Kako to izgleda kod FrankenPHP-a, opisuje članak Zaštita FrankenPHP-a.
Laravel sigurnosna ranjivost: provjera verzije PHP-a i procesa
U naredbenom retku php artisan about prikazuje verziju PHP-a, verziju Laravela i važne postavke poput okruženja i debug načina. No to je verzija CLI PHP-a. Web zahtjeve obrađuje PHP-FPM ili Octane, a to može biti druga verzija. U slučaju sumnje neka Vam operater potvrdi koje stanje paketa radi na svim putovima.
Ispravljene upstream verzije su 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a backportovi mogu nositi starije brojeve. Koje PHP verzije podržava Vaša verzija Laravela, provjerite prema sistemskim zahtjevima u dokumentaciji na laravel.com.
Nakon ažuriranja slijedi dio koji se kod Laravela najčešće zaboravlja: dugotrajni procesi.
# Prikaz verzija i konfiguracije
php artisan about
# Uputiti queue workere da se završe nakon trenutnog joba
php artisan queue:restart
# Završiti Horizon kako bi ga upravitelj procesa ponovno pokrenuo
php artisan horizon:terminate
Workeri se nakon toga ponovno pokreću samo ako ih nadzire upravitelj procesa poput Supervisora ili systemd-a. Octane poslužitelji i kontejneri moraju se potpuno ponovno pokrenuti odnosno postaviti s novom slikom. Za postave s kontejnerima vrijedi Zakrpavanje PHP-a u Docker kontejnerima.
Gdje su Laravel aplikacije ranjive
| Mjesto | Sadržaj | Točka provjere |
|---|---|---|
.env |
APP_KEY, baza podataka, pošta, API ključevi |
Nikad ne smije biti dostupna putem weba |
bootstrap/cache/config.php |
Predmemorirana konfiguracija s tajnama | Prava, datum izmjene |
public/ |
Korijen dokumenata s index.php |
Dodatne PHP datoteke |
storage/app/public |
Uploadi, dostupni putem public/storage |
Nema PHP datoteka |
storage/logs/ |
laravel.log, često s podacima zahtjeva |
Osigurati, ne javno |
vendor/ |
Composer paketi | composer audit, usporedba s composer.lock |
Mapa storage/app/public dostupna je putem simboličke veze pod public/storage. PHP datoteka odložena tamo može se, ovisno o konfiguraciji poslužitelja, izvršiti izravno. Zabranite to na razini web-poslužitelja.
APP_DEBUG u produkciji mora biti postavljen na false. Stranica pogreške s debug ispisom može prikazati varijable okruženja, putove i dijelove kôda te olakšava posao svakom napadaču.
Admin sučelja i paketi kao rizik
Laravel aplikacije nemaju jedinstveno admin sučelje. Često su to vlastita područja ili paketi poput Filamenta ili Nove. Provjerite tko ima admin prava, ima li prijava dvofaktorski stupanj i moraju li admin rute biti dostupne izvana. I API tokene, primjerice iz Sanctuma ili Passporta, nakon sumnje treba opozvati i izdati nove.
Provjerite i jesu li alati iz razvoja dostupni u produkciji, primjerice debug trake, Telescope ili testne rute. Oni često prikazuju zahtjeve, upite i konfiguraciju te pripadaju iza prijave ili ih treba potpuno ukloniti iz produkcijskog okruženja.
Composer paketi drugi su veliki blok. Svaka ovisnost donosi vlastiti kôd, a paketi bez održavanja kasnije blokiraju nadogradnje PHP-a. composer audit prikazuje poznate ranjivosti, ali ne zamjenjuje pregled vlastitog kôda.
Što Laravel ažuriranje može, a što ne
Ažuriranje Laravela ili pojedinih paketa zatvara poznate pogreške u tom kôdu. Ne zakrpava PHP, ne pokreće ponovno workere, ne obnavlja iscurjeli APP_KEY i ne uklanja datoteke iz storage ili public. Je li se prije zakrpe nešto dogodilo, može se razjasniti samo pregledom logova, datoteka i baze podataka.
Za timove s deployment pipelineom vrijedi: PHP ažuriranje pripada i u build okruženje i u bazne slike, inače sljedeći deployment ponovno donosi staru verziju. Provjerite i jesu li staging ili review okruženja javno dostupna. Često rade s APP_DEBUG=true i stvarnim podacima te se kod sigurnosnih ažuriranja lako previde.
Kako PHP SOS konkretno pomaže?
- Provjeravamo web, CLI i worker PHP Vaše Laravel aplikacije te pratimo uredno ponovno pokretanje svih procesa.
- Osiguravamo logove od 20.10.2026., bazu podataka i stanje kôda te ga uspoređujemo s Vašim repozitorijem.
- Provjeravamo
.env, predmemoriju konfiguracije,storage,public, admin račune i API tokene. - Za dublju provjeru vlastitog kôda posredujemo sigurnosni audit ili penetracijski test putem specijaliziranih partnera.
Česta pitanja
Moram li zbog PHP2Shella ažurirati Laravel?
Laravel ažuriranje ne zatvara PHP2Shell jer je ranjivost u PHP interpreteru. Laravel ipak održavajte aktualnim. Za PHP2Shell trebate zakrpani PHP i ponovno pokretanje svih PHP procesa, i workera.
Zašto kod Laravela ponovno pokretanje PHP-FPM-a često nije dovoljno?
Queue workeri, Horizon, Octane i Scheduler rade kao zasebni PHP procesi putem naredbenog retka. PHP učitavaju jednom pri pokretanju i potom rade sa starom verzijom u memoriji dok se ponovno ne pokrenu.
Što učiniti ako je datoteka .env možda iscurjela?
Tada biste trebali obnoviti APP_KEY, lozinku baze podataka i sve ključeve za vanjske usluge. Imajte na umu da novi APP_KEY prekida postojeće sesije i čini podatke šifrirane starim ključem nečitljivima; to planirajte sa svojim razvojnim timom.