# Luka bezpieczeństwa Magento i PHP2Shell: jak zabezpieczyć Magento i Adobe Commerce

> Zabezpiecz Magento i Adobe Commerce po PHP2Shell: ustal stan PHP, chroń env.php, znajdź skimmery w bazie i pub/, sprawdź konta administratorów.

Źródło: https://phpsos.de/pl/plattformen/magento-adobe-commerce/  
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:** Aktualna luka bezpieczeństwa Magento nazywa się PHP2Shell i tkwi nie w Magento, lecz w PHP. Poprawka Magento jej nie zamyka. Po aktualizacji PHP z restartem należy sprawdzić `app/etc/env.php`, bazę danych pod kątem skimmerów oraz listę kont administratorów.

## Co PHP2Shell oznacza dla sklepów Magento

Magento Open Source i Adobe Commerce to duże aplikacje PHP, które zwykle działają z PHP-FPM. Luki CVE-2026-109618 i CVE-2026-109619 umożliwiają według zespołu PHP wykonanie złośliwego kodu bez logowania. To, czy sam sklep jest aktualny, nie odgrywa tu roli.

Sklepy Magento od lat są ulubionym celem skimmingu kart kredytowych, w którym dane wpisywane w kasie są podsłuchiwane. PHP2Shell otwiera do tego kolejną drogę. Palo Alto Networks naliczyło ponad 22,6 mln narażonych, potencjalnie podatnych instancji PHP; nie wiadomo, które sklepy się wśród nich znajdują.

## Luka bezpieczeństwa Magento: jak prawidłowo ustalić stan PHP

