Luka o krytycznej ocenie 9.1 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) została zidentyfikowana w Apache APISIX. Problem dotyczy wtyczki openid-connect i w domyślnej konfiguracji może umożliwić ominięcie mechanizmów uwierzytelniania. Atakujący może uzyskać nieautoryzowany dostęp do chronionych zasobów.

Problem dotyczy szerokiego zakresu wersji, od 2.3 do 3.16.0 włącznie. Apache APISIX jest popularnym, otwartym rozwiązaniem typu API Gateway, używanym do zarządzania, zabezpieczania i kierowania ruchem do aplikacji opartych na mikroserwisach. Wiele polskich firm technologicznych i platform e-commerce wykorzystuje te bramki jako pierwszą linię obrony. Podatność w tym komponencie może mieć kaskadowe konsekwencje dla całej infrastruktury.

TL;DR

  • Produkt: Apache APISIX, wtyczka openid-connect.
  • Problem: Niewystarczająca weryfikacja autentyczności danych, umożliwiająca fałszowanie nagłówków tożsamości.
  • Identyfikator: CVE-2026-44087.
  • Wpływ: Nieautoryzowany dostęp do chronionych zasobów i usług.
  • Kogo dotyczy: Użytkownicy Apache APISIX w wersjach od 2.3 do 3.16.0.
  • Pierwszy ruch: Identyfikacja używanych instancji APISIX i weryfikacja ich wersji. Plan aktualizacji do wersji 3.17.0.

Wektor ataku

Apache APISIX działa jako centralny punkt wejścia dla żądań kierowanych do wewnętrznych aplikacji. Jedną z jego funkcji jest obsługa uwierzytelniania, aby odciążyć z tego zadania docelowe usługi. Wtyczka openid-connect integruje APISIX z dostawcami tożsamości używającymi standardu OpenID Connect (OIDC), który jest warstwą tożsamości zbudowaną na protokole OAuth 2.0.

Zidentyfikowana podatność, sklasyfikowana jako CWE-345: Insufficient Verification of Data Authenticity, tkwi w sposobie, w jaki wtyczka openid-connect przetwarza przychodzące żądania w swojej domyślnej konfiguracji. Analiza wskazuje, że atakujący może spreparować specjalne żądanie, które zawiera fałszywe nagłówki HTTP symulujące pomyślne uwierzytelnienie.

Bramka APISIX, nie weryfikując poprawnie autentyczności tych danych, przekazuje żądanie dalej do chronionej usługi. Z perspektywy usługi docelowej, żądanie wygląda na w pełni autoryzowane, ponieważ pochodzi od zaufanego komponentu, jakim jest bramka API. W rezultacie atakujący może ominąć cały proces logowania i uzyskać dostęp do zasobów, które powinny być chronione.

Problem dotyczy wszystkich wersji Apache APISIX, począwszy od 2.3 aż do 3.16.0 włącznie. Oznacza to, że podatne mogą być nawet kilkuletnie wdrożenia, jeśli nie były regularnie aktualizowane.

Wskaźniki kompromitacji

Obecnie nie istnieją publiczne wskaźniki kompromitacji (IoC — Indicators of Compromise) powiązane z konkretną kampanią wykorzystującą tę lukę. Jest to podatność w oprogramowaniu, a nie aktywne złośliwe oprogramowanie.

Zespoły SOC (Security Operations Center) powinny jednak proaktywnie analizować logi z bramek APISIX oraz chronionych przez nie aplikacji. Należy szukać anomalii, takich jak:

  • Żądania do chronionych punktów końcowych, które zawierają nagłówki tożsamości (np. X-User-ID, X-Email), ale nie są skorelowane z wcześniejszym, pełnym przepływem OIDC.
  • Nagłe, niewyjaśnione wzrosty liczby udanych dostępów do wrażliwych zasobów z nietypowych źródeł.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania w celu mitygacji ryzyka. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią pierwszy, niezbędny etap działań.

  1. Identyfikacja i weryfikacja. Należy niezwłocznie zidentyfikować wszystkie instancje Apache APISIX używane w organizacji. Następnie zweryfikować ich wersje. Jeśli którakolwiek z nich znajduje się w zakresie od 2.3 do 3.16.0, należy uznać ją za podatną.

  2. Aktualizacja. Jedynym skutecznym sposobem na usunięcie luki jest aktualizacja oprogramowania. Dostawca opublikował wersję 3.17.0, która zawiera poprawkę. Należy zaplanować i przeprowadzić aktualizację w trybie priorytetowym.

  3. Audyt konfiguracji. Poza aktualizacją, jest to dobry moment na przegląd konfiguracji wtyczki openid-connect. Należy upewnić się, że nie jest ona uruchomiona z niepotrzebnymi, domyślnymi ustawieniami w środowiskach produkcyjnych.

  4. Kontekst polski. Wiele polskich firm z sektora MŚP, a także większych graczy e-commerce i fintech, stosuje architekturę opartą na mikroserwisach, gdzie bramki API są kluczowym elementem bezpieczeństwa. Wykorzystanie tej luki może prowadzić do wycieku danych klientów, co w świetle dyrektywy NIS2 (unijna dyrektywa o bezpieczeństwie sieci) oraz RODO (Rozporządzenie o Ochronie Danych Osobowych) stanowi poważny incydent bezpieczeństwa. Taki incydent może wiązać się z obowiązkiem zgłoszenia do Prezesa Urzędu Ochrony Danych Osobowych (UODO) oraz wysokimi karami finansowymi.

Źródła

Zobacz też