← Wróć do bloga

11 sierpnia 2026 roku Magento 2.4.5 i 2.4.6 straciły wsparcie. Jeśli Twój sklep stoi na jednej z tych wersji, nic się nie zepsuło i pewnie nic nie zauważyłeś — bo brak wsparcia nie wyłącza sklepu. Problem polega na czymś innym: od tej daty nie dostajesz już poprawek bezpieczeństwa, a każda nowa podatność zostaje w Twoim sklepie na stałe. Poniżej: które wersje są jeszcze wspierane, co realnie oznacza zwłoka i jak sensownie zaplanować aktualizację.

Tabela wsparcia wersji Magento na sierpień 2026: wersje 2.4.5 i 2.4.6 bez wsparcia od 11 sierpnia 2026, 2.4.7 wspierana do 31 maja 2027, 2.4.8 do 11 kwietnia 2028, 2.4.9 jako najnowsza do około maja 2029, z uwagą o wersjach PHP

Które wersje są jeszcze wspierane

Stan na sierpień 2026 wygląda tak:

  • 2.4.5 i 2.4.6 — wsparcie zakończone 11 sierpnia 2026.
  • 2.4.7 — wsparcie regularne do 31 maja 2027, rozszerzone do 31 maja 2028.
  • 2.4.8 — wydana 8 kwietnia 2025, wspierana do 11 kwietnia 2028.
  • 2.4.9 — najnowsza, wydana 12 maja 2026, z około trzyletnim oknem wsparcia sięgającym mniej więcej maja 2029.

Ważny wyjątek — i pułapka dla Open Source

Adobe przewidziało dla klientów Adobe Commerce dodatkowy rok wsparcia bez dopłaty dla wersji 2.4.6 i 2.4.7 — w przypadku 2.4.6 obejmuje to poprawki jakościowe i bezpieczeństwa do sierpnia 2027, a następnie okres przejściowy tylko z poprawkami bezpieczeństwa. Tu jest jednak haczyk, o który łatwo się potknąć: to udogodnienie dotyczy wyłącznie klientów Adobe Commerce i nie obejmuje użytkowników Magento Open Source.

Innymi słowy: jeśli prowadzisz sklep na darmowym Magento Open Source w wersji 2.4.6, Twoje wsparcie skończyło się 11 sierpnia i nie ma żadnego przedłużenia. To jedna z tych praktycznych różnic między wersjami, o których pisaliśmy przy porównaniu Magento Open Source i Adobe Commerce.

Co realnie oznacza brak wsparcia

Sklep działa dalej — i to właśnie usypia czujność. Konsekwencje są jednak konkretne:

  • Brak poprawek bezpieczeństwa. Nowe podatności nie zostaną załatane w Twojej wersji. A opisy podatności są publikowane publicznie, więc dla atakujących stają się gotową instrukcją, gdzie i czego szukać.
  • Brak poprawek błędów. Znany błąd zostaje z Tobą albo wymaga obejścia napisanego na własny koszt.
  • Rozjazd ekosystemu. Twórcy rozszerzeń przestają testować nowe wersje pod stare wydania Magento — z czasem coraz trudniej cokolwiek dołożyć lub zaktualizować.
  • Zgodność i audyty. Wymogi po stronie płatności czy audytów bezpieczeństwa mogą wymagać aktualnego, wspieranego oprogramowania.

Sklepy Magento są realnym celem ataków, a niezałatane podatności to jeden z głównych wektorów — rozwinęliśmy ten wątek we wpisie o bezpieczeństwie sklepu Magento.

PHP — druga oś, o której się zapomina

Aktualizacja Magento to nie tylko numer wersji sklepu. Wersja PHP ma własny harmonogram i to zwykle ona generuje najwięcej pracy:

  • 2.4.8 wprowadziła zgodność z PHP 8.4.
  • 2.4.9 obsługuje PHP 8.4 i 8.5, przy czym PHP 8.2 nie jest już wspierane, a PHP 8.3 tylko na potrzeby samej aktualizacji.

Skok wersji PHP wymusza weryfikację wszystkich rozszerzeń i kodu własnego — i to właśnie tam, a nie w rdzeniu Magento, najczęściej wychodzą niezgodności. Jeśli ktoś wycenia Ci aktualizację bez przejrzenia listy modułów, to nie jest wycena, tylko życzenie.

Skok wersji potrafi pociągnąć infrastrukturę

Warto z góry założyć, że przy większym skoku zmieni się nie tylko kod. Dobry przykład: od 2.4.8 wymagany jest OpenSearch, a Elasticsearch został oznaczony jako przestarzały — czyli aktualizacja pociąga za sobą zmianę silnika wyszukiwania i pełną reindeksację. Opisaliśmy to szerzej przy wyszukiwarce produktów w Magento. Podobnie bywa z wersjami bazy danych i innych usług.

Jak wygląda sensowna aktualizacja

Nie „wpiszmy komendę i zobaczmy". Kolejność, która ogranicza ryzyko:

  • Audyt rozszerzeń i kodu własnego — co jest zainstalowane, co jest jeszcze rozwijane, co można wyrzucić. Nieużywany moduł to najtańsza rzecz do usunięcia przed aktualizacją.
  • Środowisko testowe będące kopią produkcji — aktualizacja idzie najpierw tam, nigdy na żywym sklepie.
  • Aktualizacja i naprawa niezgodności — najpierw rdzeń i PHP, potem moduły.
  • Testy krytycznej ścieżki — wyszukiwanie, koszyk, dostawa, płatność, składanie zamówienia, panel administracyjny, integracje z ERP i przewoźnikami.
  • Kopia zapasowa i plan wycofania przed wdrożeniem na produkcję.
  • Wdrożenie w oknie o niskim ruchu i obserwacja przez kolejne dni.

Ile to trwa, zależy przede wszystkim od liczby rozszerzeń i skali modyfikacji własnych, a nie od samego dystansu między wersjami. Sklep blisko standardu bywa gotowy szybko; sklep mocno przerobiony, z wieloma integracjami, wymaga zaplanowanego projektu. Dlatego rzetelna wycena zaczyna się od przejrzenia konkretnej instalacji.

Aktualizacje to proces, nie jednorazowa akcja

Największy błąd to traktowanie aktualizacji jak wydarzenia raz na kilka lat. Im dłuższa zwłoka, tym większy i droższy skok — i tym większe ryzyko, że coś pójdzie nie tak. Sklepy objęte stałym wsparciem aktualizują się mniejszymi krokami: patche bezpieczeństwa na bieżąco, wersje mniejsze regularnie, a skok większej wersji planowany z wyprzedzeniem, zanim wsparcie się skończy — a nie kilka miesięcy po fakcie.

Od czego zacząć

Sprawdź dwie rzeczy. Po pierwsze: na jakiej wersji Magento i PHP stoi Twój sklep — znajdziesz to w panelu administracyjnym lub zapytaj wykonawcę. Po drugie: jeśli to 2.4.5 lub 2.4.6, ustal termin aktualizacji, zamiast odkładać ją bezterminowo, bo od 11 sierpnia jesteś bez poprawek bezpieczeństwa. Nie wiesz, na czym stoisz albo ile pracy wymaga skok do wspieranej wersji? Napisz do nas — przejrzymy instalację, listę rozszerzeń i przygotujemy realny plan aktualizacji.