TL;DR

SQL injection nie jest jedną luką z jedną poprawką. To klasa błędów, która w 2026 roku wróciła w systemach przechowujących dane finansowe, pocztę, dokumentację pacjentów i informacje operacyjne. Wspólny mechanizm jest prosty: aplikacja składa zapytanie SQL z danych dostarczonych przez użytkownika, zamiast oddzielić kod zapytania od parametrów.

Pięć opisanych przez nas przypadków pokazuje różne poziomy ryzyka:

  • QuickCMS 6.8, CVE-2025-12465: atak wymaga konta o wysokich uprawnieniach; potwierdzono podatność wersji 6.8, a producent nie podał pełnego zakresu podatnych wydań.
  • Simple.ERP, CVE-2026-1198: wystarczy uwierzytelniony użytkownik z niskimi uprawnieniami; problem naprawiono w wersji 6.30@A04.4_u06.
  • SOGo do 5.12.7, CVE-2026-8851: uwierzytelniony użytkownik może wydobywać dane przez parametr uid w funkcji zarządzania ACL.
  • Nordex N149/4.0-4.5, CVE-2018-25333: atak nie wymaga logowania i uderza w webowy panel systemu OT.
  • SourceCodester Hospitals Patient Records Management System 1.0, CVE-2026-10185: zdalny atak na system danych pacjentów; przypadek ważny głównie jako ostrzeżenie przed nieaudytowanym oprogramowaniem.

Nie każdy z tych produktów działa w Twojej organizacji. Każdy jednak podpowiada, czego szukać podczas audytu: formularzy wyszukiwania, endpointów administracyjnych, parametrów identyfikatorów i starych paneli dostępnych z internetu.

Pięć systemów, jeden błąd

QuickCMS: uprzywilejowane konto nadal może być zagrożeniem

CVE-2025-12465 dotyczy funkcji aFilesDelete w QuickCMS. Podatność ma formę blind SQL injection: aplikacja nie zwraca atakującemu wyniku zapytania wprost, ale różnice w odpowiedzi pozwalają stopniowo odtwarzać dane. Do ataku potrzebne jest konto o wysokich uprawnieniach.

To nie jest powód, by zignorować lukę. Konto administratora może zostać przejęte przez phishing, powtórzone hasło albo wcześniejszy incydent. Wtedy SQL injection rozszerza skutki włamania z dostępu do panelu na bazę danych. NVD potwierdza podatność wersji 6.8 i zaznacza, że pozostałe wersje nie zostały przetestowane. Szczegóły: CVE-2025-12465 w QuickCMS.

Simple.ERP: luka w polskim systemie finansowym

CVE-2026-1198 znajduje się w wyszukiwaniu okna „Obroty na kontach”. Uwierzytelniony użytkownik może przygotować zapytanie wykonane przez bazę. W systemie ERP oznacza to ryzyko dla danych finansowych, informacji o kontrahentach i zapisów operacyjnych.

Tu ścieżka naprawy jest jednoznaczna: rekord CVE wskazuje wydanie 6.30@A04.4_u06 jako poprawione. Organizacja powinna nie tylko sprawdzić numer wersji aplikacji, lecz także potwierdzić z partnerem wdrożeniowym, że aktualizacja faktycznie trafiła na wszystkie środowiska. Osobny alert: SQL injection w Simple.ERP.

SOGo: legalna funkcja jako kanał eksfiltracji

W CVE-2026-8851 dane są wstrzykiwane przez parametr uid endpointu addUserInAcls. Atakujący musi mieć konto, ale może zapisywać wyniki złośliwych podzapytań w tabeli sogo_acl, a potem odczytywać je przez legalne API /acls.

Ten mechanizm utrudnia detekcję opartą wyłącznie na kodach HTTP. Żądania mogą wyglądać jak normalne zarządzanie uprawnieniami. Monitoring powinien więc uwzględniać długość i składnię parametru uid, nietypową aktywność kont oraz odczyty ACL następujące po operacjach zapisu. Więcej: SQL injection w SOGo.

Nordex: ten sam błąd, ale w sieci OT

