Adobe Commerce i Magento CVE-2026-75650: aktywne ataki i osobny hotfix

Adobe ostrzega przed aktywnym wykorzystywaniem CVE-2026-75650 w Adobe Commerce i Magento Open Source. Luka w obsłudze szablonów może pozwolić niezalogowanemu napastnikowi na zdalne wykonanie kodu. Otrzymała maksymalną ocenę CVSS 10.0, a producent nadał poprawce priorytet 1.

Najważniejszy szczegół operacyjny łatwo przeoczyć: hotfix dla CVE-2026-75650 jest oddzielny od wrześniowego pakietu Isolated Patch. Adobe poleca najpierw zastosować hotfix, potem właściwą poprawkę wrześniową, a następnie obrócić klucz szyfrowania oraz powiązane poświadczenia. Sam komunikat „wdrożyliśmy September patch” nie potwierdza więc zamknięcia tej luki.

Które instalacje są objęte ostrzeżeniem

Biuletyn APSB26-146 wymienia Adobe Commerce w liniach od 2.4.4 do 2.4.9, Adobe Commerce B2B w liniach od 1.3.3 do 1.5.3 oraz Magento Open Source w liniach od 2.4.6 do 2.4.9 — w każdym przypadku wraz z wydaniami oznaczonymi jako „2026-aug and earlier”. Dokładna tabela producenta powinna być źródłem decyzji dla konkretnej instalacji, ponieważ sposób dostarczenia poprawki zależy od produktu i wersji.

Zakres dotyczy zarówno środowisk Adobe Commerce on-premises i Cloud, jak i odpowiednich wydań Magento Open Source. Właściciel sklepu powinien sprawdzić nie tylko główną instancję produkcyjną, ale też węzły administracyjne, środowiska stagingowe, zapasowe originy, obrazy kontenerów i stare wdrożenia pozostawione po migracji.

Nie zakładaj, że CDN lub WAF rozwiązuje problem. Te warstwy mogą ograniczyć część prób, ale producent wymaga poprawki w aplikacji. Tym bardziej że publiczny biuletyn klasyfikuje wektor jako sieciowy, o niskiej złożoności, bez konta i bez działania użytkownika.

Dlaczego błąd szablonu może skończyć się wykonaniem kodu

System szablonów ma łączyć dane z przygotowanym układem strony. Jeżeli jednak dane sterowane przez użytkownika zostaną potraktowane jak element instrukcji szablonu, granica pomiędzy treścią a logiką wykonania znika. Adobe klasyfikuje CVE-2026-75650 jako niewłaściwą neutralizację specjalnych elementów używanych w silniku szablonów, czyli CWE-1336.

Publiczny biuletyn potwierdza możliwość wykonania dowolnego kodu, ale nie opisuje kompletnego łańcucha ataku. Nie należy dopowiadać, że każdy sklep został przejęty albo że każda próba daje od razu uprawnienia administratora systemu. Rzeczywisty wpływ zależy między innymi od uprawnień procesu aplikacji, dostępu do sekretów, segmentacji i możliwości wyjścia do sieci.

W sklepie internetowym nawet wykonanie kodu w ograniczonym kontekście jest jednak poważne. Proces może mieć dostęp do konfiguracji, bazy, integracji płatniczych, mechanizmów wysyłki, danych klientów i klucza używanego do ochrony innych sekretów.

Hotfix i wrześniowy Isolated Patch to dwa różne działania

Adobe wyjaśnia w dokumentacji, że hotfix APSB26-146 nie jest zawarty we wrześniowym Isolated Patch. Zalecana kolejność to:

1. dobierz hotfix CVE-2026-75650 do używanej wersji;
2. zastosuj go zgodnie z instrukcją Adobe dla Commerce Cloud, on-premises lub Magento Open Source;
3. wdroż oddzielny wrześniowy Isolated Patch;
4. potwierdź stan poprawki na każdym aktywnym węźle;
5. obróć klucz szyfrowania i wszystkie poświadczenia, które mogły być nim chronione albo ujawnione.

