SKLEPINTERNETOWY.BIZPoradniki i wiedza e-commerce
Poradnik›BEZPIECZEŃSTWO›Krytyczna luka w Magento i Adobe Commerce. CVE-2026-103849…
BEZPIECZEŃSTWO

Krytyczna luka w Magento i Adobe Commerce. CVE-2026-103849 pozwala przejąć serwer sklepu bez logowania

30 października 202617 min czytanianetpoint

Właściciele sklepów internetowych działających na Magento Open Source i Adobe Commerce powinni pilnie zweryfikować stan zabezpieczeń swoich instalacji. 13 października 2026 roku Adobe opublikowało biuletyn bezpieczeństwa APSB26-153, obejmujący krytyczną podatność CVE-2026-103849, znaną również pod nazwą BlockStrap. Luka otrzymała maksymalną ocenę 10,0 punktów w skali CVSS i w określonych warunkach umożliwia zdalne wykonanie kodu na serwerze sklepu bez konieczności logowania do panelu administracyjnego. Problem dotyczy mechanizmu przetwarzania szablonów wiadomości e-mail, a jego skuteczne wykorzystanie może prowadzić do przejęcia aplikacji, dostępu do poufnych informacji oraz ingerencji w funkcjonowanie sprzedaży internetowej. Adobe udostępniło odpowiednie poprawki, jednak ich instalacja wymaga szczególnej uwagi, ponieważ standardowa aktualizacja pakietów przez Composer nie musi usuwać podatności.

Specjaliści firmy Sansec, zajmującej się bezpieczeństwem sklepów internetowych, potwierdzili możliwość wykorzystania błędu i odtworzyli cztery różne scenariusze prowadzące do wykonania kodu na serwerze. Jednocześnie w opublikowanych dotychczas komunikatach nie potwierdzono masowych ataków wykorzystujących bezpośrednio CVE-2026-103849. Należy jednak podkreślić, że brak informacji o aktywnych włamaniach nie oznacza, że podatne sklepy są bezpieczne. Szczególnie niepokojące jest podobieństwo nowej podatności do wcześniejszego błędu StyleSmuggler, którego wykorzystanie doprowadziło do rzeczywistych ataków na sklepy Magento. W przypadku BlockStrap najważniejszym działaniem pozostaje sprawdzenie obecności październikowych poprawek bezpieczeństwa oraz niezależnej poprawki usuwającej wcześniejszą podatność mechanizmu szablonów.

Czym jest BlockStrap i podatność CVE-2026-103849?

BlockStrap to nazwa nadana krytycznej podatności bezpieczeństwa wykrytej w mechanizmie przetwarzania szablonów Magento i Adobe Commerce. Problem został sklasyfikowany jako CWE-1336, czyli nieprawidłowe neutralizowanie specjalnych elementów wykorzystywanych przez silnik szablonów. W praktyce oznacza to, że odpowiednio przygotowane dane mogą zostać potraktowane przez aplikację nie jako zwykła treść, lecz jako instrukcje przeznaczone do wykonania przez mechanizm generujący dokumenty lub wiadomości. W przypadku Magento szczególnie istotne jest to, że system szablonów współpracuje z funkcjami serwerowymi odpowiedzialnymi za renderowanie dynamicznych elementów. Jeżeli niebezpieczna instrukcja zostanie przetworzona w odpowiednim kontekście, może doprowadzić do wykonania nieautoryzowanego kodu na serwerze.

Adobe potwierdziło, że CVE-2026-103849 może prowadzić do wykonywania dowolnego kodu w kontekście uprawnień procesu obsługującego aplikację. Producent nadał podatności maksymalną ocenę CVSS 10,0, wskazując na możliwość wykorzystania jej zdalnie, bez uwierzytelnienia oraz bez konieczności podejmowania jakichkolwiek działań przez użytkownika sklepu. Tak wysoka ocena wynika z potencjalnego wpływu na poufność, integralność i dostępność systemu, czyli trzech podstawowych obszarów bezpieczeństwa informacji. Podatność została zgłoszona przez badacza posługującego się pseudonimem vozec, a poprawkę opublikowano w biuletynie APSB26-153 z 13 października 2026 roku. Warto podkreślić, że ocena 10,0 nie oznacza automatycznie przejęcia wszystkich sklepów Magento, lecz maksymalną techniczną powagę zagrożenia dla instalacji, w których podatny mechanizm pozostaje niezabezpieczony.

