Drupal Core i CVE-2026-9082: krytyczna luka SQL Injection w JSON:API zagraża instalacjom na PostgreSQL

Wprowadzenie do problemu / definicja

W ekosystemie Drupal ujawniono wysoko krytyczną podatność SQL Injection oznaczoną jako CVE-2026-9082. Problem dotyczy sposobu budowania zapytań w warstwie abstrakcji bazy danych i może zostać wykorzystany przez anonimowego atakującego przeciwko instalacjom korzystającym z PostgreSQL. Publicznie opisany scenariusz ataku pokazuje wariant oparty o JSON:API oraz technikę error-based SQL injection, w której dane z bazy mogą być ujawniane pośrednio przez komunikaty błędów.

W skrócie

CVE-2026-9082 to podatność SQL Injection w Drupal Core sklasyfikowana przez zespół bezpieczeństwa jako „highly critical”. Dotyczy witryn wykorzystujących PostgreSQL i może być wykorzystywana bez uwierzytelnienia. Publiczny proof-of-concept dla Drupal Core 10.5.5 demonstruje nadużycie parametrów filtrów JSON:API w celu wpływania na konstrukcję zapytania SQL i wywoływania błędów ujawniających informacje z bazy danych.

• Atak nie wymaga logowania.
• Najbardziej narażone są instalacje Drupal działające na PostgreSQL.
• Wektor publicznego PoC wykorzystuje parametry filtrów JSON:API.
• Skutki mogą obejmować wyciek danych, eskalację uprawnień, a w określonych warunkach nawet zdalne wykonanie kodu.
• Aktualizacja bezpieczeństwa została opublikowana 20 maja 2026 r., a 22 maja 2026 r. advisory uzupełniono o informację o wykrywanych próbach wykorzystania.

Kontekst / historia

Podatność została opisana w advisory SA-CORE-2026-004. Według producenta problem występuje w wielu wspieranych i starszych liniach rozwojowych Drupal Core. Dotknięte są wersje od 8.9.0 wzwyż w określonych zakresach, a poprawki opublikowano m.in. dla gałęzi 10.5, 10.6, 11.1, 11.2 i 11.3. Dla starszych wydań, takich jak Drupal 9 i 8.9, udostępniono łatki w modelu best effort.

Na początku czerwca 2026 r. w publicznych repozytoriach exploitów pojawił się gotowy proof-of-concept dla Drupal Core 10.5.5. Tego typu publikacja zwykle skraca czas potrzebny cyberprzestępcom na przejście od analizy luki do masowego skanowania internetu i prób automatycznego wykorzystania podatnych instancji.

Analiza techniczna

Źródłem problemu jest mechanizm abstrakcji bazy danych, którego zadaniem jest bezpieczne składanie zapytań i neutralizowanie danych wejściowych. W przypadku CVE-2026-9082 określone, specjalnie spreparowane dane wejściowe nie są prawidłowo obsługiwane, gdy aplikacja korzysta z PostgreSQL. W efekcie atakujący może doprowadzić do wykonania wstrzykniętego fragmentu SQL.

Publiczny PoC wykorzystuje endpoint JSON:API dla zasobu typu article i operuje na parametrach filtra. Kluczowy element polega na manipulacji tablicowym kluczem przekazywanym w parametrze filter[...][condition][value][...] przy jednoczesnym użyciu operatora IN. W demonstracji złośliwy indeks tablicy zawiera wyrażenie prowadzące do wykonania podzapytania oraz wygenerowania błędu konwersji po stronie PostgreSQL.

To właśnie błąd staje się kanałem wycieku danych. Jeżeli aplikacja zwraca odpowiedź HTTP 500 wraz z detalami błędu, wynik podzapytania może zostać ujawniony w treści komunikatu. Publiczny przykład pokazuje odczyt informacji o wersji serwera PostgreSQL, ale analogiczny schemat może zostać użyty do pozyskiwania nazw tabel, użytkowników bazy, fragmentów konfiguracji lub innych danych dostępnych dla konta aplikacyjnego.

Choć opublikowany kod koncentruje się na wariancie error-based i ujawnianiu informacji, skutki podatności mogą być szersze. W zależności od uprawnień konta bazy danych, konfiguracji środowiska oraz dodatkowych komponentów aplikacyjnych SQL Injection może prowadzić do modyfikacji danych, eskalacji uprawnień, a nawet stanowić element łańcucha ataku kończącego się wykonaniem kodu na serwerze.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem jest utrata poufności danych. Atakujący może pozyskiwać informacje z bazy bez logowania, co w przypadku systemów CMS oznacza ryzyko wycieku treści roboczych, danych użytkowników, ustawień konfiguracji, tokenów oraz innych wrażliwych informacji.

