Ukratko: Shopware 6 sigurnosna ranjivost koju trgovci sada mnogo traže zapravo je ranjivost u PHP-u. Shopware ažuriranja ne zatvaraju je. Potreban Vam je zakrpani PHP s ponovnim pokretanjem svih procesa, a potom biste trebali provjeriti .env, custom/plugins, direktorij public i API integracije.
Što PHP2Shell znači za Shopware 6
Shopware 6 temelji se na PHP frameworku Symfony i uglavnom radi s PHP-FPM-om iza Nginxa ili Apachea. Ranjivosti CVE-2026-109618 i CVE-2026-109619 pogađaju upravo taj način rada. Prema PHP timu omogućuju izvršavanje zlonamjernog koda na daljinu, bez prijave u shop.
Napadač s izvršavanjem koda na poslužitelju doseže sve čemu i sam shop ima pristup: podatke kupaca, narudžbe, dokumente računa, pristupne podatke za robno knjigovodstvo i pružatelje plaćanja. Tehničku pozadinu objašnjavamo na stranici Što je PHP2Shell?.
Provjera Shopware 6 ranjivosti: koji PHP stvarno radi?
Shopware 6 često se održava putem naredbenog retka, primjerice s bin/console. Pritom je lako pogriješiti: php -v prikazuje verziju PHP-a naredbenog retka, a ne nužno verziju PHP-FPM-a koji obrađuje zahtjeve shopa. Na mnogim poslužiteljima paralelno je instalirano više verzija PHP-a.
Pouzdani su podatak u hosting panelu za konkretnu domenu i potvrda pružatelja hostinga o stanju paketa. Ispravljene upstream verzije su 8.5.12, 8.4.27, 8.3.36 i 8.2.35; backportovi mogu nositi starije brojeve. Koje PHP verzije podržava Vaša verzija Shopwarea, provjerite prema sistemskim zahtjevima u dokumentaciji na shopware.com. Kako provjeriti sami, piše u članku Ispravna provjera verzije i stanja zakrpe PHP-a.
Jednu točku kod Shopwarea 6 često previde: mnogi shopovi obrađuju red poruka i planirane zadatke putem trajno pokrenutih pozadinskih procesa, primjerice bin/console messenger:consume pod upraviteljem procesa. Ti procesi PHP učitavaju jednom pri pokretanju. Nakon ažuriranja zato treba ponovno pokrenuti ne samo PHP-FPM nego i te workere. Inače dio shopa i dalje radi sa starim, ranjivim PHP-om u memoriji.
Direktoriji i datoteke koje biste trebali poznavati
| Mjesto | Sadržaj | Zašto je važno |
|---|---|---|
.env, .env.local |
Pristup bazi podataka, APP_SECRET, ostali ključevi |
Nakon sumnje obnoviti |
public/ |
Korijen dokumenata s index.php, medijima, datotekama teme |
Dodatne PHP datoteke su sumnjive |
public/theme/ |
Kompilirane JavaScript i CSS datoteke storefronta | Mjesto za ubačene skimmere |
custom/plugins/, custom/apps/ |
Proširenja | Izmijenjen kôd dodatka |
files/ |
Privatne datoteke poput računa i otpremnica | Osobni podaci |
var/log/ |
Zapisnici shopa | Osigurati tragove |
Neopasne prve provjere:
# Prikaz instaliranih dodataka s verzijom i statusom
bin/console plugin:list
# Ispis PHP datoteka u javnom direktoriju
find public -type f -name "*.php"
# Prikaz poznatih ranjivosti u Composer ovisnostima
composer audit
U mapi public/ smije biti samo nekoliko poznatih PHP datoteka. Sve nepoznato treba sigurnosno kopirati i istražiti, a ne odmah brisati.
U administraciji pod Postavke > Sustav provjerite područja „Korisnici i prava“ i „Integracije“. Nepoznati korisnici ili API integracije stražnja su vrata koja svako skeniranje datoteka previdi.
Admin pristup, dodaci i aplikacije kao rizik
Administracija se prema zadanim postavkama nalazi na /admin. Zaštitite je osobnim računima, jakom prijavom i, ako je moguće, ograničenjem pristupa na poznate mreže. Integracije za robno knjigovodstvo, tržnice ili dostavne službe trebale bi imati samo ona prava koja im doista trebaju.
Dodaci iz trgovine i vlastiti razvoji donose vlastiti PHP kôd, a aplikacije dodatno webhookove prema vanjskim poslužiteljima. Što je više proširenja, veća je površina napada i skuplja je svaka nadogradnja PHP-a. Dodatke koji se više ne koriste uklonite u potpunosti.
Što Shopware ažuriranje može, a što ne
Ažuriranje Shopwarea ili dodatka zatvara poznate pogreške u tom kôdu. Ne može:
- zakrpati PHP na poslužitelju,
- ponovno pokrenuti stare PHP-FPM procese,
- sigurno ukloniti strane datoteke u
public/ili manipulirane datoteke teme, - izbrisati strane korisnike ili integracije,
- dokazati da se prije zakrpe ništa nije dogodilo.
Nakon PHP ažuriranja na novu glavnu verziju trebali biste ponovno generirati predmemoriju i temu te shop provjeriti u testnom okruženju. Prelazak PHP-a s dokazom na zahtjev preuzima naš PHP servis zakrpa.
Shopware 6 kod većih trgovaca često radi na više aplikacijskih poslužitelja. Tada svaki poslužitelj mora biti zakrpan i ponovno pokrenut, čak i oni koji obrađuju samo pozadinske zadatke. Ako shop kao upravljanu platformu vodi pružatelj usluga, trebao bi Vam potvrditi stanje za sve čvorove.
Kako PHP SOS konkretno pomaže?
- Utvrđujemo koji PHP Vaš shop putem FPM-a stvarno koristi te s pružateljem hostinga ili agencijom razjašnjavamo zakrpu i ponovno pokretanje.
- Osiguravamo logove od 20.10.2026., bazu podataka i datoteke.
- Provjeravamo
public/, kompilirane datoteke teme, dodatke, korisnike i integracije na nepravilnosti. - Kod nalaza čistimo shop zajedno s Vašom agencijom te uredno obnavljamo ključeve i pristupe.
Česta pitanja
Pogađa li PHP2Shell sam Shopware 6?
Ranjivosti su u PHP-u, a ne u Shopwareovu kôdu. Svaki Shopware 6 shop na nezakrpanom PHP-u stoga je potencijalno ranjiv, neovisno o verziji Shopwarea. Ažuriranje Shopwarea tu ništa ne mijenja.
Koja je datoteka u Shopwareu 6 nakon napada osobito kritična?
Datoteka .env ili .env.local s pristupom bazi podataka i APP_SECRET-om. Tko ju je mogao pročitati, zna Vaše pristupne podatke. Nakon sumnje te bi vrijednosti trebalo obnoviti, u dogovoru s Vašom agencijom.
Što su integracije u Shopwareu 6 i zašto ih provjeravati?
Integracije su API pristupi za vanjske sustave poput robnog knjigovodstva ili tržnica. Strana integracija s administratorskim pravima omogućuje puni pristup shopu putem API-ja, a da na poslužitelju ne postoji nijedna datoteka.