Jak działa atak na mechanizm szablonów Magento?

Magento wykorzystuje rozbudowany system szablonów do generowania wiadomości transakcyjnych, powiadomień i innych dynamicznych treści wysyłanych klientom oraz administratorom. W szablonach mogą znajdować się specjalne dyrektywy, które umożliwiają podstawianie danych zamówienia, informacji o kliencie lub elementów generowanych przez aplikację. Prawidłowo działający mechanizm powinien rozpoznawać wyłącznie dopuszczone instrukcje i nie pozwalać, aby dowolna zawartość pochodząca z niezaufanego źródła została zinterpretowana jako polecenie systemowe. W przypadku BlockStrap wykryto problem związany z ponownym przetwarzaniem dyrektyw występujących w zagnieżdżonych szablonach. Odpowiednio przygotowana zawartość mogła w ten sposób przejść przez mechanizmy zabezpieczeń i zostać ponownie zinterpretowana w kontekście umożliwiającym wykonanie niebezpiecznej operacji.

Analiza Sansec wskazuje, że problem obejmuje sposób obsługi dyrektyw używanych przez silnik szablonów Magento, w tym mechanizm związany z dyrektywą {{block}}. W określonych warunkach dane kontrolowane przez napastnika mogą zostać przetworzone przez szablon podrzędny, a następnie ponownie zinterpretowane na wyższym poziomie renderowania. Taki przebieg pozwala ominąć część zabezpieczeń, które miały zapobiegać wykonywaniu nieautoryzowanych instrukcji. Nie jest to więc zwykły błąd wyświetlania tekstu ani klasyczna podatność XSS, która ogranicza się do wykonywania JavaScript w przeglądarce użytkownika. W przypadku BlockStrap zagrożenie dotyczy kodu wykonywanego po stronie serwera, co może mieć znacznie poważniejsze konsekwencje dla całej instalacji sklepu.

Czy cyberprzestępca może przejąć sklep Magento bez logowania?

Jedną z najgroźniejszych cech CVE-2026-103849 jest brak wymogu posiadania konta użytkownika lub dostępu do panelu administracyjnego Magento. Oficjalny biuletyn Adobe jednoznacznie wskazuje, że wykorzystanie podatności nie wymaga uwierzytelnienia ani interakcji ze strony użytkownika. Oznacza to, że atak może zostać zainicjowany zdalnie, jeżeli napastnik uzyska możliwość przekazania odpowiednio przygotowanych danych do podatnego procesu przetwarzania szablonów. Nie musi wcześniej znać hasła administratora, przejmować konta pracownika ani uzyskiwać bezpośredniego dostępu do infrastruktury hostingowej. Nadal konieczne jest jednak dotarcie do konkretnej podatnej ścieżki przetwarzania danych, dlatego nie każde żądanie HTTP skierowane do sklepu automatycznie prowadzi do wykonania kodu.

Badacze Sansec poinformowali, że w ciągu 24 godzin od publikacji poprawki udało im się odtworzyć cztery różne drogi prowadzące do zdalnego wykonania kodu. Potwierdza to, że podatność nie ogranicza się do czysto teoretycznego błędu, którego praktyczne wykorzystanie byłoby niemożliwe. Nie należy jednak mylić technicznego potwierdzenia działania luki z udokumentowanymi atakami na rzeczywiste sklepy internetowe. Samo wykonanie kodu następuje również w granicach uprawnień procesu aplikacji, a nie automatycznie z uprawnieniami administratora systemu Linux. Mimo tego proces obsługujący Magento posiada zwykle dostęp do istotnych plików i usług potrzebnych do funkcjonowania sklepu, dlatego przejęcie jego kontekstu wykonania może prowadzić do bardzo poważnego naruszenia bezpieczeństwa.

