CVE-2026-75650 w Adobe Commerce i Magento: załataj sklep, a potem go zbadaj

Adobe wydało awaryjną poprawkę dla CVE-2026-75650 — krytycznej luki w Adobe Commerce i Magento Open Source, która może umożliwić nieuwierzytelnione zdalne wykonanie kodu. Adobe ocenia lukę na CVSS 10,0 i informuje, że jest ona wykorzystywana w rzeczywistych atakach. Australijskie Centrum Cyberbezpieczeństwa oraz singapurska Agencja Cyberbezpieczeństwa również wezwały organizacje korzystające z podatnych instalacji do natychmiastowego wdrożenia poprawek.

Dla sprzedawcy kluczowe jest rozróżnienie między zamknięciem luki a udowodnieniem, że sklep nie został wcześniej naruszony. Pierwsze zadanie należy do utrzymania oprogramowania. Drugie jest elementem reagowania na incydent. Sklepu, który był dostępny w okresie wykorzystywania luki, nie można uznać za czysty tylko dlatego, że jego obecny status poprawek wygląda prawidłowo.

To problem wyraźnie inny niż zwykła comiesięczna aktualizacja. Z publicznych doniesień wynika, że eksploatacja rozpoczęła się przed awaryjną poprawką Adobe z 7 września, a badacz, który ujawnił problem, twierdzi, że napastnicy zmieniali ładunki podczas atakowania działających sklepów. Najbezpieczniejsza reakcja powinna więc przebiegać w krótkiej, uporządkowanej sekwencji: zidentyfikować każdą podatną instalację, zastosować poprawkę dostawcy, zabezpieczyć dowody, sprawdzić hosta i aplikację, obrócić sekrety, które mogły zostać ujawnione, a dopiero potem przywrócić sklep do normalnego działania.

Czego dotyczy CVE-2026-75650

CVE-2026-75650 to luka wynikająca z nieprawidłowego neutralizowania danych w silniku szablonów. Adobe klasyfikuje jej wpływ jako arbitralne wykonanie kodu, podaje, że uwierzytelnienie nie jest wymagane, i przypisuje jej bazową ocenę CVSS 3.1 na poziomie 10,0. Wynika ona z osiągalnej przez sieć ścieżki ataku, która nie wymaga uprawnień ani interakcji użytkownika, a potencjalnie mocno narusza poufność, integralność i dostępność systemu.

Podatna rodzina produktów obejmuje Adobe Commerce, Adobe Commerce B2B oraz Magento Open Source. Biuletyn Adobe z 7 września wymienia jako podatne wersje Adobe Commerce od 2.4.4 do 2.4.9, w tym wydania oznaczone znacznikiem kompilacji 2026-August. W przypadku Adobe Commerce B2B zakres obejmuje wersje od 1.3.3 do 1.5.3, a w przypadku Magento Open Source — od 2.4.6 do 2.4.9. Dokładną kombinację pakietu i kompilacji należy sprawdzać w poradniku Adobe. Sama nazwa rodziny produktu nie wystarcza.

Australijskie Centrum Cyberbezpieczeństwa dodaje szczegół ważny podczas triage: eksploatacja wymaga wystawienia punktu końcowego /graphql. Nie oznacza to jednak, że sklep dostępny z internetu jest bezpieczny tylko dlatego, że GraphQL uznano za wyłączony w założeniach środowiska deweloperskiego. Punkt może być częściowo filtrowany albo osiągalny przez load balancer, CDN, alternatywną nazwę hosta lub starszą trasę. Zespół powinien sprawdzić rzeczywistą ekspozycję publicznego wdrożenia oraz środowisk administracyjnych i stagingowych osiągalnych spoza zaufanej sieci.

Podatne oprogramowanie służy do prowadzenia sklepów internetowych, obsługi zamówień klientów oraz łączenia płatności, logistyki, analityki i innych systemów biznesowych. Luka nie ogranicza się więc do serwera WWW. Udane przejęcie może otworzyć drogę do poświadczeń, tokenów integracyjnych, danych aplikacji widocznych dla klientów, procesów zamówień lub innych usług dostępnych dla procesu Commerce. Skala skutków zależy od uprawnień konta usługi, konfiguracji hosta oraz sekretów przechowywanych przez aplikację albo osiągalnych z jej poziomu.

Dlaczego termin zmienia sposób reakcji

