ERPNext – poważna luka SQL Injection umożliwia kradzież sesji i przejęcie kont administratorów (GHSA-cc74-rc2g-p7hw, CVSS 7,7)

W systemie ERPNext wykryto poważną podatność SQL Injection, która umożliwia zalogowanemu użytkownikowi z minimalnymi uprawnieniami uzyskanie dostępu do poufnych informacji przechowywanych w bazie danych. Szczególnie niebezpieczna jest możliwość odczytania aktywnych danych sesyjnych, które mogą zostać wykorzystane do przejęcia kont innych użytkowników, w tym administratorów systemu. Luka otrzymała identyfikator GHSA-cc74-rc2g-p7hw oraz ocenę CVSS 7,7/10.

Ostrzeżenie zostało opublikowane 6 listopada 2026 roku przez zespół odpowiedzialny za rozwój ERPNext. Podatność dotyczy modułów Selling i Buying, wykorzystywanych do zarządzania sprzedażą, zakupami i powiązanymi procesami biznesowymi. Zagrożone są instalacje ERPNext w wersjach wcześniejszych niż 15.121.6 oraz 16.37.0. Poprawki były dostępne już od 30 września 2026 roku.

Do wykorzystania podatności nie jest wymagane konto administratora. Wystarczy uwierzytelniony użytkownik, nawet posiadający konto portalowe bez przypisanych ról biznesowych. Producent potwierdził możliwość uzyskania nieautoryzowanego dostępu do danych sesyjnych, a w konsekwencji przejęcia kont użytkowników o znacznie wyższych uprawnieniach.

Problem jest szczególnie istotny dla przedsiębiorstw wykorzystujących ERPNext jako zaplecze sprzedaży internetowej, system ERP, narzędzie do zarządzania zamówieniami lub centralne środowisko obsługujące kilka powiązanych firm.

Na czym polega podatność GHSA-cc74-rc2g-p7hw w ERPNext?

Podatność została sklasyfikowana jako CWE-89, czyli Improper Neutralization of Special Elements used in an SQL Command. Oznacza to nieprawidłowe zabezpieczanie danych wykorzystywanych podczas konstruowania zapytań SQL.

W bezpiecznie działającej aplikacji wartości przesyłane przez użytkownika powinny być traktowane jako dane, a nie jako fragmenty instrukcji wykonywanych przez serwer bazy danych.

Problem w ERPNext wynika z błędu kolejności wykonywania walidacji danych.

Według oficjalnego ostrzeżenia określona wartość przesłana w żądaniu była początkowo sprawdzana przez aplikację. Jednak na późniejszym etapie przetwarzania mogła zostać zastąpiona inną wartością dostarczoną przez użytkownika.

Po tej zmianie aplikacja nie przeprowadzała ponownej walidacji.

W rezultacie zmodyfikowana wartość trafiała do zapytania SQL, mimo że nie została poddana wymaganej kontroli bezpieczeństwa.

Napastnik mógł więc ominąć wcześniejsze sprawdzenie danych i doprowadzić do zmiany sposobu wykonywania zapytania przez bazę danych ERPNext.

Producent potwierdził, że podatny mechanizm występuje w jednym z endpointów wykorzystywanych przez moduły Selling i Buying.

Nie ujawniono publicznie dokładnej nazwy podatnego endpointu ani parametrów pozwalających odtworzyć pełne żądanie atakujące.

Jak działa mechanizm SQL Injection w modułach Selling i Buying?

ERPNext wykorzystuje zapytania do bazy danych podczas wykonywania licznych operacji biznesowych, takich jak odczytywanie informacji o klientach, zamówieniach, dokumentach sprzedaży i zakupach.

W omawianej podatności problem nie wynikał wyłącznie z braku sprawdzania wartości przesyłanych przez użytkownika.

Kluczowe znaczenie miała możliwość zmiany wartości już po przeprowadzeniu kontroli.

1. Wstępna walidacja wartości

Podczas obsługi żądania aplikacja otrzymywała dane, które podlegały określonemu sprawdzeniu.

Na tym etapie mechanizm mógł uznać wartość za poprawną i dopuścić ją do dalszego przetwarzania.

2. Nadpisanie wcześniej sprawdzonego parametru

Na kolejnym etapie aplikacja pozwalała zastąpić wcześniej zweryfikowaną wartość innymi danymi pochodzącymi z żądania użytkownika.