Które wersje Magento i Adobe Commerce są zagrożone?

Podatność CVE-2026-103849 dotyczy kilku gałęzi oprogramowania Adobe Commerce, Adobe Commerce B2B oraz Magento Open Source. Według biuletynu APSB26-153 zagrożone są instalacje Adobe Commerce z gałęzi od 2.4.4 do 2.4.9, które nie otrzymały odpowiednich poprawek październikowych. W przypadku Magento Open Source Adobe wymienia podatne gałęzie 2.4.6, 2.4.7, 2.4.8 oraz 2.4.9. Wersje oznaczone poziomem zabezpieczeń 2026-sep i wcześniejszym pozostają podatne, jeżeli nie zastosowano poprawek rozwiązujących konkretny problem. Sama informacja o zainstalowaniu najnowszego wydania podstawowej gałęzi, bez sprawdzenia dodatkowych łatek, nie jest wystarczającym potwierdzeniem bezpieczeństwa.

Adobe Commerce B2B posiada dodatkowe komponenty i własne oznaczenia wersji, dlatego administratorzy sklepów hurtowych powinni sprawdzić również odpowiednie poprawki dla tego rozszerzenia. W biuletynie wymieniono gałęzie B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 oraz 1.5.3, dla których udostępniono październikowe wydania bezpieczeństwa. Szczególnej uwagi wymagają sklepy Magento Open Source 2.4.6, ponieważ Adobe nie udostępniło dla tej gałęzi publicznej październikowej poprawki na takich samych zasadach jak dla wersji 2.4.7 i nowszych. W przypadku starszych instalacji konieczna może być migracja do wspieranej gałęzi albo zastosowanie odpowiedniego rozwiązania dostępnego w ramach posiadanej licencji. Administrator nie powinien wybierać poprawki wyłącznie na podstawie podobieństwa numerów wersji, ponieważ pakiety są przygotowywane dla konkretnych wydań i komponentów.

Jakie mogą być konsekwencje skutecznego wykorzystania BlockStrap?

Zdalne wykonanie kodu na serwerze sklepu internetowego jest jednym z najpoważniejszych scenariuszy naruszenia bezpieczeństwa aplikacji. Jeżeli napastnik uzyska możliwość uruchamiania instrukcji w kontekście procesu obsługującego Magento, może próbować odczytywać pliki dostępne dla tego procesu, modyfikować elementy aplikacji oraz wykonywać operacje, do których posiada on uprawnienia. W typowym środowisku Magento szczególnie istotne są pliki konfiguracyjne zawierające informacje potrzebne do komunikacji z bazą danych i innymi usługami. Dostęp do odpowiednich danych uwierzytelniających może umożliwić dalszą ingerencję w środowisko sklepu, o ile pozostałe zabezpieczenia nie ograniczają takich działań. Potencjalne skutki zależą od konfiguracji hostingu, uprawnień procesów, sposobu przechowywania sekretów i izolacji poszczególnych usług.

Dla właściciela sklepu najbardziej dotkliwe mogą być konsekwencje związane z bezpieczeństwem danych klientów i obsługą zamówień. Magento przechowuje informacje dotyczące transakcji, produktów, adresów dostaw, kont użytkowników oraz integracji z systemami zewnętrznymi, dlatego uzyskanie nieautoryzowanego dostępu do odpowiednich zasobów może doprowadzić do naruszenia poufności danych. Po skutecznym przejęciu aplikacji napastnik mógłby również próbować modyfikować stronę finalizacji zamówienia, wstrzykiwać złośliwy JavaScript lub przekierowywać kupujących do fałszywych formularzy płatności. Tego rodzaju działania są znane z ataków web skimming i kampanii Magecart, ale nie ma podstaw, aby twierdzić, że zostały już potwierdzone w ramach CVE-2026-103849. Podatność BlockStrap stwarza możliwość poważnej ingerencji w aplikację, natomiast rzeczywiste skutki każdego incydentu wymagają odrębnego potwierdzenia.

Czym BlockStrap różni się od wcześniejszej podatności StyleSmuggler?