Adobe opublikowało APSB26-146 7 września 2026 roku, nadając sprawie najwyższy priorytet. W biuletynie firma stwierdza, że wie o wykorzystywaniu luki w rzeczywistych atakach. Sansec, który opublikował swoje badania 5 września, poinformował o atakach rozpoczętych 4 września i w chwili ujawnienia opisywał problem jako nieuwierzytelnioną lukę zero-day umożliwiającą zdalne wykonanie kodu. Strona Sansec została zaktualizowana 13 września i podaje, że awaryjna poprawka ukazała się trzy dni po pierwszym potwierdzonym wykorzystaniu.

Te daty wyznaczają prostą granicę ryzyka. Każdy sklep osiągalny przed wdrożeniem poprawki wymaga oceny ekspozycji, nawet jeśli nie doszło do widocznej awarii. Napastnik, który uzyskał wykonanie kodu, nie musi niszczyć wyglądu witryny ani przerywać obsługi płatności, by wyrządzić szkodę. Może po cichu zbierać poświadczenia, zainstalować web shell albo proces działający w tle, zmienić logikę aplikacji, utworzyć mechanizm utrzymania dostępu lub wykorzystać sklep jako punkt przejścia do kolejnych systemów. Normalne doświadczenie klienta nie jest dowodem czystości hosta.

Braku publicznego potwierdzenia kampanii wymierzonej w konkretną branżę nie należy traktować jako uspokojenia dla pojedynczego sprzedawcy. Australijski komunikat mówi o informacjach dotyczących aktywnej eksploatacji, ale nie wskazuje, by atakowany był jeden określony sektor. Oznacza to, że problem ma szeroki charakter, a każda organizacja korzystająca z podatnej platformy powinna samodzielnie ocenić ekspozycję na podstawie wersji, dostępności punktu końcowego, logów i historii wdrożeń.

Pierwsza decyzja: łatać czy ograniczać dostęp

Jeśli sklep jest podatny, a hotfix można bezpiecznie zastosować, trzeba niezwłocznie postępować zgodnie z instrukcją Adobe dotyczącą poprawki CVE-2026-75650. Sansec identyfikuje ją jako hotfix VULN-39341, dostarczany w formie łatki Composer. Dokładny pakiet, obsługiwane wydanie i metoda wdrożenia powinny wynikać z notatek Adobe oraz umowy wsparcia sprzedawcy. Nie należy zastępować poprawki plikiem skopiowanym z niezweryfikowanego forum ani zakładać, że zwykły wynik security:patch-status dowodzi instalacji tej awaryjnej poprawki.

Przed zmianą produkcji trzeba wykonać chronioną kopię odpowiednich plików aplikacji, konfiguracji, baz danych i logów. Należy zapisać bieżącą wersję, plik blokady pakietów, identyfikator wdrożonego commitu albo artefaktu, wersje PHP i serwera WWW oraz moment wykonania migawki. Kopię trzeba przechować poza potencjalnie naruszonym hostem. Dzięki temu zespół będzie miał materiał do porównania po zmianie i łatwiej odróżni skutki uboczne łatania od istniejącej ingerencji.

Jeśli hotfixu nie można wdrożyć od razu, należy ograniczyć ekspozycję na czas przygotowania instalacji. Australijskie zalecenie wskazuje na aktualizację do wersji zawierającej poprawkę, a gdy nie ma poprawki dla używanej wersji — na ograniczenie i monitorowanie dostępu. W praktyce może to oznaczać czasowe ograniczenie publicznego dostępu do sklepu, zablokowanie podatnego punktu na zaufanej krawędzi sieci albo przełączenie witryny w kontrolowany tryb konserwacji. Reguła zapory aplikacyjnej może ograniczyć przypadkowy ruch, ale należy ją traktować jako zabezpieczenie kompensacyjne, nie zamiennik poprawki Adobe.

Zespoły powinny zachować ostrożność wobec niewspieranych gałęzi. Sansec informuje, że testowany przez Adobe zakres hotfixu jest powiązany ze wspieranymi wydaniami 2026-August, a starsze gałęzie są podatne, lecz nie zostały zweryfikowane przez Adobe w taki sam sposób. Jeśli organizacja korzysta z wersji bez wsparcia, właściwym krokiem jest zaangażowanie opiekuna Commerce albo wykwalifikowanego dostawcy reagowania na incydenty, przetestowanie wspieranej aktualizacji lub sprawdzonego backportu oraz unikanie nieprzetestowanej zmiany produkcyjnej w działającym sklepie.

Samo łatanie nie kończy zadania

Najczęstszy błąd operacyjny przy aktywnie wykorzystywanej luce polega na zatrzymaniu się na sprawdzeniu wersji. Poprawka uniemożliwia ponowne użycie znanej ścieżki, ale nie usuwa kodu zapisanego przed jej wdrożeniem, nie unieważnia skopiowanych poświadczeń i nie pokazuje, do których systemów zewnętrznych uzyskał dostęp naruszony proces.