Nowa wartość nie przechodziła ponownie przez wymagany mechanizm walidacji.

To właśnie w tym miejscu dochodziło do utraty ochrony zapewnianej przez wcześniejsze sprawdzenie.

3. Wykorzystanie niezweryfikowanych danych w zapytaniu SQL

Zmodyfikowana wartość była następnie wykorzystywana przez mechanizm komunikujący się z bazą danych.

Jeżeli zawierała odpowiednio przygotowaną składnię, mogła wpływać na strukturę wykonywanego zapytania SQL.

W ten sposób napastnik mógł doprowadzić do odczytania informacji, do których nie miał uprawnień.

4. Odczytywanie poufnych informacji i danych sesyjnych

Producent potwierdził możliwość pobierania wrażliwych danych z bazy ERPNext.

Szczególnie poważnym skutkiem jest możliwość uzyskania aktywnych danych sesyjnych innych użytkowników.

Jeżeli napastnik uzyska prawidłowe dane umożliwiające uwierzytelnienie w ramach istniejącej sesji, może wykorzystać je do przejęcia konta bez znajomości hasła jego właściciela.

Nie jest to jednak równoznaczne z możliwością bezpośredniego wykonania dowolnego kodu na serwerze. Potwierdzonym mechanizmem podatności jest SQL Injection prowadzący do ujawniania informacji, w tym danych pozwalających na dalsze nadużycia uwierzytelniania.

Dlaczego możliwe jest przejęcie konta administratora bez znajomości hasła?

Systemy internetowe wykorzystują sesje do utrzymywania uwierzytelnienia po prawidłowym zalogowaniu użytkownika.

Po podaniu loginu i hasła aplikacja tworzy lub aktywuje odpowiedni kontekst sesji. Dzięki temu użytkownik nie musi ponownie wpisywać hasła przy każdym otwarciu dokumentu lub wykonaniu operacji.

Informacje identyfikujące aktywną sesję muszą być chronione, ponieważ mogą stanowić podstawę uwierzytelniania kolejnych żądań.

W przypadku GHSA-cc74-rc2g-p7hw producent wyraźnie wskazuje, że podatność SQL Injection może umożliwiać odczyt danych sesyjnych pozwalających przejmować konta innych użytkowników.

Dotyczy to również kont administratorów.

Przykładowy scenariusz zagrożenia wygląda następująco:

1. Napastnik uzyskuje legalne lub wcześniej zdobyte konto użytkownika ERPNext o bardzo ograniczonych uprawnieniach.
2. Wysyła odpowiednio przygotowane żądanie do podatnego mechanizmu w modułach Selling lub Buying.
3. Wykorzystuje SQL Injection do uzyskania informacji z bazy danych, do których nie powinien mieć dostępu.
4. Wśród odczytanych informacji mogą znajdować się aktywne dane sesyjne innych użytkowników.
5. Jeżeli uzyskane dane pozwalają na uwierzytelnienie w ramach cudzej sesji, napastnik może uzyskać dostęp do konta jej właściciela.

W przypadku przejęcia sesji administratora zagrożenie może obejmować funkcje zarządzania całym środowiskiem ERPNext dostępne dla tego administratora.

Skuteczność takiego ataku zależy jednak od uzyskania odpowiednich aktywnych danych sesyjnych i ich dalszego wykorzystania.

Nie należy utożsamiać samego błędu SQL Injection z automatycznym nadaniem napastnikowi roli administratora.

Podobne znaczenie ochrony sesji i tokenów uwierzytelniających opisano również przy okazji krytycznej podatności CVE-2026-82907 w Apache OFBiz, która pozwala wykorzystywać przechwycone klucze do przejmowania sesji użytkowników.

Jakie uprawnienia są potrzebne do wykorzystania podatności?

Jednym z najważniejszych elementów ostrzeżenia jest niski próg uprawnień wymaganych do przeprowadzenia ataku.

Producent potwierdził, że wystarczające może być dowolne uwierzytelnione konto ERPNext, również konto portalowe bez przypisanych ról biznesowych.

Nie jest wymagane posiadanie uprawnień do zarządzania sprzedażą, dokumentami zakupowymi ani bazą danych.

Atak można przeprowadzić zdalnie przez sieć, a wykorzystanie podatności nie wymaga interakcji ze strony administratora ani innego użytkownika, którego dane mają zostać odczytane.