BlockStrap nie jest pierwszym krytycznym problemem dotyczącym mechanizmu szablonów Magento wykrytym jesienią 2026 roku. We wrześniu ujawniono podatność StyleSmuggler, oznaczoną CVE-2026-75650, która również otrzymała maksymalną ocenę CVSS 10,0 i umożliwiała zdalne wykonanie kodu bez uwierzytelnienia. Adobe udostępniło wówczas osobną poprawkę bezpieczeństwa, znaną pod identyfikatorem VULN-39341, której zadaniem było ograniczenie możliwości przemycania niebezpiecznych dyrektyw przez mechanizm szablonów. BlockStrap wykorzystuje inny aspekt tego samego obszaru funkcjonalnego, związany z ponownym przetwarzaniem zagnieżdżonych instrukcji. Oznacza to, że zastosowanie wrześniowej poprawki nie jest równoznaczne z usunięciem październikowej podatności.

Różnica ma bezpośrednie znaczenie dla administratorów, ponieważ oba błędy wymagają odrębnych zabezpieczeń. Adobe wyraźnie wskazuje, że poprawka dla CVE-2026-75650 nie została dołączona do październikowego pakietu Isolated Security Patch i musi zostać zastosowana oddzielnie. Z kolei obecność wrześniowego hotfixu nie oznacza, że sklep został zabezpieczony przed CVE-2026-103849. W praktyce sklep może posiadać jedną z tych poprawek, a mimo to nadal pozostawać podatny na drugą lukę. Administratorzy powinni zatem zweryfikować komplet zabezpieczeń mechanizmu szablonów, a nie ograniczać kontrolę do sprawdzenia pojedynczego numeru CVE.

Jakie poprawki bezpieczeństwa udostępniło Adobe?

13 października 2026 roku Adobe udostępniło aktualizację APSB26-153, która usuwa CVE-2026-103849 oraz dziesięć innych podatności bezpieczeństwa. Wśród nich znalazły się również błędy umożliwiające wykonanie kodu, podnoszenie uprawnień, zapisywanie plików w nieautoryzowanych lokalizacjach oraz obchodzenie mechanizmów zabezpieczeń. Dla Adobe Commerce przygotowano poprawione wydania oznaczone jako 2.4.4-2026-oct, 2.4.5-2026-oct, 2.4.6-2026-oct, 2.4.7-2026-oct, 2.4.8-2026-oct i 2.4.9-2026-oct. Dla Magento Open Source oficjalnie udostępnione październikowe poziomy poprawek obejmują gałęzie 2.4.7, 2.4.8 i 2.4.9. Adobe wymienia również wersję 2.4.10-alpha1 jako zawierającą poprawkę, ale jest to wydanie testowe, którego nie należy traktować jako docelowej wersji produkcyjnej sklepu.

Poprawki udostępniono w postaci pakietów Isolated Security Patch, czyli oddzielnych plików aktualizujących określone elementy aplikacji bez konieczności przeprowadzania pełnego uaktualnienia całego systemu. Dla Magento Open Source dostępne są między innymi pakiety przeznaczone dla wersji 2.4.7-p10, 2.4.8-p5 oraz 2.4.9. W przypadku Adobe Commerce istnieją także pakiety dla starszych gałęzi, jednak ich pobranie może wymagać odpowiednich danych dostępowych związanych z licencją. Adobe zaznacza, że przed instalacją październikowej poprawki należy posiadać właściwą wersję bazową i wszystkie wymagane wcześniejsze poprawki miesięczne, zastosowane we właściwej kolejności. Jest to szczególnie ważne w sklepach, które przez kilka miesięcy nie instalowały aktualizacji bezpieczeństwa, ponieważ pominięcie wcześniejszych plików może doprowadzić do konfliktów lub pozostawienia części podatności bez zabezpieczenia.

Dlaczego sama aktualizacja Magento przez Composer może nie wystarczyć?