Dochodzenie należy rozpocząć od dokładnej osi czasu. Trzeba ustalić, kiedy każda internetowa instancja Commerce była podatna, kiedy punkt /graphql był osiągalny, kiedy pojawiły się pierwsze podejrzane żądania, kiedy zainstalowano hotfix oraz czy później zrestartowano lub ponownie wdrożono aplikację. W analizie powinny znaleźć się logi CDN, WAF, reverse proxy, load balancera, serwera WWW, PHP-FPM, aplikacji, systemu operacyjnego, zadań zaplanowanych i audytu chmurowego. Wszystkie dane muszą używać tej samej strefy czasowej, a oryginalne pliki należy zachować przed filtrowaniem lub rotacją.

Dowodów trzeba szukać na kilku warstwach, nie opierając się na jednym sygnale. Na brzegu sieci należy przejrzeć nietypowe żądania do GraphQL, serie żądań niepasujące do normalnego ruchu sklepu, nieoczekiwane user-agenty, powtarzające się błędy oraz ruch z dostawców hostingu lub sieci niezwiązanych z prawidłowymi klientami. W aplikacji trzeba sprawdzić zmiany szablonów, aktywność powiadomień o nieudanych płatnościach, nieoczekiwane modyfikacje CMS lub konfiguracji, nowe konta administratorów, zmiany uprawnień integracji i nietypowe zapisy w katalogach raportów, mediów lub cache. Na hoście należy szukać nowych procesów, nowych zadań zaplanowanych, zmodyfikowanych plików startowych, nieoczekiwanych plików PHP oraz połączeń wychodzących, których proces Commerce zwykle nie wykonuje.

Raport Sansec opisuje dwuetapowy schemat, w którym napastnik zatruwa kod związany z systemem szablonów Magento, a następnie powoduje jego wyrenderowanie przez Magento w ścieżce powiadomienia o nieudanej płatności. To zachowanie daje obrońcom konkretne pytania, bez konieczności odtwarzania exploita: czy liczba powiadomień o nieudanych płatnościach nagle wzrosła, czy dane związane z szablonami zmieniły się poza normalnym wdrożeniem oraz czy worker Commerce wykonał nietypowy zapis pliku lub połączenie wychodzące w tym samym czasie? Żaden sygnał nie jest samodzielnym dowodem. Odrzucone płatności, rozszerzenia i zaplanowane prace mogą powodować podobne zdarzenia, dlatego ustalenia trzeba zestawić z rejestrami wdrożeń i logami żądań.

Podczas szukania pomocy nie należy wklejać w publicznych trackerach wrażliwych logów, informacji o klientach, danych sesyjnych ani wartości sekretów. Z dostawcą Adobe, zaufanym zespołem reagowania na incydenty lub właściwym organem cyberbezpieczeństwa trzeba dzielić się wyłącznie minimalnym, zanonimizowanym materiałem. Singapurski komunikat odsyła administratorów do biuletynu dostawcy i rekordu NVD, a komunikat australijski wskazuje kanał pomocy i zgłaszania incydentów dla organizacji dotkniętych problemem.

Sekrety, które mogą wymagać rotacji

Jeżeli dochodzenie potwierdzi eksploatację albo sklep nie potrafi wykazać, że do niej nie doszło, poświadczenia należy obracać w kolejności ograniczającej możliwość dalszego działania napastnika. Najpierw trzeba zabezpieczyć tożsamości i systemy administracyjne używane do zarządzania hostem oraz potokiem wdrożeniowym. Następnie należy obrócić klucz szyfrowania Commerce i wszystkie poświadczenia, które mogły być chronione przez ten klucz, z niego wyprowadzone lub przechowywane obok niego.

Lista może obejmować hasła administratorów, tokeny integracji REST, SOAP i GraphQL, sekrety klientów OAuth, poświadczenia bramek płatniczych, hasła baz danych, klucze SSH, klucze wdrożeniowe, poświadczenia chmurowe oraz klucze API rozszerzeń zewnętrznych. Rotację trzeba wykonać u źródła, a nie tylko zmienić wartość w konfiguracji Commerce. Zmiana poświadczenia płatniczego wewnątrz sklepu nie unieważnia starego klucza u operatora płatności; operator musi wydać albo unieważnić poświadczenie. Ta sama zasada dotyczy IAM w chmurze, kontroli źródła, monitoringu, dostawców wysyłki i platform marketingowych.