Ważne jest jednak rozróżnienie pomiędzy niskimi uprawnieniami a całkowitym brakiem uwierzytelnienia.

GHSA-cc74-rc2g-p7hw nie została opisana jako podatność dostępna anonimowemu odwiedzającemu bez konta.

Napastnik musi dysponować możliwością zalogowania się do podatnego środowiska.

Dlaczego zagrożenie jest istotne dla e-commerce?

ERPNext jest systemem klasy ERP rozwijanym w ramach ekosystemu Frappe. Umożliwia obsługę wielu procesów biznesowych, w tym sprzedaży, zakupów, magazynowania, księgowości, produkcji i relacji z klientami.

Może funkcjonować jako samodzielne zaplecze sprzedażowe albo współpracować z innymi systemami e-commerce.

Przedsiębiorstwo prowadzące sklep internetowy może wykorzystywać ERPNext do zarządzania zamówieniami, synchronizacji stanów magazynowych, obsługi kontrahentów lub przetwarzania dokumentów finansowych.

W takim modelu naruszenie bezpieczeństwa ERP może pośrednio zagrozić procesom realizowanym w sklepie.

W zależności od uprawnień przejętego konta potencjalne konsekwencje mogą obejmować:

• Dostęp do informacji o klientach: odczytywanie danych kontrahentów i dokumentów sprzedaży dostępnych w ramach przejętego konta.
• Dostęp do zamówień: przeglądanie historii sprzedaży i informacji o realizowanych transakcjach.
• Operacje magazynowe: możliwość wykonywania działań na produktach i stanach magazynowych, jeżeli przejęty użytkownik posiada odpowiednie uprawnienia.
• Informacje finansowe: dostęp do dokumentów księgowych, rozliczeń i raportów dostępnych w ERPNext.
• Administrację systemem: możliwość wykonywania operacji administracyjnych w przypadku przejęcia odpowiedniej sesji.
• Integracje zewnętrzne: dostęp do określonych ustawień i funkcji systemów połączonych z ERPNext, zależnie od konfiguracji i zakresu uprawnień.

Są to możliwe następstwa przejęcia odpowiednio uprzywilejowanej sesji, a nie potwierdzenie, że wszystkie takie działania zostały już wykonane przez napastników wykorzystujących tę konkretną podatność.

Nie oznacza to również, że sam WooCommerce, Magento, PrestaShop, Shopify czy Shoper zawiera lukę GHSA-cc74-rc2g-p7hw. Dotyczy ona wyłącznie ERPNext i może wpływać na inne platformy poprzez istniejące integracje biznesowe.

GHSA-cc74-rc2g-p7hw – podatne wersje i ocena CVSS

Ocena CVSS 7,7 wskazuje na wysoki poziom zagrożenia. Atak może zostać przeprowadzony przez sieć przy niskiej złożoności i niewielkich wymaganiach dotyczących uprawnień.

Wektor CVSS potwierdza wysoki potencjalny wpływ na poufność danych. Nie wskazuje natomiast bezpośredniego wpływu samej podatności SQL Injection na integralność i dostępność systemu.

Odrębnym zagrożeniem jest możliwość wykorzystania odczytanych danych sesyjnych do przejęcia kont, w tym kont administratorów.

Szczegółowy opis mechanizmu i potwierdzony zakres podatnych wersji znajdują się w oficjalnym ostrzeżeniu bezpieczeństwa ERPNext GHSA-cc74-rc2g-p7hw.

Jak ERPNext 15.121.6 i 16.37.0 usuwają podatność?

Poprawka producenta zmienia sposób kontrolowania danych wykorzystywanych podczas wykonywania podatnego zapytania.

Wcześniej aplikacja sprawdzała określoną wartość przed etapem, na którym mogła zostać zastąpiona innymi danymi pochodzącymi od użytkownika.

Po nadpisaniu wartość trafiała do zapytania SQL bez ponownej walidacji.

Producent wprowadził dodatkową kontrolę wykonywaną również po nadpisaniu parametru.

Dzięki temu dane przekazywane do zapytania są sprawdzane po uwzględnieniu zmian wprowadzonych na późniejszym etapie przetwarzania.

Zmiana usuwa konkretny mechanizm pozwalający obejść wcześniejszą walidację.

Poprawione wersje 15.121.6 oraz 16.37.0 zostały udostępnione 30 września 2026 roku, natomiast szczegółowe ostrzeżenie dotyczące GHSA-cc74-rc2g-p7hw opublikowano 6 listopada.