Właściciele sklepów Magento często zakładają, że wykonanie standardowej aktualizacji pakietów przez Composer zapewnia jednocześnie instalację wszystkich dostępnych poprawek bezpieczeństwa. W przypadku APSB26-153 takie założenie może być błędne, ponieważ Adobe udostępniło październikowe poprawki jako oddzielne pliki Isolated Security Patch, a nie jako nowe pakiety Composer dla wszystkich obsługiwanych gałęzi. Oznacza to, że sklep może korzystać z aktualnej podstawowej wersji Magento, ale nadal nie posiadać poprawki usuwającej BlockStrap. Sansec zwraca uwagę, że nawet świeża instalacja standardowych pakietów może pozostawać podatna, jeżeli administrator nie zastosował dodatkowego październikowego zabezpieczenia. Dlatego kontrola powinna obejmować faktyczny stan plików aplikacji i historię zainstalowanych poprawek, a nie wyłącznie numer wersji wyświetlany w panelu administracyjnym.

Dodatkowym utrudnieniem jest to, że niektóre narzędzia automatyzujące wdrażanie poprawek mogą pomijać określone zmiany bez jednoznacznego przerwania całego procesu instalacji. Jeśli system wdrożeniowy nie sprawdza skuteczności zastosowania każdego pliku, administrator może błędnie uznać aktualizację za zakończoną powodzeniem. Warto również pamiętać o poprawionej paczce dla Adobe Commerce 2.4.8-p5, ponieważ początkowe wydanie październikowego zestawu nie zawierało jednej ze zmian związanych z odrębną podatnością CVE-2026-91013. Adobe udostępniło odpowiednie uzupełnienie, a administratorzy tej gałęzi powinni zweryfikować, czy korzystają z pełnego zestawu poprawek. Sam BlockStrap został usunięty również przez pierwszą wersję poprawki dla 2.4.8-p5, ale zabezpieczenie wszystkich podatności opisanych w biuletynie wymaga sprawdzenia kompletności instalacji.

Jak sprawdzić, czy sklep Magento został zabezpieczony przed BlockStrap?

Najbardziej wiarygodną metodą jest sprawdzenie rzeczywistej obecności poprawek w plikach aplikacji i porównanie ich z wymaganiami odpowiedniego wydania bezpieczeństwa. Adobe udostępnia narzędzie Commerce Version Tool, które pozwala zweryfikować stan miesięcznych aktualizacji i sprawdzić, czy określone podatności zostały usunięte. Narzędzie raportuje zastosowane i brakujące poprawki oraz stan zabezpieczenia poszczególnych CVE, wykorzystując między innymi oznaczenia PROTECTED, VULNERABLE i UNKNOWN. W środowiskach, w których Commerce Version Tool jest dostępne, administrator może uruchomić polecenie php vendor/bin/patch-status z głównego katalogu instalacji Magento. Wynik powinien zostać przeanalizowany przez osobę odpowiedzialną za utrzymanie sklepu, szczególnie jeżeli pojawiają się informacje o brakujących lub nierozpoznanych poprawkach.

Badacze Sansec opisali również techniczną metodę weryfikacji konkretnej zmiany w kodzie mechanizmu szablonów. Październikowa poprawka wprowadza funkcję resolveDeferredDirectives w pliku vendor/magento/framework/Filter/Template.php, dlatego jej obecność może stanowić dodatkowy sygnał, że odpowiednia modyfikacja została zastosowana. Samo znalezienie nazwy funkcji nie zastępuje jednak pełnej kontroli wszystkich plików zmienianych przez aktualizację ani sprawdzenia pozostałych zabezpieczeń. Administratorzy powinni również potwierdzić obecność wcześniejszego hotfixu VULN-39341, ponieważ poprawki BlockStrap i StyleSmuggler są od siebie niezależne. W przypadku instalacji niestandardowych, korzystających z własnych modyfikacji Magento lub dodatkowych mechanizmów wdrożeniowych, warto przeprowadzić analizę zgodności poprawek z rzeczywistym kodem aplikacji.

Czy CVE-2026-103849 jest już aktywnie wykorzystywana przez cyberprzestępców?