Rotacji powinien towarzyszyć przegląd dostępu. Należy usunąć nieużywane integracje, ograniczyć uprawnienia, skrócić czas życia tokenów tam, gdzie jest to praktyczne, potwierdzić unieważnienie starych poświadczeń i przejrzeć logi uwierzytelniania pod kątem użycia po ostatnim prawidłowym wdrożeniu. Jeśli ten sam sekret był używany w innym środowisku, należy uznać je za narażone do czasu sprawdzenia. Rotacja klucza, po której zapomniana kopia pozostaje aktywna na hoście stagingowym albo w zmiennej CI, tworzy jedynie pozór odzyskania kontroli.

Sama zmiana klucza szyfrowania Commerce nie jest pełną reakcją. Może chronić przyszłe wartości zapisane nowym kluczem, ale nie odzyska ani nie usunie danych, które napastnik już odczytał. Nie usuwa także web shella, zadania zaplanowanego, zmodyfikowanego rozszerzenia ani skradzionej sesji. Rotacja poświadczeń powinna nastąpić po zabezpieczeniu dowodów i równolegle z naprawą hosta, a nie zamiast tych działań.

Kto musi zareagować

Sprzedawcy korzystający z Adobe Commerce lub Magento Open Source powinni zinwentaryzować każdy sklep, wdrożenie regionalne, witrynę stagingową, kopię odzyskiwania po awarii i instancję utrzymywaną przez partnera. Firma może znać swój główny sklep, ale przeoczyć nieaktywną witrynę innej marki, wewnętrzny portal zamówień albo wdrożenie chmurowe prowadzone przez agencję. Ewidencja powinna zawierać dokładną gałąź oprogramowania, publiczne nazwy hostów, ekspozycję GraphQL, stan poprawek, właściciela i datę ostatniej weryfikacji.

Dostawcy usług zarządzanych i agencje e-commerce powinni powiadomić klientów, wskazać wspólne zależności operacyjne i udowodnić, które środowiska zostały załatane. Stwierdzenie dostawcy, że platforma jest aktualna, jest słabsze niż rekord wdrożenia zawierający nazwę hotfixu, podatną instancję i czas weryfikacji. Klient powinien poprosić o taki dowód oraz o potwierdzenie zachowania logów, jeśli usługa była dostępna przed wdrożeniem poprawki.

Zespoły płatności, realizacji zamówień, obsługi klienta i analityki powinny zostać włączone do działań, gdy pojawią się dowody wykonania kodu lub ujawnienia sekretów. Ich systemy nie muszą działać na Magento, lecz mogą ufać poświadczeniom API sklepu albo przyjmować z niego zdarzenia. Przegląd bezpieczeństwa powinien obejmować tokeny downstream, sekrety podpisywania webhooków, konta usług oraz nietypową aktywność w połączonych systemach.

Zespoły bezpieczeństwa powinny traktować problem jednocześnie jako zarządzanie podatnością i reagowanie na incydent. Zarządzanie podatnością odpowiada na pytanie, czy oprogramowanie jest już zabezpieczone. Reagowanie na incydent ustala, czy organizacja została wcześniej dotknięta skutkami. Rozdzielenie tych ścieżek zapobiega częstej porażce, w której skuteczne wdrożenie poprawki myli się ze skutecznym zbadaniem incydentu.

Czego nie należy wywnioskować z dostępnych dowodów

CVE-2026-75650 jest poważną luką, ale dostępne fakty nie uzasadniają każdej możliwej tezy. Publiczne doniesienia potwierdzają aktywną eksploatację i krytyczną, nieuwierzytelnioną ścieżkę wykonania kodu. Same w sobie nie dowodzą, że każdy sklep Magento został przełamany, że dane płatnicze klientów skradziono każdej ofierze ani że za całą obserwowaną aktywność odpowiada jedna wskazana grupa. Sprzedawcy nie powinni publikować takich wniosków bez dowodów z własnego środowiska.

Podobnie obecność podejrzanego adresu IP w logu nie dowodzi, że żądanie zakończyło się sukcesem, a brak znanego wskaźnika nie dowodzi, że atak się nie udał. Napastnicy mogą zmieniać infrastrukturę i ładunki. Detekcja powinna łączyć dowody z żądań, skutki w aplikacji, zmiany plików i procesów, zapisy uwierzytelniania oraz czas wdrożenia. Jeśli pozostaje niepewność, trzeba zachować host i eskalować sprawę do analizy forensycznej, zamiast od razu usuwać podejrzane pliki.

