Rok 2026 był dla Magento wyjątkowo nieprzyjemny. Dwie krytyczne podatności w samym rdzeniu, jedna z najwyższą możliwą oceną zagrożenia i atakami, które ruszyły zanim pojawiła się poprawka. Do tego luki w popularnych rozszerzeniach — i to właśnie ta druga część jest najciekawsza, bo pokazuje coś, co łatwo przeoczyć: aktualizowanie samego Magento zamyka tylko połowę listy.
Uwaga: wszystkie numery, daty i wersje w tym tekście pochodzą z biuletynów Adobe, publikacji firmy Sansec i komunikatów producentów rozszerzeń. Celowo nie podajemy krążących w sieci odsetków „zaatakowanych sklepów” — różne źródła podają różne wartości, a bez wyjaśnienia metodologii taka liczba wprowadza w błąd.
StyleSmuggler — najpoważniejszy przypadek roku
CVE-2026-75650, ocena CVSS 10,0 — maksymalna. Nieuwierzytelnione zdalne wykonanie kodu, czyli najgorszy możliwy wariant: atakujący nie potrzebuje żadnego konta ani hasła.
Mechanizm jest nietypowy i warto go rozumieć, bo tłumaczy, dlaczego luka wymknęła się uwadze. Atakujący wstrzykuje kod PHP do systemu szablonów Magento, ale kod nie wykonuje się od razu — czeka na moment wygenerowania konkretnej wiadomości e-mail: przypomnienia o nieudanej transakcji płatniczej. Ładunek i jego uruchomienie są rozdzielone w czasie.
Podatne są wszystkie wersje od 2.4.4 do 2.4.9 włącznie. Adobe opublikowało awaryjną poprawkę w biuletynie APSB26-146 z 7 września 2026, z najwyższym priorytetem wdrożenia. Problem w tym, że ataki ruszyły 4 września — trzy dni wcześniej. W opisywanych przypadkach atakujący instalowali w sklepach trwały dostęp: backdoor i powłokę sieciową w PHP.
Konsekwencja praktyczna: przy tej podatności samo wgranie poprawki nie wystarcza. Jeśli sklep stał bez niej po 4 września, trzeba założyć, że mógł zostać zaatakowany, i sprawdzić go pod kątem śladów włamania.
PolyShell — i niewygodna luka w czasie
CVE-2026-48356, ocena CVSS 9,3. Nieuwierzytelnione wgranie pliku przez REST API — konkretnie przez punkt obsługujący koszyk gościa. Plik podszywa się pod obrazek produktu, przechodzi walidację i ląduje na serwerze jako kod.
Podatność ujawniono 17 marca 2026. Pierwszym wydaniem zawierającym poprawkę było Magento 2.4.9 z 12 maja, a poprawki dla starszych linii pojawiły się dopiero w lipcowym biuletynie APSB26-73. Kwietniowe wydanie kwartalne jej nie zawierało.
To jest moment, który warto zapamiętać: przez kilka miesięcy sklepy na wspieranych, regularnie łatanych wersjach produkcyjnych nie miały dostępnej poprawki na publicznie znaną, krytyczną podatność. Argument „jesteśmy na bieżąco z kwartalnymi aktualizacjami” nie zawsze wystarcza — czasem jedynym sposobem zamknięcia luki jest przejście na nowszą linię.
Magefan Blog — wyciek danych, nie przejęcie serwera
CVE-2026-79323, moduł magefan/module-blog-graph-ql. Tu nie chodzi o wykonanie kodu, tylko o ujawnienie informacji — co w kontekście RODO bywa równie kosztowne.
Nieuwierzytelniony atakujący mógł wysłać zapytanie POST do punktu /graphql, wywołać zapytanie blogComments i otrzymać w odpowiedzi adresy e-mail osób komentujących wpisy oraz wewnętrzne identyfikatory klientów i administratorów. Dotyczyło to sklepów z włączonymi komentarzami Magefan, w których komentarze faktycznie istniały.
Podatne są wersje do 2.2.1 włącznie, w trzech modułach: Magefan_BlogGraphQl, Magefan_SecondBlogGraphQl i Magefan_ThirdBlogGraphQl. Poprawka jest w wersji 2.2.2 i producent zaleca natychmiastową aktualizację. Opis podatności opublikował na własnym blogu.
Jest też obejście wartościowe samo w sobie jako wzorzec postępowania: sklepy, które nie działają w architekturze headless, mogą po prostu wyłączyć moduły Blog GraphQL w pliku app/etc/config.php. Jeśli moduły są już wyłączone, a komentarzy Magefan nie używacie, nie trzeba robić nic. Ta sama logika działa przy wielu podatnościach: zanim pojawi się poprawka, często wystarczy odciąć nieużywaną funkcję.
Amasty Order Attributes — wgranie pliku bez logowania
CVE-2026-53787, ocena CVSS 9,8, ujawnione 12 czerwca 2026. Punkt przyjmujący pliki akceptował dowolny typ i dowolną nazwę — bez uwierzytelnienia, bez walidacji sesji, bez kontekstu koszyka. Atakujący mógł zapisać plik wprost w katalogu mediów sklepu.
I tu jest warunek, który decyduje o skali szkody: wgranie pliku zamienia się w przejęcie sklepu dopiero wtedy, gdy katalog mediów pozwala wykonywać kod PHP. To ustawienie serwera, nie Magento — i jedna z tych rzeczy, które warto sprawdzić niezależnie od wszystkiego innego.
Podatne są wszystkie wersje poniżej 4.0.0, czyli do 3.16.0 włącznie. W lipcu 2026 Amasty wydało zbiorczy zestaw poprawek obejmujący kilkadziesiąt rozszerzeń, w tym dwie pozycje krytyczne.
Wniosek pierwszy: aktualizuj rdzeń
Brzmi banalnie, ale rok 2026 dodał do tej rady konkret. Przy StyleSmuggler liczy się nie numer wersji, tylko poziom poprawek — podatne były wszystkie wydania od 2.4.4 po najnowsze. Przy PolyShell z kolei okazało się, że bycie na wspieranej linii nie zawsze oznacza dostęp do poprawki.
Praktycznie: warto wiedzieć, na jakiej wersji i jakim poziomie poprawek stoi sklep, i mieć gotową ścieżkę szybkiego wdrożenia łatki. To jedna z rzeczy, które decydują, czy awaryjna poprawka wchodzi tego samego dnia, czy za trzy tygodnie — i jeden z powodów, dla których sklepy objęte stałym wsparciem reagują na takie biuletyny szybciej niż te, w których trzeba najpierw znaleźć wolnego programistę. Mechanikę cyklu wsparcia opisaliśmy we wpisie o wsparciu wersji Magento.
Wniosek drugi: rdzeń to połowa pracy
To jest rzecz, którą warto wynieść z tego zestawienia. Dwie z czterech opisanych podatności nie dotyczą Magento, tylko rozszerzeń — a rozszerzenia mają własny obieg zgłoszeń, własne numery CVE i własny harmonogram wydań, niezależny od biuletynów Adobe.
Sklep aktualizowany wzorowo co do rdzenia może więc mieć otwartą krytyczną lukę w module, o którym nikt nie pamięta, bo „działa od lat”. Stąd dwa pytania warte zadania dzisiaj:
- Czy ktokolwiek śledzi komunikaty bezpieczeństwa producentów rozszerzeń, które macie zainstalowane? Jeśli odpowiedź brzmi „chyba nikt”, to jest dokładnie ta część opieki nad sklepem, która zwykle wypada jako pierwsza.
- Czy wiecie, które rozszerzenia faktycznie są włączone — i czy wszystkie są jeszcze do czegoś używane?
Drugie pytanie bywa najtańszą poprawką bezpieczeństwa w całym sklepie. Moduł wyłączony nie ma podatności.
Co zrobić w tym tygodniu
- Ustal wersję i poziom poprawek swojego sklepu. Bez tego reszta jest zgadywaniem.
- Sprawdź, czy wszedł APSB26-146. Jeśli nie — to pozycja numer jeden, przed wszystkim innym.
- Jeśli sklep stał bez tej poprawki po 4 września, potraktuj go jako potencjalnie zaatakowany i poszukaj śladów włamania, zamiast zakładać, że obyło się bez. To zadanie dla kogoś, kto wie, czego szukać — jeśli nie macie takiej osoby, pomagamy w tym w ramach wsparcia.
- Wypisz zainstalowane rozszerzenia i sprawdź komunikaty ich producentów. Zacznij od Magefan i Amasty, jeśli ich używacie.
- Sprawdź, czy katalog mediów wykonuje PHP. To ustawienie zamienia wgranie pliku w przejęcie sklepu.
- Wyłącz moduły, z których nie korzystacie.
Szerzej o tym, jak poukładać ten proces na stałe, zamiast reagować przy każdym biuletynie, piszemy we wpisie o bezpieczeństwie sklepu Magento.