Dla Adobe Commerce w chmurze producent pokazuje weryfikację przez Quality Patches Tool. W innych modelach wdrożenia dowodem powinien być stan zastosowanego patcha, suma i wersja odpowiednich plików lub inna metoda przewidziana w instrukcji producenta — nie tylko zamknięty ticket wdrożeniowy.

Po zmianie wykonaj test transakcyjny: logowanie, koszyk, płatność, integracje, webhooki, wysyłkę e-mail i zadania cron. Szybka poprawka bezpieczeństwa nie zwalnia z kontroli ciągłości sprzedaży.

Rotacja nie kończy się na jednym kluczu

Adobe poleca po hotfixie obrócić klucz szyfrowania oraz wszystkie powiązane poświadczenia, w tym dane serwera, API i integracji. Dokumentacja wymienia również poświadczenia bramek płatniczych i tokeny automatyzacji o wysokich uprawnieniach.

W praktyce najpierw utwórz inwentarz zależności, aby nie unieważnić klucza bez planu aktualizacji systemów korzystających z sekretu. Priorytet mają poświadczenia dające dostęp administracyjny, płatniczy, do bazy danych, chmury, CI/CD i zewnętrznych integracji. Rotację wykonuj z rejestrem właściciela, czasu i potwierdzenia działania po zmianie.

Jeżeli instancja była publicznie dostępna przed poprawką, traktuj rotację jako element reakcji na możliwy incydent, a nie dowód, że do incydentu doszło. Aktywne wykorzystanie luki w internecie podnosi priorytet, ale nie przesądza o kompromitacji konkretnego sklepu.

Co sprawdzić po załataniu

Zachowaj logi CDN, WAF, reverse proxy, aplikacji, systemu operacyjnego, bazy i panelu administracyjnego z okresu ekspozycji. Następnie szukaj zmian, które nie wynikają z wdrożeń: nowych lub zmodyfikowanych plików w webroot, zadań cron, kont administracyjnych, integracji, webhooków, kluczy API i konfiguracji płatności.

Porównaj ruch wychodzący procesu sklepu z oczekiwanym profilem. Nietypowe połączenie zewnętrzne, proces potomny uruchomiony przez serwer aplikacyjny albo nieznana modyfikacja pliku to silniejsze sygnały niż pojedynczy błąd HTTP. Nie usuwaj artefaktów przed ich zabezpieczeniem, jeśli istnieją przesłanki naruszenia.

Adobe nie opublikował w przywołanych materiałach uniwersalnego IOC ani liczby poszkodowanych sklepów. Wskazówki dotyczące polowania na webshell, zmian kont i nietypowego ruchu są wnioskami Breachroad wynikającymi z potencjalnego wykonania kodu, a nie oficjalną listą wskaźników Adobe.

Fakty źródłowe i priorytet dla organizacji

Ocena CVSS 10.0, brak wymagania uwierzytelnienia, wpływ w postaci wykonania kodu, zakres produktów i informacja o aktywnej eksploatacji pochodzą z biuletynu Adobe APSB26-146. Oddzielność hotfixa od wrześniowego Isolated Patch, kolejność wdrożenia, sposób weryfikacji i obowiązek rotacji poświadczeń opisuje pilne zalecenie Adobe Commerce.

Dla firmy utrzymującej sklep właściwa kolejność brzmi: potwierdź wersję, zastosuj oba właściwe patche, zweryfikuj każdy węzeł, obróć poświadczenia i przeprowadź triage. Zespołom pomagamy ćwiczyć ten podział odpowiedzialności podczas szkoleń z cyberbezpieczeństwa, a ekspozycję aplikacji i API oceniamy w ramach testów penetracyjnych web i API. Techniczne tło najczęstszych klas błędów znajdziesz też w przewodniku OWASP Top 10 dla aplikacji webowych.