Krótko: Luka bezpieczeństwa Shopware 6, której obecnie szuka wielu sprzedawców, jest w rzeczywistości luką w PHP. Aktualizacje Shopware jej nie zamykają. Potrzebne jest załatane PHP z restartem wszystkich procesów, a następnie kontrola .env, custom/plugins, katalogu public i integracji API.
Co PHP2Shell oznacza dla Shopware 6
Shopware 6 opiera się na frameworku PHP Symfony i działa zwykle z PHP-FPM za Nginx lub Apache. Luki CVE-2026-109618 i CVE-2026-109619 dotyczą właśnie tego trybu pracy. Według zespołu PHP umożliwiają zdalne wykonanie złośliwego kodu, bez logowania do sklepu.
Atakujący z możliwością wykonywania kodu na serwerze sięga po wszystko, do czego ma dostęp sam sklep: dane klientów, zamówienia, dokumenty faktur, dane dostępowe do systemu magazynowego i dostawców płatności. Tło techniczne wyjaśniamy w artykule Czym jest PHP2Shell?.
Sprawdzanie luki w Shopware 6: które PHP naprawdę działa?
Shopware 6 jest w dużej mierze obsługiwany z wiersza poleceń, na przykład za pomocą bin/console. Łatwo tu o błąd: php -v pokazuje wersję PHP wiersza poleceń, niekoniecznie wersję PHP-FPM, które obsługuje żądania sklepu. Na wielu serwerach równolegle zainstalowanych jest kilka wersji PHP.
Wiarygodne są informacja w panelu hostingu dla konkretnej domeny oraz potwierdzenie firmy hostingowej dotyczące stanu pakietu. Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35; backporty mogą nosić starsze numery. To, które wersje PHP obsługuje Państwa wersja Shopware, można sprawdzić w wymaganiach systemowych w dokumentacji na shopware.com. Jak sprawdzić to samodzielnie, opisujemy w artykule Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
W Shopware 6 często pomija się jeden punkt: wiele sklepów przetwarza kolejkę komunikatów i zaplanowane zadania przez stale działające procesy w tle, na przykład bin/console messenger:consume pod menedżerem procesów. Procesy te ładują PHP jeden raz przy starcie. Po aktualizacji trzeba więc zrestartować nie tylko PHP-FPM, ale także te procesy worker. W przeciwnym razie część sklepu nadal działa ze starym, podatnym PHP w pamięci.
Katalogi i pliki, które warto znać
| Miejsce | Zawartość | Dlaczego jest istotne |
|---|---|---|
.env, .env.local |
Dostęp do bazy danych, APP_SECRET, inne klucze |
W razie podejrzenia odnowić |
public/ |
Katalog główny dokumentów z index.php, mediami, plikami motywu |
Dodatkowe pliki PHP są podejrzane |
public/theme/ |
Skompilowane pliki JavaScript i CSS storefrontu | Miejsce na wprowadzone skimmery |
custom/plugins/, custom/apps/ |
Rozszerzenia | Zmieniony kod wtyczek |
files/ |
Pliki prywatne, takie jak faktury i dokumenty wydania | Dane osobowe |
var/log/ |
Logi sklepu | Zabezpieczyć ślady |
Bezpieczne pierwsze kontrole:
# Wyświetlenie zainstalowanych wtyczek z wersją i statusem
bin/console plugin:list
# Wypisanie plików PHP w katalogu publicznym
find public -type f -name "*.php"
# Wyświetlenie znanych luk w zależnościach Composera
composer audit
W folderze public/ powinno leżeć tylko kilka znanych plików PHP. Wszystko nieznane należy zabezpieczyć i zbadać, a nie od razu usuwać.
Proszę sprawdzić w panelu administracyjnym w Ustawienia > System sekcje „Użytkownicy i uprawnienia” oraz „Integracje”. Nieznani użytkownicy lub integracje API to tylne drzwi, które pomija każde skanowanie plików.
Dostęp administratora, wtyczki i aplikacje jako ryzyko
Panel administracyjny domyślnie znajduje się pod /admin. Proszę go chronić kontami osobistymi, silnym logowaniem i, jeśli to możliwe, ograniczeniem dostępu do znanych sieci. Integracje z systemem magazynowym, marketplace'ami lub dostawcami usług wysyłkowych powinny mieć tylko te uprawnienia, których naprawdę potrzebują.
Wtyczki ze sklepu i własne rozwiązania wnoszą własny kod PHP, a aplikacje dodatkowo webhooki do serwerów zewnętrznych. Im więcej rozszerzeń, tym większa powierzchnia ataku i tym bardziej pracochłonna każda aktualizacja PHP. Wtyczki, które nie są już używane, należy usunąć w całości.
Co potrafi aktualizacja Shopware, a czego nie
Aktualizacja Shopware lub wtyczki zamyka znane błędy w tym kodzie. Nie może ona:
- załatać PHP na serwerze,
- zrestartować starych procesów PHP-FPM,
- bezpiecznie usunąć obcych plików w
public/ani zmanipulowanych plików motywu, - usunąć obcych użytkowników lub integracji,
- dowieść, że przed poprawką nic się nie wydarzyło.
Po aktualizacji PHP do nowej wersji głównej należy ponownie wygenerować pamięć podręczną i motyw oraz sprawdzić sklep w środowisku testowym. Na życzenie zmianę PHP z dokumentacją przejmuje nasza usługa łatania PHP.
Shopware 6 działa u większych sprzedawców często na kilku serwerach aplikacji. Wtedy każdy serwer musi być załatany i zrestartowany, także te, które obsługują wyłącznie zadania w tle. Jeśli sklep prowadzi dostawca usług jako platformę zarządzaną, powinien potwierdzić Państwu stan wszystkich węzłów.
Jak konkretnie pomaga PHP SOS?
- Ustalamy, z którego PHP Państwa sklep faktycznie korzysta przez FPM, i uzgadniamy poprawkę oraz restart z firmą hostingową lub agencją.
- Zabezpieczamy logi od 20.10.2026, bazę danych i pliki.
- Sprawdzamy
public/, skompilowane pliki motywu, wtyczki, użytkowników i integracje pod kątem nieprawidłowości. - W razie znaleziska oczyszczamy sklep wspólnie z Państwa agencją i w uporządkowany sposób odnawiamy klucze oraz dostępy.
Częste pytania
Czy sam Shopware 6 jest dotknięty przez PHP2Shell?
Luki tkwią w PHP, a nie w kodzie Shopware. Każdy sklep Shopware 6 działający na niezałatanym PHP jest więc potencjalnie podatny na atak, niezależnie od wersji Shopware. Aktualizacja Shopware niczego tu nie zmienia.
Który plik w Shopware 6 jest po ataku szczególnie krytyczny?
Plik .env lub .env.local z danymi dostępowymi do bazy danych i APP_SECRET. Kto mógł go odczytać, zna Państwa dane dostępowe. W razie podejrzenia wartości te należy odnowić w uzgodnieniu z Państwa agencją.
Czym są integracje w Shopware 6 i dlaczego je sprawdzać?
Integracje to dostępy API dla systemów zewnętrznych, takich jak system magazynowy lub marketplace'y. Obca integracja z uprawnieniami administratora zapewnia pełny dostęp do sklepu przez API, bez żadnego pliku na serwerze.