Drugim wymiarem zagrożenia jest naruszenie integralności. SQL Injection nie ogranicza się wyłącznie do odczytu, a potencjalna możliwość modyfikacji danych zależy od realnych warunków wykonania oraz przywilejów konta wykorzystywanego przez aplikację. Przy nadmiernych uprawnieniach skutki mogą objąć zmianę treści serwisu, pośrednie utworzenie dodatkowych kont uprzywilejowanych lub przygotowanie środowiska do kolejnych etapów ataku.

Istotne pozostaje również ryzyko operacyjne. Publiczny PoC oraz informacja o wykrywanych próbach wykorzystania zwiększają prawdopodobieństwo zautomatyzowanego skanowania internetu pod kątem podatnych instancji. Dla organizacji oznacza to potrzebę pilnego patchowania oraz przeglądu logów aplikacyjnych, serwerowych i bazodanowych w celu identyfikacji śladów nadużyć.

Warto dodać, że wydane aktualizacje obejmują także poprawki bezpieczeństwa w zależnościach, takich jak Symfony i Twig. Z perspektywy zarządzania ryzykiem oznacza to, że nawet środowiska niewrażliwe na ten konkretny wektor powinny potraktować aktualizację jako istotną.

Rekomendacje

Priorytetem powinno być niezwłoczne zaktualizowanie Drupal Core do wersji wskazanych przez producenta. Dla wspieranych linii oznacza to przejście odpowiednio do 10.5.10, 10.6.9, 11.1.10, 11.2.12 lub 11.3.10, zależnie od wykorzystywanej gałęzi.

Organizacje korzystające z PostgreSQL powinny potraktować sprawę jako potencjalnie aktywnie wykorzystywaną i przeprowadzić szybką ocenę ekspozycji.

• Zidentyfikować wszystkie instancje Drupal korzystające z PostgreSQL.
• Sprawdzić publiczną dostępność endpointów JSON:API i innych interfejsów przyjmujących złożone parametry filtrów.
• Przeanalizować logi HTTP pod kątem nietypowych parametrów filter[...], operatora IN, sekwencji ||, CAST(, SELECT oraz odpowiedzi 500.
• Zweryfikować logi PostgreSQL pod kątem błędów składni i nieudanych konwersji typów.
• Ocenić uprawnienia konta bazy danych wykorzystywanego przez aplikację.

Dodatkowo warto wdrożyć działania ograniczające powierzchnię ataku.

• Ograniczyć szczegółowość komunikatów błędów zwracanych do klienta.
• Rozważyć tymczasowe filtrowanie podejrzanych wzorców na poziomie WAF lub reverse proxy.
• Upewnić się, że konto aplikacyjne w PostgreSQL działa zgodnie z zasadą najmniejszych uprawnień.
• Przeprowadzić przegląd uprawnień związanych z modyfikacją szablonów i komponentów renderujących po stronie Drupal.
• Wykonać testy regresyjne po aktualizacji, szczególnie dla integracji opartych o JSON:API i wyszukiwanie encji.

Jeżeli instancja działa na niewspieranej wersji Drupal, zastosowanie doraźnej łatki nie powinno być traktowane jako rozwiązanie docelowe. W takim przypadku należy zaplanować migrację do wspieranej linii, ponieważ starsze wydania mogą zawierać również inne wcześniej ujawnione luki bezpieczeństwa.

Podsumowanie

CVE-2026-9082 to poważna podatność SQL Injection w Drupal Core, która szczególnie zagraża wdrożeniom wykorzystującym PostgreSQL. Publiczny exploit pokazuje praktyczny scenariusz nadużycia JSON:API i potwierdza, że atak może zostać przeprowadzony bez uwierzytelnienia. Ze względu na wysoki poziom krytyczności, dostępność PoC oraz sygnały o próbach wykorzystania administratorzy powinni niezwłocznie zaktualizować system, przeanalizować telemetrię bezpieczeństwa i ograniczyć ekspozycję interfejsów aplikacyjnych.

Źródła

1. Drupal core – Highly critical – SQL injection – SA-CORE-2026-004 — https://www.drupal.org/sa-core-2026-004
2. Drupal Core 10.5.5 – Error-Based SQL Injection – PHP webapps Exploit — https://www.exploit-db.com/exploits/52608
3. Drupal project download page — https://www.drupal.org/project/drupal