Właściciele sklepów internetowych korzystających z Drupal Commerce powinni natychmiast sprawdzić wersję zainstalowanego modułu Commerce Core. 28 października 2026 roku zespół bezpieczeństwa Drupala ujawnił krytyczną podatność CVE-2026-118539, umożliwiającą obejście mechanizmów kontroli dostępu do określonych funkcji i danych zamówień. Luka otrzymała ocenę 21 na 25 punktów w skali zagrożeń Drupal Security Team, a jej skutki mogą obejmować manipulowanie cenami produktów, obchodzenie etapów płatności oraz tworzenie zamówień oznaczonych jako opłacone pomimo braku rzeczywistej transakcji. Co szczególnie niepokojące, nie jest to wyłącznie teoretyczne zagrożenie — producent potwierdził zgłoszenia rzeczywistych prób oszustw w działających sklepach.
29 października firma Centarro, odpowiedzialna za rozwój Drupal Commerce, opublikowała szczegółowe ostrzeżenie przygotowane we współpracy z Drupal Security Team. Potwierdzono otrzymanie dwóch zgłoszeń od sprzedawców, którzy zaobserwowali podejrzane zamówienia. Wśród wykrytych nieprawidłowości znalazły się próby zamawiania produktów po cenie zaledwie 0,01 dolara oraz manipulowania danymi wykorzystywanymi podczas finalizacji zakupu. Poprawki są już dostępne w wersjach Commerce Core 3.3.13 oraz 8.x-2.41. Administratorzy powinni jednak nie tylko zaktualizować oprogramowanie, lecz również skontrolować wcześniejsze zamówienia, ponieważ instalacja poprawki nie usuwa skutków ewentualnych oszustw dokonanych przed aktualizacją.
Czym jest podatność CVE-2026-118539 w Drupal Commerce?
CVE-2026-118539 to podatność typu Access Bypass, czyli obejście mechanizmów kontroli dostępu. Występuje w module Commerce Core, który odpowiada za najważniejsze funkcje sprzedażowe platformy Drupal Commerce, w tym koszyk, finalizację zamówienia, obsługę produktów oraz udostępnianie danych sprzedażowych przez API.
W prawidłowo zabezpieczonym sklepie klient może wykonywać wyłącznie operacje, do których został uprawniony. Może na przykład dodawać produkty do koszyka, zmieniać ich ilość i wybierać dostępne metody dostawy, ale nie powinien mieć możliwości samodzielnego nadpisywania cen produktów, zmieniania statusu opłacenia zamówienia czy modyfikowania wewnętrznych pól systemu sprzedażowego.
W podatnych wersjach Commerce Core niektóre ścieżki dostępu i pola encji nie zostały odpowiednio zabezpieczone. W rezultacie osoba nieuprawniona może wykonywać operacje, które powinny pozostawać niedostępne z poziomu publicznego procesu zakupowego.
Drupal Security Team sklasyfikował lukę jako wysoce krytyczną, przyznając jej 21 na 25 punktów we własnej skali oceny ryzyka. Wynik ten nie jest oceną CVSS, lecz klasyfikacją stosowaną przez zespół bezpieczeństwa Drupala. W oficjalnym komunikacie potwierdzono również, że podatność jest aktywnie wykorzystywana w rzeczywistych atakach.
Jak cyberprzestępcy mogą manipulować zamówieniami i cenami produktów?
Jednym z najważniejszych skutków podatności jest możliwość ingerowania w dane zamówienia przed jego ostatecznym zatwierdzeniem. W zależności od konfiguracji sklepu napastnik może próbować zmodyfikować informacje, które normalnie powinny pozostawać pod kontrolą systemu sprzedażowego.
Badacze Centarro opisali cztery charakterystyczne scenariusze wykorzystania podatności:
- Zamówienie bez płatności — klient może doprowadzić do złożenia zamówienia bez prawidłowego przejścia przez wymagane etapy płatności.
- Fałszywe oznaczenie zamówienia jako opłaconego — w określonych konfiguracjach możliwe jest zmodyfikowanie danych zamówienia tak, aby system wskazywał opłacenie, mimo braku odpowiadającej mu transakcji.
- Zmiana ceny produktu — napastnik może próbować nadpisać cenę towaru i doprowadzić do jego zakupu po znacznie niższej wartości.
- Manipulowanie rabatami i opłatami — możliwe jest wprowadzanie nieautoryzowanych korekt wartości zamówienia, które nie wynikają z promocji skonfigurowanych przez sprzedawcę.
W dwóch zgłoszonych przypadkach zaobserwowano zamówienia z nieprawidłowymi cenami, w tym ceną 0,01 USD. Producent wskazuje również, że manipulacje mogą prowadzić do zamówień o normalnie wyglądającej wartości, ale nieprawidłowym statusie płatności.
Nie oznacza to, że każdy atak pozwala automatycznie uzyskać dowolny produkt za jeden cent. Dostępne możliwości zależą od wersji Commerce Core, sposobu działania checkout, uprawnień do poszczególnych pól oraz dodatkowych modułów zainstalowanych w sklepie.
Dlaczego zamówienie może wyglądać na opłacone, mimo że klient nie zapłacił?
Drupal Commerce przechowuje informacje o zamówieniu oraz powiązanych z nim płatnościach w odrębnych strukturach danych. System może przedstawiać sprzedawcy status realizacji zamówienia, jego wartość, kwotę opłaconą oraz pozostałe saldo. Prawidłowe funkcjonowanie sklepu wymaga, aby informacje te były ze sobą zgodne.
W jednym ze scenariuszy CVE-2026-118539 napastnik może doprowadzić do sytuacji, w której zamówienie zostaje oznaczone jako opłacone, ale w systemie nie istnieje odpowiadający mu rekord rzeczywistej płatności.
Centarro wskazuje, że ten wariant ma szczególne znaczenie w instalacjach korzystających z modułu JSON:API i pozwalających na aktualizowanie danych Commerce przez API. Atakujący może w określonych warunkach wykorzystać niewłaściwie zabezpieczone operacje do zmodyfikowania informacji o płatności.
Jeżeli właściciel sklepu lub jego system magazynowy polega wyłącznie na statusie zamówienia, może dojść do wydania produktu bez uzyskania pieniędzy. Problem jest szczególnie poważny w przypadku automatycznego realizowania zamówień, na przykład sprzedaży produktów cyfrowych, kodów licencyjnych, voucherów i usług aktywowanych bez udziału pracownika.
**Samo oznaczenie zamówienia jako opłaconego nie powinno stanowić wystarczającego potwierdzenia otrzymania płatności.** W przypadku podejrzenia wykorzystania podatności konieczne jest porównanie danych Drupal Commerce z rzeczywistymi transakcjami zarejestrowanymi przez operatora płatności.
Które sklepy internetowe są zagrożone?
Podatność dotyczy sklepów wykorzystujących moduł Drupal Commerce Core w określonych wersjach. Nie występuje automatycznie na wszystkich stronach zbudowanych przy użyciu Drupala ani we wszystkich platformach e-commerce.
Według oficjalnego komunikatu SA-CONTRIB-2026-254 zagrożone są następujące wydania:
| Gałąź Drupal Commerce | Wersje podatne | Wersja z poprawką |
|---|---|---|
| Commerce Core 2.x | Wydania starsze niż 8.x-2.41 | 8.x-2.41 |
| Commerce Core 3.x | Od 3.0.0 do 3.3.12 | 3.3.13 |
Zagrożone mogą być zarówno tradycyjne sklepy wykorzystujące standardowy interfejs Drupal Commerce, jak i rozwiązania headless, w których frontend sprzedażowy jest oddzielony od backendu i komunikuje się z nim przez API.
Firma Centarro wyjaśnia, że konkretne ścieżki wykorzystania podatności różnią się w zależności od architektury sklepu. W przypadku instalacji wykorzystujących JSON:API część problematycznych operacji mogła być teoretycznie dostępna już od Commerce Core 8.x-2.18, wydanego w maju 2020 roku. W pozostałych konfiguracjach wskazano możliwość wykorzystania określonych mechanizmów od wersji 8.x-2.25, wydanej w czerwcu 2021 roku.
Oznacza to, że część instalacji mogła przez długi czas działać z podatnym kodem. Nie jest to jednak dowód, że wszystkie takie sklepy internetowe zostały zaatakowane.
Czy podatność jest aktywnie wykorzystywana przez cyberprzestępców?
Tak. W odróżnieniu od wielu ostrzeżeń dotyczących potencjalnych scenariuszy ataku, CVE-2026-118539 została powiązana z rzeczywistymi próbami oszustw w działających sklepach.
Centarro potwierdziło otrzymanie dwóch zgłoszeń od przedsiębiorców, którzy zauważyli podejrzane operacje na zamówieniach. Wspólnie z Drupal Security Team przeanalizowano problem i przygotowano poprawki opublikowane 28 października 2026 roku.
W analizie z 29 października producent wskazał, że nie posiada dowodów na szeroko zakrojoną, zautomatyzowaną kampanię wykraczającą poza początkowo zgłoszone przypadki. Nie należy więc utożsamiać potwierdzonych prób wykorzystania podatności z masowym przejęciem wszystkich sklepów Drupal Commerce.
Jednocześnie oficjalny komunikat bezpieczeństwa jednoznacznie informuje o aktywnym wykorzystywaniu luki. Z tego powodu administratorzy nie powinni odkładać aktualizacji do czasu pojawienia się kolejnych zgłoszeń.
Jak sprawdzić, czy w sklepie doszło do oszustw?
Właściciele sklepów korzystających z podatnych wersji Commerce Core powinni przeprowadzić analizę wcześniejszych zamówień, szczególnie tych złożonych przed instalacją poprawki. Producent wskazuje kilka charakterystycznych nieprawidłowości, które mogą sugerować wykorzystanie CVE-2026-118539.
Zamówienia bez potwierdzonej płatności
Pierwszym sygnałem ostrzegawczym są zamówienia mające status wskazujący na zakończenie procesu zakupowego, mimo że w systemie nie ma odpowiadającej im płatności, autoryzacji ani transakcji oczekującej na rozliczenie.
Nie każde takie zamówienie jest oszustwem. Sklep może legalnie obsługiwać darmowe produkty, płatności odroczone lub zamówienia realizowane według indywidualnych zasad. Należy jednak sprawdzić, czy konkretna transakcja odpowiada normalnemu sposobowi sprzedaży.
Zamówienia oznaczone jako opłacone bez transakcji
Drugim problemem jest rozbieżność pomiędzy kwotą oznaczoną jako zapłacona a sumą rzeczywistych płatności zapisanych w Drupal Commerce i u operatora płatności.
Przykładowo zamówienie może mieć status opłaconego, mimo że nie istnieje transakcja bankowa lub płatnicza uzasadniająca taki stan. W konfiguracjach korzystających z JSON:API taki przypadek może wskazywać na nieautoryzowaną modyfikację danych.
Nieprawidłowe ceny produktów
Trzecim sygnałem są zamówienia zawierające towary w cenach znacząco odbiegających od katalogu produktów i obowiązujących promocji. Centarro wskazuje między innymi przypadki ceny 0,01 USD.
Administrator powinien sprawdzić, czy przy danym produkcie aktywowano funkcję ręcznego nadpisania ceny jednostkowej, oznaczoną w systemie jako Override the unit price. Jeśli sklep nie pozwala normalnie na takie modyfikacje, nieoczekiwana zmiana może wymagać dokładniejszego zbadania.
Nieznane rabaty i korekty wartości zamówienia
Kolejnym obszarem kontroli są ręcznie dodane korekty wartości zamówienia, rabaty i opłaty. Jeżeli w systemie pojawiają się modyfikacje, których nie utworzył pracownik ani skonfigurowany mechanizm promocji, mogą one wskazywać na ingerencję w dane sprzedażowe.
Wszystkie wykryte nieprawidłowości należy porównać z historią zmian, logami aplikacji i rzeczywistą konfiguracją sklepu. Samo wykrycie ręcznie nadpisanej ceny lub zamówienia bez płatności nie wystarcza do jednoznacznego potwierdzenia oszustwa.
Centarro udostępniło zapytania SQL do wykrywania podejrzanych zamówień
Aby ułatwić administratorom weryfikację danych, producent Drupal Commerce opublikował cztery zapytania SQL umożliwiające wyszukiwanie charakterystycznych nieprawidłowości w bazie sklepu.
Zapytania pomagają wykryć zamówienia utworzone poza standardowym procesem checkout, rozbieżności pomiędzy kwotami oznaczonymi jako zapłacone i zapisanymi transakcjami, ręcznie nadpisane ceny jednostkowe oraz nietypowe korekty wartości zamówień.
Rozwiązanie jest szczególnie przydatne dla administratorów sklepów obsługujących dużą liczbę transakcji, w których ręczna kontrola wszystkich zamówień byłaby czasochłonna.
Nie należy jednak wykonywać zapytań bez wcześniejszej weryfikacji struktury bazy danych i przygotowania kopii zapasowej. Producent zaznacza również, że wyniki mogą obejmować legalne operacje wykonywane przez pracowników lub dodatkowe moduły sklepu.
Najbardziej wiarygodne ustalenia można uzyskać, porównując identyfikatory zamówień, daty, adresy IP i historię żądań HTTP. Centarro rekomenduje szczególnie sprawdzenie, czy podejrzane zamówienia rzeczywiście przeszły przez prawidłową ścieżkę checkout, a nie zostały utworzone przez inne, nieoczekiwane żądania.
Jak zabezpieczyć Drupal Commerce przed CVE-2026-118539?
Najważniejszym działaniem jest natychmiastowa aktualizacja modułu Commerce Core do poprawionej wersji właściwej dla używanej gałęzi. W przypadku Drupal Commerce 3.x należy zainstalować wydanie 3.3.13 lub nowsze. Administratorzy korzystający ze starszej gałęzi 8.x-2.x powinni zastosować poprawkę 8.x-2.41.
Przed aktualizacją działającego sklepu warto wykonać sprawdzoną kopię zapasową plików i bazy danych. W rozbudowanych instalacjach należy również zweryfikować zgodność modułów dodatkowych, szczególnie odpowiedzialnych za płatności, wysyłkę, licencje i komunikację API.
Centarro informuje, że wraz z poprawką Commerce Core przygotowano również aktualizacje bezpieczeństwa dla modułów Commerce API, Commerce License, Commerce Shipping oraz Commerce Stripe. Sklepy korzystające z tych rozszerzeń powinny sprawdzić dostępność odpowiednich wydań i zastosować zalecane aktualizacje.
W instalacjach headless istotne jest także przeanalizowanie uprawnień modułu JSON:API. Jeśli sklep nie wymaga aktualizowania danych Commerce przez ten interfejs, producent rekomenduje ograniczenie go do operacji odczytu. Jest to dodatkowy środek zabezpieczający, który nie zastępuje aktualizacji podatnych modułów.
Dlaczego samo zainstalowanie poprawki nie wystarczy?
Aktualizacja Commerce Core usuwa znane błędy kontroli dostępu, ale nie koryguje automatycznie zamówień, które mogły zostać wcześniej zmodyfikowane przez nieuprawnione osoby.
Jeśli napastnik doprowadził do zamówienia produktu za nieprawidłową kwotę albo oznaczył zamówienie jako opłacone bez rzeczywistej płatności, taka informacja może nadal znajdować się w bazie sklepu po aktualizacji.
Dlatego każdy sklep internetowy korzystający z podatnej wersji Drupal Commerce powinien połączyć instalację poprawek z kontrolą zamówień. Szczególnie ważne jest sprawdzenie transakcji już zrealizowanych, dla których towar został wysłany lub usługa została aktywowana.
W przypadku sklepów sprzedających produkty cyfrowe warto dodatkowo sprawdzić, czy dostęp do plików, licencji i usług nie został przyznany na podstawie zamówień, które nie posiadały prawidłowego potwierdzenia płatności.
Jeżeli analiza wykaże rzeczywiste straty finansowe, należy zabezpieczyć historię zamówień, logi systemowe i informacje od operatorów płatności. Mogą one być potrzebne do wyjaśnienia incydentu, ustalenia skali szkód i ewentualnego zgłoszenia oszustwa.
Jak zapobiegać podobnym oszustwom w sklepach internetowych?
Przypadek CVE-2026-118539 pokazuje, że bezpieczeństwo sklepu nie ogranicza się do ochrony haseł administratorów czy zabezpieczania danych kart płatniczych. Równie istotna jest kontrola tego, kto i na jakich zasadach może zmieniać dane zamówień, ceny produktów oraz informacje o opłaceniu transakcji.
W prawidłowo zaprojektowanym procesie sprzedaży użytkownik nie powinien mieć możliwości dowolnego modyfikowania wartości wyliczanych przez serwer. Ceny, rabaty i statusy płatności powinny być ustalane na podstawie zaufanych informacji, a każda istotna zmiana wymagać odpowiednich uprawnień.
Dodatkową ochronę zapewnia rozdzielenie procesu złożenia zamówienia od decyzji o wydaniu towaru. Samo zakończenie checkout nie zawsze jest równoznaczne z otrzymaniem zapłaty, dlatego automatyczne systemy realizacji zamówień powinny korzystać z wiarygodnych potwierdzeń płatności.
W przypadku sklepów wykorzystujących interfejsy API warto regularnie przeglądać dostępne operacje, uprawnienia użytkowników oraz możliwości aktualizowania danych sprzedażowych przez systemy zewnętrzne. Niepotrzebne funkcje zapisu powinny zostać ograniczone, szczególnie w integracjach udostępnionych publicznie.
Istotne znaczenie ma również monitorowanie nietypowych zmian cen, nieoczekiwanych rabatów oraz zamówień, których status finansowy nie odpowiada zapisanym transakcjom. Automatyczne wykrywanie takich rozbieżności może pomóc zauważyć oszustwo, zanim zostanie ono zakończone wysyłką produktu.
Drupal Commerce — krytyczna luka została już wykorzystana w rzeczywistych sklepach
CVE-2026-118539 należy do szczególnie niebezpiecznych podatności e-commerce, ponieważ jej skutki dotyczą bezpośrednio pieniędzy sprzedawców i integralności procesu zamawiania. Błąd umożliwia obejście określonych mechanizmów kontroli dostępu do danych Commerce Core, a w zależności od konfiguracji może prowadzić do manipulowania cenami, rabatami i informacjami o płatnościach.
Producent potwierdził dwa zgłoszenia rzeczywistych prób oszustw, w tym zamówienia z cenami obniżonymi do 0,01 USD. Nie ma podstaw do twierdzenia, że wszystkie sklepy Drupal Commerce zostały zaatakowane ani że trwa globalna, zautomatyzowana kampania na dużą skalę. Jednocześnie oficjalny status podatności jako aktywnie wykorzystywanej oznacza, że administratorzy powinni potraktować ją priorytetowo.
Najważniejsze działania obejmują aktualizację Commerce Core do wersji 3.3.13 lub 8.x-2.41, sprawdzenie bezpieczeństwa powiązanych modułów oraz analizę wcześniejszych zamówień. Szczególną uwagę należy poświęcić transakcjom bez rzeczywistych płatności, nieoczekiwanym zmianom cen i rabatom, których nie skonfigurowali pracownicy sklepu.
Dla przedsiębiorców prowadzących sprzedaż internetową przypadek ten stanowi przypomnienie, że prawidłowo wyświetlone zamówienie nie zawsze oznacza prawidłowo przeprowadzoną transakcję. Bezpieczeństwo e-commerce wymaga zarówno aktualnego oprogramowania, jak i niezależnego potwierdzania płatności oraz regularnej kontroli danych sprzedażowych.