# Bezpieczeństwo OXID eShop po PHP2Shell: jak zabezpieczyć sklep i interfejsy

> Zabezpiecz OXID eShop po PHP2Shell: sprawdź stan PHP w panelu admina, skontroluj config.inc.php i moduły oraz zabezpiecz konta i interfejsy B2B.

Źródło: https://phpsos.de/pl/plattformen/oxid-eshop/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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:

```bash
# 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
```

> **Ważne:**
> 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?](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/). Do sytuacji w średnich firmach pasuje artykuł [Bezpieczeństwo IT dla średnich firm i przemysłu](https://phpsos.de/pl/branchen/mittelstand-industrie/).

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](https://phpsos.de/pl/leistungen/incident-response/) 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ć.

## Źródła

- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
- [OXID eSales](https://www.oxid-esales.com/)
- [Obsługiwane wersje PHP](https://www.php.net/supported-versions.php)
- [BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej)](https://www.bsi.bund.de/)