Krótko: W kwestii bezpieczeństwa OXID eShop chodzi po PHP2Shell najpierw o serwer: luka leży w PHP, a nie w OXID. Proszę zlecić potwierdzenie stanu PHP i restart wszystkich procesów. Następnie należy sprawdzić config.inc.php, moduły, pliki motywu, konta admina oraz dostępy do ERP i usług płatniczych.
Dlaczego sklepy OXID wymagają szczególnej uwagi
OXID eShop jest w krajach niemieckojęzycznych rozpowszechniony przede wszystkim w handlu B2B, u producentów ze sprzedażą bezpośrednią i w handlu hurtowym. Takie sklepy rzadko są rozwiązaniami wyspowymi: wymieniają zamówienia, ceny, stany magazynowe i dane klientów z ERP, PIM i usługami płatniczymi. Atakujący na serwerze sklepu widzi więc często więcej niż tylko sklep.
Luki PHP CVE-2026-109618 i CVE-2026-109619 umożliwiają według zespołu PHP zdalne wykonanie złośliwego kodu bez logowania. To, czy sam OXID jest aktualny, nie odgrywa tu roli. Typowe dane w sklepach OXID to:
- klienci firmowi z osobami kontaktowymi, adresami, numerami klientów i indywidualnymi cenami
- historia zamówień i zapytania ofertowe
- dane dostępowe do ERP oraz usług płatniczych i wysyłkowych w konfiguracji i ustawieniach modułów
- konta pracowników w panelu admina
Bezpieczeństwo OXID eShop: jak prawidłowo sprawdzić stan PHP
W panelu admina Service > Systeminfo pokazuje dane PHP działającego sklepu. Jest to wersja sieciowa, która obsługuje klientów. Konsola OXID, importy i zadania cron działają natomiast często na PHP wiersza poleceń, które może być inną wersją. Obie muszą być załatane.
Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dystrybucje i firmy hostingowe dostarczają poprawki czasem jako backport, a numer pozostaje wtedy ten sam; rozstrzygający jest potwierdzony stan pakietów. To, które wersje PHP obsługuje Państwa wersja OXID, można sprawdzić w wymaganiach systemowych w dokumentacji producenta na oxid-esales.com.
Starsze sklepy OXID generacji 4 lub wczesnych wersji generacji 6 często nadal działają na starych wersjach PHP bez oficjalnych aktualizacji. Wtedy do czasu aktualizacji potrzebna jest ochrona przejściowa i stały harmonogram.
Katalogi i pliki w OXID
Od OXID 6 sklep instaluje się przez Composera; katalogiem głównym dokumentów jest zwykle katalog source/.
| Miejsce | Zawartość | Punkt kontroli |
|---|---|---|
source/config.inc.php |
Dane dostępowe do bazy danych, ustawienia podstawowe | Dopisany kod, po podejrzeniu zmienić hasło |
source/modules/ (do OXID 6), od OXID 7 vendor/ |
Moduły, częściowo z pakietów Composera | Nieznane moduły, zmienione pliki |
var/configuration/ |
Konfiguracja modułów i sklepu w plikach | Nieoczekiwane zmiany |
source/out/ |
Motywy, obrazy, JavaScript | Obce skrypty, pliki PHP w folderach obrazów |
source/tmp/ |
Skompilowane szablony i pamięć podręczna | Po oczyszczeniu opróżnić |
source/log/ |
Log sklepu | Zabezpieczyć przed zmianami |
Skompilowane szablony w katalogu tmp często się pomija. Składają się z kodu PHP i po oczyszczeniu są generowane od nowa; dlatego folder należy opróżniać po każdym znalezisku.
Bezpieczne pierwsze kontrole:
# Pliki PHP w folderach obrazów i mediów
find source/out -type f -name "*.php"
# Pliki modułów zmienione od 17.10.2026 (OXID 6; od OXID 7 moduły leżą w vendor/)
find source/modules -type f -newermt "2026-10-17"
# Znane luki w zależnościach
composer audit
Oczyszczony serwer sklepu nie sprawia, że wyciekłe dostępy do interfejsów znów stają się tajne. W razie podejrzenia proszę odnowić dane dostępowe do ERP oraz usług płatniczych i wysyłkowych w uzgodnieniu z ich operatorami.
Panel admina i moduły
Panel admina znajduje się domyślnie pod /admin/. Proszę sprawdzić zarządzanie użytkownikami pod kątem kont z prawami administratora, których nikt nie potrafi przypisać, oraz dostępów byłych dostawców usług. Dostęp admina należy, jeśli to możliwe, ograniczyć do sieci firmowej lub VPN; w środowisku B2B zwykle jest to dobrze wykonalne.
Moduły do metod płatności, połączenia z ERP, funkcji B2B, takich jak ceny progowe czy procesy akceptacji, są w sklepach OXID często indywidualnie dostosowywane. Każdy moduł to własny kod PHP, a dostosowane moduły często hamują aktualizacje PHP. Proszę zapisać, które moduły są aktywne, kto je prowadzi i czy istnieje wersja dla docelowej wersji PHP.
Co potrafi aktualizacja OXID, a czego nie
Aktualizacja OXID lub modułu zamyka znane błędy w tym kodzie i może umożliwić nowsze wersje PHP. Nie łata PHP i nie restartuje ani PHP-FPM, ani procesów w tle. Obce pliki w source/out, zmanipulowane moduły, skompilowane szablony i nowe konta admina pozostają. To, czy są oznaki ataku, sprawdzą Państwo za pomocą artykułu Czy już doszło do kompromitacji?. Do sytuacji w średnich firmach pasuje artykuł Bezpieczeństwo IT dla średnich firm i przemysłu.
Wiele sklepów OXID ma obok systemu produkcyjnego środowisko stagingowe na tym samym lub drugim serwerze. Proszę je również sprawdzić i załatać, ponieważ często zawiera kopię danych klientów i jest równie przydatne dla atakujących.
Jak konkretnie pomaga PHP SOS?
- Ustalamy PHP sieciowe i CLI na Państwa serwerze OXID oraz prosimy o potwierdzenie poprawki i restartu.
- Zabezpieczamy logi od 20.10.2026, pliki i bazę danych.
- Sprawdzamy
config.inc.php, moduły, motywy, skompilowane szablony i konta admina. - W razie podejrzenia koordynujemy w ramach naszej usługi reagowania na incydenty oczyszczanie i odnowienie dostępów do interfejsów z Państwa agencją i dostawcami ERP.
Częste pytania
Czy OXID eShop jest dotknięty przez PHP2Shell?
PHP2Shell nie jest luką OXID, lecz luką w PHP. Każdy sklep OXID na serwerze z niezałatanym PHP jest więc potencjalnie podatny na atak. Aktualizacja OXID nie zamyka tej luki.
Gdzie w OXID zobaczę wersję PHP?
W panelu admina w Service > Systeminfo, gdzie wyświetlane są dane PHP działającego sklepu. Tego, czy wprowadzono backport, nie widać po numerze; potwierdza to Państwa firma hostingowa lub operator.
Który plik OXID zawiera dane dostępowe?
Plik config.inc.php w katalogu source. Zawiera dane dostępowe do bazy danych. W razie podejrzenia należy zmienić hasło do bazy danych i sprawdzić plik pod kątem dopisanego kodu.
Czy musimy sprawdzić nasz interfejs ERP?
Tak. Jeśli atakujący wykonał kod na serwerze sklepu, mógł odczytać dane dostępowe do ERP, PIM lub usług płatniczych. W razie podejrzenia dostępy te należy odnowić.