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.
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):
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
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.
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.
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.
- 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ć.