W oficjalnym biuletynie APSB26-153 Adobe poinformowało, że w chwili publikacji nie posiadało informacji o wykorzystywaniu podatności objętych aktualizacją w rzeczywistych atakach. Sansec w analizie opublikowanej 15 października 2026 roku również wskazał, że nie zaobserwował jeszcze skutecznych ataków BlockStrap na działające sklepy internetowe. Jednocześnie badacze potwierdzili możliwość wykonania kodu i odtworzyli cztery odmienne scenariusze techniczne prowadzące do wykorzystania błędu. Oznacza to, że podatność została praktycznie zweryfikowana, ale nie należy utożsamiać takiego testu z udokumentowanym włamaniem do rzeczywistego sklepu. Na 30 października 2026 roku w zweryfikowanych komunikatach nie znalazło się potwierdzenie masowej kampanii wykorzystującej właśnie CVE-2026-103849.

Adobe sklasyfikowało aktualizację jako Priority 2, co może budzić wątpliwości w zestawieniu z maksymalną oceną CVSS. Te dwa wskaźniki opisują jednak różne zagadnienia, ponieważ CVSS koncentruje się na technicznej powadze podatności, a priorytet producenta uwzględnia także informacje o rzeczywistym zagrożeniu i dostępnych dowodach wykorzystania. Badacze Sansec zalecają szybsze zastosowanie poprawki niż wynikałoby to z interpretacji standardowego terminu dla Priority 2, zwracając uwagę na możliwość odtworzenia działających scenariuszy ataku. Wcześniejsze przypadki naruszeń bezpieczeństwa Magento pokazują, że czas pomiędzy upublicznieniem szczegółów podatności a pojawieniem się prób jej wykorzystania może być bardzo krótki. Dlatego właściciel sklepu nie powinien czekać na potwierdzone informacje o pierwszych poszkodowanych, jeżeli producent udostępnił już skuteczne zabezpieczenie.

Jak zabezpieczyć sklep Magento i sprawdzić, czy nie doszło do włamania?

Najważniejszym działaniem jest niezwłoczne zastosowanie odpowiedniego październikowego pakietu bezpieczeństwa Adobe oraz potwierdzenie, że w instalacji nadal znajduje się niezależna poprawka dla CVE-2026-75650. Przed wdrożeniem zmian należy wykonać sprawdzoną kopię zapasową plików i bazy danych oraz upewnić się, że można bezpiecznie przywrócić sklep w razie problemów technicznych. W rozbudowanych instalacjach warto przeprowadzić aktualizację na środowisku testowym, szczególnie jeżeli sklep posiada indywidualne rozszerzenia, integracje płatnicze i modyfikacje procesu zamawiania. Następnie trzeba zweryfikować stan poprawek w środowisku produkcyjnym i przeprowadzić testy najważniejszych funkcji sprzedażowych, w tym koszyka, checkout, obsługi płatności, powiadomień e-mail i integracji magazynowych. Ponieważ BlockStrap dotyczy mechanizmu szablonów, szczególnego znaczenia nabiera również sprawdzenie generowania wiadomości transakcyjnych po aktualizacji.

Administratorzy sklepów, które przez dłuższy czas pozostawały podatne, powinni dodatkowo przeanalizować dzienniki serwera i zmiany w plikach aplikacji. Należy zwrócić uwagę na nietypowe operacje związane z generowaniem szablonów, nieznane skrypty PHP, niespodziewane modyfikacje konfiguracji oraz nowe konta administracyjne, które nie zostały utworzone przez uprawnionych pracowników. Warto sprawdzić także integralność plików Magento, historię zmian modułów i obecność mechanizmów umożliwiających ponowny dostęp do serwera. Jeżeli istnieją przesłanki skutecznego włamania, samo zainstalowanie poprawki nie wystarczy, ponieważ wcześniejszy atak mógł doprowadzić do pozostawienia dodatkowego złośliwego oprogramowania. W takim przypadku konieczna jest analiza incydentu, zabezpieczenie logów i ustalenie, czy doszło do naruszenia danych klientów lub poufnych informacji integracyjnych.