CVE-2018-25333 dotyczy webowego serwera turbiny Nordex N149/4.0-4.5 w wersji 4.0. Parametr login w login.php pozwala nieuwierzytelnionemu atakującemu wykonywać zapytania SQL, wydobywać dane i omijać logowanie.

W środowisku OT priorytetem nie jest wystawienie kolejnej reguły WAF, lecz usunięcie panelu zarządzania z publicznego internetu. Dostęp administracyjny powinien przebiegać przez segmentowaną sieć, kontrolowany VPN i konta indywidualne. Przegląd przypadku: SQL injection w turbinach Nordex.

System medyczny: publiczny exploit obniża próg ataku

CVE-2026-10185 dotyczy SourceCodester Hospitals Patient Records Management System 1.0. W źródłowym alercie opisaliśmy manipulację parametrem ID w żądaniu do /classes/Users.php?f=save i dostępny publicznie kod exploita.

Nie ma podstaw, by zakładać szerokie użycie tego produktu w Polsce. Wartość tego przypadku jest inna: system przetwarzający dane szczególnej kategorii nie powinien trafiać do produkcji bez oceny dostawcy, testów bezpieczeństwa i planu aktualizacji. Pełny opis: SQLi w systemie medycznym.

Jak znaleźć ryzyko przed kolejnym CVE

Lista CVE odpowiada na pytanie „co już wiadomo”. Audyt musi też odpowiedzieć na pytanie „gdzie ten sam błąd może istnieć jeszcze bez identyfikatora”. Zacznij od miejsc, w których aplikacja przyjmuje dane wpływające na filtrowanie lub wybór rekordów:

  1. wyszukiwarki i filtry w ERP, CRM i panelach księgowych;
  2. parametry id, uid, sort, order, filter i search w API;
  3. formularze logowania oraz odzyskiwania konta;
  4. masowe operacje administracyjne: usuwanie plików, eksport, zarządzanie ACL;
  5. starsze panele urządzeń OT i aplikacje wdrożone bez aktywnej umowy utrzymaniowej.

Po stronie kodu podstawą są zapytania parametryzowane albo bezpieczny ORM. Walidacja wejścia i WAF mogą ograniczać ryzyko, ale nie zastępują oddzielenia danych od składni SQL.

Plan działań na 24–48 godzin

  1. Zrób inwentaryzację wersji. Porównaj wszystkie instalacje z informacjami producentów i rekordami CVE. Uwzględnij środowiska testowe — często mają kopię danych produkcyjnych i słabszą ochronę.
  2. Zainstaluj dostępne poprawki. Dla Simple.ERP punktem odniesienia jest co najmniej 6.30@A04.4_u06. Dla pozostałych produktów sprawdź bieżący komunikat dostawcy, bo status łatki może zmienić się po publikacji tego przeglądu.
  3. Ogranicz ekspozycję. Panele administracyjne, systemy pocztowe i OT nie powinny być publiczne bez wyraźnej potrzeby. Ograniczenia sieciowe zmniejszają ryzyko, ale nie usuwają podatności.
  4. Przejrzyj logi. Szukaj nietypowych znaków i słów SQL w parametrach, serii podobnych żądań oraz nietypowo długich odpowiedzi charakterystycznych dla blind SQL injection.
  5. Zweryfikuj konta. W kilku przypadkach atak wymaga uwierzytelnienia. Usuń konta nieużywane, ogranicz role i wymuś MFA tam, gdzie produkt je obsługuje.
  6. Przygotuj reakcję na wyciek. Jeśli analiza potwierdzi nieautoryzowany dostęp do danych, uruchom procedurę incident response i ocenę obowiązków zgłoszeniowych. Samo załatanie luki nie zamyka incydentu.

Źródła

  1. nvd.nist.gov › CVE 2025 12465
  2. nvd.nist.gov › CVE 2026 1198
  3. nvd.nist.gov › CVE 2026 8851
  4. nvd.nist.gov › CVE 2018 25333
  5. nvd.nist.gov › CVE 2026 10185

Zobacz też

Zobacz też