CVE-2025-53092

Strapi to otwartoźródłowy system zarządzania treścią, który w wersjach od 4.0.0 do przed 5.37.0 nie wystarczająco sanitizował parametry zapytań przy filtrowaniu treści przez pola relacyjne. Atakujący bez uwierzytelnienia mógł wykorzystać parametr zapytania `where`, aby przeprowadzić atak boolean-oracle na prywatnych polach w tabeli `admin_users`, co umożliwiało przejęcie konta administratora.

Strapi w wersjach od 5.47.0 do 5.57.0 zawiera podatność na nieprawidłową autoryzację, która pozwala tokenom API administratora zachować pełny dostęp do Menedżera Treści po ograniczeniu pól roli właściciela. Ponieważ funkcja reconcileTokenPermissionsToUserCeiling ignoruje uprawnienia tokenów z pominiętymi lub pustymi polami, posiadacze tokenów mogą nadal czytać pola treści, które administrator usunął z roli.

Strapi w wersjach 4.x do 4.26.2 oraz 5.x przed 5.48.1 zawiera podatność stored cross-site scripting w komponencie podglądu WYSIWYG menedżera treści, który nie usuwa znaczników script z tekstu sformatowanego. Użytkownik z rolą Author może zapisać złośliwe znaczniki script w polach tekstu sformatowanego, które wykonują się w sesji Editora lub Super Admina po rozwinięciu panelu podglądu, umożliwiając przejęcie konta.

Wtyczka users-permissions w Strapi nie ogranicza algorytmów JWT, gdy parametr plugin::users-permissions.jwt.algorithm nie jest jawnie skonfigurowany, co pozwala na akceptację tokenów HS384 i HS512 obok domyślnego HS256. Atakujący posiadający jwtSecret może tworzyć tokeny z niestandardowymi wariantami HMAC, omijając ograniczenia algorytmów i osłabiając kontrolę uwierzytelniania.

W Strapi w wersjach przed 5.33.3 punkty końcowe Content API wtyczki Upload nie egzekwowały skonfigurowanych przez administratora ograniczeń typu MIME. Uwierzytelniony użytkownik z uprawnieniem do uploadu przez Content API mógł przesłać zabronione typy plików, w tym HTML i SVG, co w domyślnej konfiguracji mogło prowadzić do przejęcia sesji administratora.

W Strapi przed wersją 5.33.3 zmiana lub reset hasła użytkownika domyślnie nie unieważniały istniejących sesji refresh-token, ponieważ krok unieważniania zależał od dostarczonego przez wywołującego deviceId. Atakujący posiadający wcześniej refresh token mógł nadal generować nowe tokeny dostępu po resecie hasła przez prawowitego użytkownika, utrzymując nieautoryzowany dostęp do 30 dni. Poprawka w wersji 5.33.3 unieważnia wszystkie refresh tokeny przy każdej zmianie i resecie hasła.

W Strapi (gałęzie 4.x przed 4.26.1 i 5.x przed 5.33.2) uwierzytelniony administrator mógł wstrzyknąć dowolne polecenia SQL poprzez atrybut `column.defaultTo` w API Content-Type Builder, ustawiając go jako krotkę `[wartość, { isRaw: true }]`. W zależności od silnika bazy danych umożliwiało to odczyt plików, atak DoS lub zdalne wykonanie kodu na serwerze bazy danych.

W Strapi w wersjach przed 5.45.0 middleware rate-limit w pluginie users-permissions budował klucz limitu m.in. na podstawie pola `ctx.request.body.email`, nawet na trasach, których schemat żądania nie zawiera pola email (np. /auth/local, /auth/reset-password, /auth/change-password). Nieuwierzytelniony atakujący mógł podać dowolną wartość email w treści żądania, uzyskując nowy klucz limitu przy każdym żądaniu i tym samym omijając ograniczenie liczby prób na IP. Umożliwiało to masowe ataki brute-force na dane logowania, kody resetowania hasła oraz credential stuffing.

Strapi używa tokenów JWT do uwierzytelniania. Po wylogowaniu lub dezaktywacji konta token JWT nie jest unieważniany, co pozwala atakującemu, który ukradł lub przechwycił token, na jego ponowne użycie aż do daty wygaśnięcia (domyślnie 30 dni). Istnienie endpointu /admin/renew-token pozwala na nieograniczone odnawianie tokenów bliskich wygaśnięcia, co zwiększa wpływ ataku. Problem naprawiono w wersji 5.24.1.