W przypadku sklepów obsługujących płatności internetowe warto również skontrolować integralność strony finalizacji zamówienia oraz wszystkich skryptów JavaScript ładowanych podczas procesu płatności. Skuteczne przejęcie serwera może potencjalnie umożliwić modyfikację tych elementów, chociaż nie stanowi to potwierdzonego sposobu wykorzystania CVE-2026-103849 w rzeczywistych atakach. Jeżeli analiza wskazuje na nieautoryzowane zmiany lub podejrzenie ujawnienia danych dostępowych, należy rozważyć wymianę odpowiednich kluczy API, haseł i innych sekretów po uprzednim zabezpieczeniu materiału potrzebnego do ustalenia przebiegu incydentu. W przypadku naruszenia danych osobowych konieczna jest także ocena obowiązków wynikających z RODO, w tym ewentualnego zgłoszenia naruszenia właściwemu organowi nadzorczemu. Zakres reakcji powinien wynikać z rzeczywiście ustalonych okoliczności, ponieważ sama obecność podatnej wersji Magento nie jest jeszcze dowodem kradzieży danych.

Co oznacza BlockStrap dla właścicieli sklepów Magento i Adobe Commerce?

CVE-2026-103849 należy do najpoważniejszych podatności bezpieczeństwa dotyczących Magento i Adobe Commerce ujawnionych w październiku 2026 roku. Maksymalna ocena CVSS 10,0, brak wymogu uwierzytelnienia oraz potwierdzona możliwość zdalnego wykonywania kodu sprawiają, że problem powinien być traktowany priorytetowo przez administratorów podatnych instalacji. Szczególnie istotne jest to, że podatność dotyczy podstawowego mechanizmu przetwarzania szablonów, a nie pojedynczego dodatkowego modułu, którego wyłączenie automatycznie rozwiązywałoby problem. Adobe przygotowało poprawki, jednak sposób ich dystrybucji wymaga samodzielnego sprawdzenia kompletności instalacji, ponieważ standardowa aktualizacja pakietów Composer nie musi obejmować październikowych plików bezpieczeństwa. Dodatkowo administratorzy muszą pamiętać o osobnej wrześniowej poprawce dla StyleSmuggler, która nadal pozostaje konieczna.

Właściciele sklepów korzystających z Magento Open Source i Adobe Commerce powinni zatem ustalić rzeczywistą wersję instalacji, sprawdzić obecność październikowego poziomu zabezpieczeń i zweryfikować wcześniejsze poprawki wymagane przez Adobe. Szczególnie pilnej uwagi wymagają instalacje Magento Open Source 2.4.6 i starsze, dla których dostępność oficjalnych poprawek jest ograniczona i może być konieczne przejście na nowszą gałąź systemu. Nie ma podstaw, aby twierdzić, że wszystkie sklepy Magento zostały zaatakowane przez BlockStrap, jednak techniczne potwierdzenie możliwości wykonania kodu i publiczne ujawnienie podatności stanowią wystarczający powód do szybkiego działania. W branży e-commerce skutki skutecznego przejęcia serwera mogą obejmować nie tylko przerwanie sprzedaży, ale również naruszenie bezpieczeństwa klientów, danych zamówień i systemów płatniczych. Dlatego najważniejszym zadaniem pozostaje nie tylko zainstalowanie aktualizacji, lecz także potwierdzenie, że wszystkie wymagane zabezpieczenia faktycznie działają w środowisku produkcyjnym sklepu.

Źródła

Adobe Security Bulletin APSB26-153 – oficjalny komunikat z 13 października 2026 roku, CVE-2026-103849, podatne wersje i poprawki bezpieczeństwa

Adobe Experience League – instrukcje dotyczące październikowych poprawek Isolated Security Patch, wymagania instalacyjne i weryfikacja zabezpieczeń

Sansec – BlockStrap: Magento and Adobe Commerce RCE, analiza techniczna podatności CVE-2026-103849 i zalecenia dla administratorów sklepów

netpoint

Materiały o e-commerce, sprzedaży i technologii dla sklepów internetowych.

Czytaj dalej

Powiązane materiały