Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W ekosystemie Node.js ujawniono podatność SQL Injection dotyczącą MikroORM, popularnego ORM-a używanego w aplikacjach TypeScript i JavaScript. Problem wynika z nieprawidłowego escapowania danych sterujących w kontekście identyfikatorów SQL oraz kluczy ścieżek JSON, co może umożliwić atakującemu przerwanie oczekiwanego kontekstu zapytania i wstrzyknięcie własnych fragmentów SQL.
Luka została oznaczona jako CVE-2026-44680 i dotyczy komponentu @mikro-orm/sql oraz mechanizmów odpowiedzialnych za budowanie zapytań. W praktyce oznacza to, że samo korzystanie z ORM nie gwarantuje ochrony, jeśli dane wejściowe użytkownika wpływają nie tylko na wartości parametrów, ale również na strukturę zapytania.
W skrócie
- Podatność obejmuje wersje MikroORM wcześniejsze niż 7.0.14.
- Poprawka została udostępniona w wydaniu 7.0.14.
- Błąd wpisuje się w kategorię CWE-89, czyli SQL Injection.
- Problem dotyczy niebezpiecznego obchodzenia się z identyfikatorami SQL i kluczami JSON-path.
- Największe ryzyko występuje w aplikacjach, które dynamicznie mapują dane wejściowe na filtry ORM.
Kontekst / historia
Informacje o luce pojawiły się publicznie pod koniec maja 2026 roku wraz z materiałami pokazującymi proof-of-concept. Opis wskazuje, że atak może wykorzystywać manipulację kluczami JSON-path używanymi przez aplikację podczas filtrowania danych w ORM.
To istotny przykład klasy problemów, które nie wynikają z ręcznie pisanego SQL, lecz z błędów w warstwie abstrakcji. Przez lata ORM-y były postrzegane jako skuteczny sposób ograniczania ryzyka wstrzyknięć SQL, jednak tego typu incydenty pokazują, że zagrożenie może pojawić się w mniej oczywistych miejscach, takich jak dynamiczne nazwy pól, identyfikatory kolumn czy ścieżki dostępu do danych JSON.
Analiza techniczna
Technicznie problem polega na niewystarczającym escapowaniu znaków, które mogą zamknąć kontekst identyfikatora SQL albo literału używanego do generowania odwołań do właściwości JSON. Jeżeli aplikacja przekazuje do publicznych interfejsów ORM wartości kontrolowane przez użytkownika, takie jak nazwa pola, identyfikator kolumny lub klucz JSON-path, napastnik może tak przygotować dane wejściowe, aby zakończyć oryginalny fragment zapytania i dołączyć własną składnię SQL.
Szczególnie niebezpieczny scenariusz dotyczy zapytań opartych na mechanizmach pokroju JSON_EXTRACT i podobnych funkcjach wykorzystywanych do filtrowania danych zapisanych w kolumnach JSON. Jeśli klucz ścieżki jest składany dynamicznie na podstawie danych z żądania HTTP, złośliwy input może doprowadzić do wyjścia poza oczekiwany kontekst i uruchomienia dodatkowych operacji SQL.
W praktyce może to oznaczać możliwość odczytu informacji o schemacie bazy, wersji silnika, użytkowniku bazy danych, a w niektórych przypadkach także modyfikację logiki zapytania. Problem nie sprowadza się więc wyłącznie do braku parametryzacji wartości, ale do sytuacji, w której użytkownik ma wpływ na elementy konstrukcyjne samego zapytania.
Konsekwencje / ryzyko
Skutki podatności zależą od sposobu użycia MikroORM w aplikacji oraz od tego, czy interfejs pozwala użytkownikowi wpływać na strukturę filtrów. W najbardziej ryzykownych scenariuszach możliwe jest odczytanie danych z bazy, obejście ograniczeń logicznych, enumeracja schematu, a także naruszenie izolacji danych między tenantami.
- Odczyt danych spoza przewidzianego zakresu.
- Obejście filtrów bezpieczeństwa i kontroli dostępu.
- Enumeracja struktury bazy danych.
- Potencjalna modyfikacja danych lub destabilizacja aplikacji.
- Zwiększone ryzyko wycieku danych w systemach wielodostępowych.
Najbardziej narażone są aplikacje oferujące elastyczne API wyszukiwania, rozbudowane raportowanie oraz dynamiczne mapowanie parametrów żądania na obiekty filtrów ORM. Nawet jeśli atak wymaga dostępu do funkcjonalności po stronie aplikacji, nie zmniejsza to znacząco wagi problemu, ponieważ wiele nowoczesnych API jest dostępnych dla szerokiego grona użytkowników, partnerów lub systemów wewnętrznych.
Rekomendacje
Najważniejszym działaniem naprawczym jest aktualizacja MikroORM do wersji 7.0.14 lub nowszej wszędzie tam, gdzie wykorzystywany jest podatny komponent. Organizacje powinny również przeanalizować zależności pośrednie, aby upewnić się, że podatna wersja nie jest wprowadzana transitively przez inne pakiety.
- Zaktualizować MikroORM do wersji 7.0.14 lub nowszej.
- Zablokować bezpośrednie przekazywanie nazw pól, identyfikatorów i kluczy JSON z danych wejściowych użytkownika.
- Stosować ścisłe listy dozwolonych pól zamiast dynamicznego mapowania.
- Oddzielić wartości filtrowania od struktury zapytania.
- Przeprowadzić przegląd endpointów wyszukiwania, raportowania i filtrowania zaawansowanego.
- Dodać testy bezpieczeństwa obejmujące manipulację JSON-path oraz nazwami pól.
- Monitorować logi pod kątem anomalii i błędów składni SQL.
- Ograniczyć uprawnienia kont bazodanowych zgodnie z zasadą najmniejszych uprawnień.
Dobrym uzupełnieniem działań jest skanowanie SBOM i audyt zależności, aby szybko wykrywać podobne luki w komponentach aplikacyjnych. Z perspektywy AppSec to przypomnienie, że ORM nie eliminuje ryzyka SQL Injection, jeśli użytkownik może wpływać na strukturę generowanego zapytania.
Podsumowanie
CVE-2026-44680 pokazuje, że współczesne SQL Injection coraz częściej pojawia się nie w ręcznie pisanym kodzie SQL, ale w warstwach abstrakcji i mechanizmach pomocniczych frameworków. W przypadku MikroORM problem dotyczył obszaru identyfikatorów i ścieżek JSON, czyli elementów często błędnie uznawanych za bezpieczne tylko dlatego, że są obsługiwane przez ORM.
Dla organizacji korzystających z MikroORM priorytetem powinno być szybkie wdrożenie poprawek, analiza dynamicznych mechanizmów filtrowania oraz ograniczenie możliwości wpływania przez użytkownika na strukturę zapytań. To kolejny sygnał, że bezpieczeństwo dostępu do danych wymaga kontroli nie tylko nad parametrami, ale również nad całą logiką budowania zapytań.