Oznacza to, że przedsiębiorstwa korzystające z aktualnych wydań ERPNext mogły mieć zainstalowaną poprawkę jeszcze przed publicznym ujawnieniem szczegółów podatności.

Jak sprawdzić, czy firmowa instalacja ERPNext jest podatna?

Administrator powinien w pierwszej kolejności ustalić numer wersji ERPNext faktycznie uruchomionej w środowisku produkcyjnym.

W instalacjach zarządzanych przy użyciu Frappe Bench można sprawdzić wersje aplikacji poleceniem:

bench version

Polecenie wyświetla informacje o wersjach aplikacji zainstalowanych w środowisku, między innymi ERPNext i Frappe Framework.

Należy porównać numer wersji ERPNext z odpowiednim poprawionym wydaniem.

• Linia 15 wymaga co najmniej wersji 15.121.6.
• Linia 16 wymaga co najmniej wersji 16.37.0.

Jeżeli instalacja korzysta ze starszego wydania, należy zaplanować aktualizację.

W przypadku środowisk zarządzanych przez zewnętrznego dostawcę należy potwierdzić, czy odpowiednie poprawki zostały rzeczywiście wdrożone, a nie jedynie zaplanowane.

Jak zabezpieczyć ERPNext przed SQL Injection i przejęciem sesji?

1. Zaktualizuj ERPNext do poprawionej wersji

Najważniejszym działaniem jest wdrożenie ERPNext 15.121.6 albo 16.37.0 lub nowszego wydania odpowiedniej linii.

Producent jednoznacznie wskazał, że dla tej podatności nie udostępniono obejścia, które mogłoby zastąpić aktualizację.

Przed zmianami w środowisku produkcyjnym należy wykonać pełną kopię bezpieczeństwa bazy danych, plików i konfiguracji.

W instalacjach zarządzanych przez Frappe Bench do przeprowadzania aktualizacji aplikacji i środowiska wykorzystywane jest polecenie:

bench update

Operacja może obejmować aktualizację wielu aplikacji w danym środowisku, instalację zależności, przebudowanie zasobów, migracje bazy danych i ponowne uruchomienie usług.

Dlatego przed jej wykonaniem należy sprawdzić, czy wszystkie niestandardowe rozszerzenia i integracje są zgodne z docelowymi wersjami.

Dokładne informacje o działaniu narzędzia znajdują się w oficjalnej dokumentacji Frappe Bench.

2. Zweryfikuj konta użytkowników o ograniczonych uprawnieniach

Ze względu na warunki wykorzystania podatności należy zwrócić szczególną uwagę na konta portalowe i użytkowników nieposiadających przypisanych ról biznesowych.

Takie konta mogą być tworzone na potrzeby obsługi klientów, kontrahentów i innych osób współpracujących z przedsiębiorstwem.

Administrator powinien sprawdzić, czy wszystkie aktywne konta nadal są potrzebne, a uprawnienia użytkowników odpowiadają ich obowiązkom.

Nie należy zakładać, że brak roli administracyjnej wystarcza do ochrony przed tą konkretną podatnością. Producent potwierdził możliwość jej wykorzystania nawet przez konto bez przypisanych ról.

3. Sprawdź aktywne sesje i nietypowe logowania

Jeżeli podatna instalacja była dostępna dla nie w pełni zaufanych użytkowników, warto przeanalizować logi związane z uwierzytelnianiem i dostępem do aplikacji.

Szczególnej uwagi wymagają:

• nieoczekiwane logowania na konta administratorów;
• sesje pochodzące z nietypowych adresów IP;
• operacje administracyjne wykonywane poza standardowymi godzinami pracy;
• nieoczekiwane zmiany ustawień kont użytkowników;
• nietypowa aktywność kont portalowych;
• powtarzające się błędy aplikacji lub zapytań do bazy danych.

Takie zdarzenia mogą wskazywać na podejrzaną aktywność, ale nie stanowią samodzielnego dowodu wykorzystania GHSA-cc74-rc2g-p7hw.

4. Unieważnij zagrożone sesje w przypadku podejrzenia włamania

Jeżeli istnieją przesłanki, że napastnik uzyskał dostęp do danych sesyjnych, należy rozważyć unieważnienie aktywnych sesji użytkowników i wymuszenie ponownego uwierzytelnienia.