Magento nie pokazuje wersji PHP w widocznym miejscu w panelu administracyjnym. Stan należy zatem sprawdzić w panelu hostingu dla domeny lub zlecić jego potwierdzenie firmie hostingowej. `php -v` w wierszu poleceń pokazuje wyłącznie PHP CLI, na którym działają `bin/magento` i zadania cron. PHP sieciowe przez FPM może być inną wersją i obie muszą być załatane.

Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a backporty dystrybucji mogą nosić starsze numery. To, które wersje PHP obsługuje Państwa wersja Magento, można sprawdzić w wymaganiach systemowych w dokumentacji Adobe (experienceleague.adobe.com). W przypadku Adobe Commerce na infrastrukturze Adobe proszę zapytać Adobe lub operatora o stan. Instrukcję krok po kroku zawiera artykuł [Jak prawidłowo sprawdzić wersję PHP i stan poprawek](https://phpsos.de/pl/php2shell/php-version-pruefen/).

## Gdzie w Magento siedzi złośliwy kod

| Miejsce | Zawartość | Punkt kontroli |
|---|---|---|
| `app/etc/env.php` | Baza danych, klucz szyfrowania, ścieżka admina | Data zmiany, po podejrzeniu odnowić wartości |
| `pub/` | Katalog główny dokumentów, `pub/media`, `pub/static` | Pliki PHP w folderach media i static |
| `app/code/` | Własne moduły | Nieznane moduły, zmienione pliki |
| `vendor/` | Pakiety Composera, także rozszerzenia | Odstępstwa od pliku lock |
| `generated/`, `var/` | Wygenerowany kod, pamięć podręczna, logi | Zabezpieczyć logi, wygenerować kod od nowa |
| Baza danych | Konfiguracja, bloki CMS, użytkownicy admina | Obce skrypty, nowi administratorzy |

Skimmery leżą w Magento często w bazie danych, na przykład w ustawieniach dodatkowych skryptów w nagłówku lub stopce strony oraz w blokach CMS. Samo skanowanie plików ich nie wykryje. Bezpieczne odczyty pomagają przy pierwszym rzucie oka (prefiks tabel zależnie od instalacji):

```bash
bin/magento info:adminuri
bin/magento module:status
```

```sql
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
```

> **Ważne:**
> Oczyszczona kasa nie oznacza, że dane nie wyciekły. Proszę zabezpieczyć logi od 20.10.2026 i zrzuty bazy danych, zanim usuną Państwo skrypty. Tylko tak można później ustalić, od kiedy i których zamówień dotyczył problem.

## Panel administracyjny i rozszerzenia

Ścieżkę admina w Magento można dowolnie wybrać i znajduje się ona w `env.php`. Trudna do odgadnięcia ścieżka jest sensowna, ale nie zastępuje uwierzytelniania dwuskładnikowego ani ograniczenia do znanych sieci. Proszę regularnie sprawdzać użytkowników admina i ich role, a także integracje i tokeny API.

Rozszerzeń od zewnętrznych dostawców jest w Magento wiele: metody płatności, połączenia z ERP, moduły wyszukiwania i marketingu. Każde z nich wnosi kod, który trzeba sprawdzić przy aktualizacji PHP. Proszę regularnie używać `composer audit` i w całości usuwać wyłączone moduły.

Proszę pamiętać także o procesach w tle. Magento pracuje z zadaniami cron i często z konsumentami kolejek, które działają jako osobne procesy PHP z wiersza poleceń. Po aktualizacji PHP muszą one zostać zrestartowane tak samo jak PHP-FPM. Po zmianie głównej wersji PHP należy ponadto zlecić ponowne zbudowanie wygenerowanego kodu w `generated/` i plików statycznych oraz przeklikać sklep w środowisku testowym, zanim wznowiona zostanie praca produkcyjna. Jak prawidłowo przeprowadzić restart, opisuje artykuł [Restart PHP-FPM i wszystkich procesów worker](https://phpsos.de/pl/php2shell/php-fpm-neustart/).

## Co potrafi aktualizacja Magento, a czego nie

Wydanie Magento lub poprawka bezpieczeństwa od Adobe zamyka błędy w kodzie sklepu. Nie łata PHP, nie restartuje procesów FPM, nie usuwa skryptów z bazy danych i nie kasuje obcych kont administratora. Jeśli kod został już wykonany, potrzebne jest dochodzenie. Jak rozpoznać tylne drzwi, wyjaśnia artykuł [Rozpoznawanie i usuwanie webshelli](https://phpsos.de/pl/ratgeber/webshell-erkennen/).

Dla sprzedawców przyjmujących płatności kartą obowiązuje dodatkowo: proszę sprawdzić wytyczne dostawcy płatności dotyczące incydentów bezpieczeństwa i przed odnowieniem kluczy uzgodnić to z nim. To, czy konieczne jest zgłoszenie do organu nadzorczego ochrony danych, należy ustalić z inspektorem ochrony danych lub prawnikiem.

## Jak konkretnie pomaga PHP SOS?

- Ustalamy PHP sieciowe i CLI na Państwa serwerze Magento oraz prosimy o potwierdzenie poprawki i restartu.
- Zabezpieczamy logi, pliki i bazę danych w sposób możliwy do prześledzenia, w razie potrzeby w ramach naszej [informatyki śledczej](https://phpsos.de/pl/leistungen/it-forensik/).
- Sprawdzamy `env.php`, `pub/`, moduły, tabele konfiguracji, bloki CMS i konta administratorów.
- Oczyszczamy system, odnawiamy klucze i dostępy oraz dokumentujemy okres możliwego naruszenia dla ochrony danych i dostawcy płatności.


## Częste pytania

**Czy poprawka bezpieczeństwa Magento zamyka także PHP2Shell?**  
Nie. Poprawki Magento usuwają błędy w kodzie sklepu. PHP2Shell tkwi w interpreterze PHP na serwerze i zamyka go wyłącznie aktualizacja PHP lub potwierdzony backport z restartem wszystkich procesów.

**Gdzie atakujący ukrywają w Magento skimmery kart kredytowych?**  
Często nie w plikach, lecz w bazie danych, na przykład w ustawieniach dodatkowych skryptów w nagłówku strony lub w blokach CMS. Dlatego w razie podejrzenia zawsze należy sprawdzić także bazę danych.

**Kto łata PHP w Adobe Commerce w chmurze?**  
To zależy od Państwa umowy i środowiska. Proszę zapytać Adobe lub operatora na piśmie o stan PHP i restart. Własne rozszerzenia i zawartość bazy danych pozostają w Państwa odpowiedzialności.

**Dlaczego app/etc/env.php jest tak ważny?**  
Plik zawiera dane dostępowe do bazy danych, klucz szyfrowania i ścieżkę do panelu administracyjnego. Kto mógł go odczytać, może odszyfrować zaszyfrowane wartości i znaleźć panel administracyjny. W razie podejrzenia wartości te należy odnowić.

## Źródła

- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
- [Adobe Commerce](https://business.adobe.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Palo Alto/TechTarget: narażone instancje](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)