Ta sama ostrożność dotyczy środków ograniczających ryzyko. Reguła CDN, sygnatura WAF, wyłączony punkt końcowy albo ograniczenie sieciowe mogą obniżyć ryzyko, ale każde z tych zabezpieczeń może być źle skonfigurowane lub ominięte alternatywną trasą. Zabezpieczenie kompensacyjne powinno mieć właściciela, datę wygaśnięcia i test weryfikacyjny. Nie może stać się stałą wymówką dla uruchamiania niewspieranego i niezałatanego sklepu.

Praktyczna sekwencja reakcji

W przypadku sklepu, który nadal jest narażony, sekwencję można przydzielić podczas incydentu: zidentyfikować instancję i właściciela, ograniczyć dostęp, jeśli hotfixu nie da się natychmiast wdrożyć, zachować logi i czystą kopię zapasową, zastosować hotfix Adobe dla CVE-2026-75650, zweryfikować wdrożenie na podstawie działającego artefaktu i ponownie sprawdzić publiczną osiągalność. Nie należy zaczynać od usuwania dowodów ani odtwarzania systemu z niezweryfikowanej kopii.

Sklep załatany po 4 września należy traktować tak, jakby okres przed wdrożeniem był oknem dochodzenia. Trzeba porównać żądania brzegowe z logami aplikacji, sprawdzić zmiany szablonów i CMS, przejrzeć powiadomienia o nieudanych płatnościach, poszukać nieoczekiwanych plików i zadań zaplanowanych, zbadać połączenia wychodzące oraz skontrolować uwierzytelnianie administratorów i integracji. Przy jakimkolwiek wiarygodnym sygnale wykonania kodu host należy odizolować albo przenieść sklep do znanego, dobrego środowiska, kontynuując prace dochodzeniowe.

W przypadku potwierdzonego lub prawdopodobnego przejęcia trzeba zachować naruszony system, obrócić poświadczenia w systemach, które je wydają, w razie potrzeby odbudować środowisko z zaufanych artefaktów, przejrzeć połączone usługi, powiadomić klientów lub organy regulacyjne, jeśli wymagają tego właściwe przepisy, oraz udokumentować dowody wspierające końcową decyzję o ryzyku. Plan odzyskiwania powinien obejmować monitoring po przywróceniu działania, ponieważ samo łatanie i odbudowa nie gwarantują zabezpieczenia każdego zależnego konta.

Lekcja dla bezpieczeństwa e-commerce

Bezpośrednia lekcja brzmi: trzeba zastosować hotfix Adobe. Szersza dotyczy różnicy między poprawnym sygnałem wersji a czystym środowiskiem. Podatny sklep może stać się problemem tożsamości i systemów płatniczych, gdy aplikacja ma dostęp do sekretów, procesów klienta i automatycznych integracji. Granicą bezpieczeństwa nie jest wyłącznie pakiet Commerce; obejmuje ona serwer, potok wdrożeniowy, rozszerzenia, punkty końcowe, poświadczenia i połączone usługi.

CVE-2026-75650 pokazuje również, dlaczego awaryjna poprawka potrzebuje planu zabezpieczenia dowodów. Gdy eksploatacja zaczyna się przed udostępnieniem poprawki dostawcy, organizacja musi równolegle zmniejszać pozostałą powierzchnię ataku i ustalać, co wydarzyło się w okresie ekspozycji. Taki sposób działania prowadzi do spokojniejszego i łatwiejszego do obrony wyniku niż zarówno paniczne wyłączenia, jak i uspokajające, lecz niepoparte dowodami twierdzenie, że załatana wersja oznacza koniec incydentu.

Dla podatnych sprzedawców decyzja jest więc jasna. W pierwszej kolejności należy zastosować wspieraną poprawkę Adobe, potwierdzić jej obecność w działającym wdrożeniu i zbadać każdą instancję wystawioną przed załataniem. Jeśli pojawi się podejrzana aktywność, trzeba przyjąć, że sekrety mogły zostać odczytane, dopóki odpowiednie systemy wydające poświadczenia nie potwierdzą ich rotacji i unieważnienia. Sklep może wrócić do normalnego działania wtedy, gdy oprogramowanie jest naprawione, środowisko zostało zbadane, poświadczenia połączonych usług są pod kontrolą, a dowody wspierają taki wniosek.

Źródła

Materiał opiera się na biuletynie bezpieczeństwa Adobe APSB26-146, notatkach wydania hotfixu VULN-39341 w Adobe Experience League, komunikatach Australijskiego Centrum Cyberbezpieczeństwa i singapurskiej Agencji Cyberbezpieczeństwa, raporcie Sansec dotyczącym StyleSmuggler oraz rekordzie CVE-2026-75650 w bazie NVD. Daty, zakresy wersji, oceny ryzyka i opis aktywnej eksploatacji zachowano zgodnie z tymi źródłami.