Dotyczy to szczególnie kont administracyjnych.

Sama zmiana hasła nie zawsze stanowi wystarczające zabezpieczenie, jeżeli nie powoduje unieważnienia wcześniej aktywowanych sesji.

Dlatego działania powinny obejmować również bezpośrednie zabezpieczenie mechanizmu zarządzania sesjami.

5. Sprawdź integracje systemu ERP ze sklepami internetowymi

Przedsiębiorstwa wykorzystujące ERPNext do zarządzania sprzedażą online powinny zweryfikować również aplikacje połączone z systemem.

Warto ustalić, czy przejęcie konta ERPNext mogłoby umożliwiać dostęp do konfiguracji integracji, danych zamówień albo innych zasobów wykorzystywanych przez sklep.

Takie kontrole są szczególnie ważne w przedsiębiorstwach obsługujących kilka marek lub odrębnych kanałów sprzedaży.

Zagadnienia związane z ochroną całego środowiska sprzedażowego, kontrolą dostępu i aktualizacjami oprogramowania opisano również w artykule jak dobrze zabezpieczyć sklep internetowy.

Czy podatność GHSA-cc74-rc2g-p7hw jest już wykorzystywana w atakach?

Na dzień 8 listopada 2026 roku oficjalne ostrzeżenie producenta nie zawiera potwierdzenia aktywnej kampanii wykorzystującej GHSA-cc74-rc2g-p7hw przeciwko instalacjom ERPNext.

Potwierdzono jednak techniczny mechanizm SQL Injection, możliwość odczytywania poufnych danych oraz zagrożenie przejęciem sesji innych użytkowników.

Nie należy przedstawiać tej podatności jako zwykłego błędu wyświetlania danych w module sprzedaży.

Możliwość odczytywania informacji o aktywnych sesjach oznacza, że skutki wykorzystania podatności mogą wykraczać poza pojedynczy moduł ERPNext.

Brak publicznie potwierdzonych ataków nie eliminuje ryzyka. Po ujawnieniu podatności jej mechanizm staje się znany większej liczbie osób, a niezałatane środowiska mogą stać się celem kolejnych prób wykorzystania błędu.

ERPNext miał już wcześniej problemy z kontrolą dostępu do danych finansowych

GHSA-cc74-rc2g-p7hw nie jest pierwszym poważnym ostrzeżeniem bezpieczeństwa dotyczącym ERPNext.

31 października 2026 roku ujawniono inną podatność umożliwiającą użytkownikom o ograniczonych uprawnieniach uzyskiwanie dostępu do poufnych informacji finansowych należących do innych przedsiębiorstw.

W tym przypadku problem dotyczył mechanizmów raportowania finansowego i niewystarczającej kontroli uprawnień do odczytu danych.

Wcześniejsza luka została opisana w artykule poważna luka w ERPNext umożliwia dostęp do poufnych danych finansowych innych firm.

Obie podatności dotyczą różnych mechanizmów. Jedna wynika z niewystarczających kontroli uprawnień podczas generowania raportów, druga z niebezpiecznego przetwarzania danych wykorzystywanych w zapytaniach SQL.

Pokazuje to, jak istotne jest rozdzielanie uprawnień oraz zabezpieczanie wszystkich etapów przetwarzania danych pochodzących z żądań użytkowników.

Dlaczego aktualizacja ERPNext jest konieczna?

Podatność GHSA-cc74-rc2g-p7hw pozwala zalogowanemu użytkownikowi z niewielkimi uprawnieniami na wykorzystanie błędu SQL Injection w modułach Selling i Buying.

Potwierdzonym skutkiem jest możliwość odczytywania poufnych informacji z bazy danych, w tym aktywnych danych sesyjnych mogących umożliwiać przejmowanie kont innych użytkowników.

Problem dotyczy ERPNext w wersjach wcześniejszych niż 15.121.6 oraz 16.37.0. Poprawione wydania zostały udostępnione 30 września 2026 roku, a szczegóły podatności ujawniono publicznie 6 listopada.

Producent nie wskazuje obejścia pozwalającego skutecznie usunąć zagrożenie bez instalacji poprawki.

Administratorzy ERPNext powinni niezwłocznie zaktualizować podatne instalacje, sprawdzić aktywność kont o ograniczonych uprawnieniach oraz zweryfikować bezpieczeństwo sesji użytkowników, szczególnie administratorów.