CVE-2026-67337

Biblioteka Better Auth w wersji przed 1.6.11 zawiera podatność w pluginie @better-auth/sso. Punkty końcowe POST /sso/register i POST /sso/update-provider akceptują kontrolowane przez atakującego adresy URL (oidcConfig.userInfoEndpoint, tokenEndpoint, jwksEndpoint) przy włączonej opcji skipDiscovery: true, przechowują je bez walidacji pochodzenia i pobierają podczas wywołania zwrotnego OIDC, co umożliwia nieślepe fałszerstwo żądań po stronie serwera (SSRF) oraz potencjalne łączenie kont, gdy trustEmailVerified: true jest skonfigurowane.

Biblioteka Better Auth przed wersją 1.6.11 zawiera podatność w pluginach legacy oidcProvider i mcp, gdzie endpointy tokenów OAuth uwierzytelniają jedynie posiadanie ważnego refresh_token i client_id, bez weryfikacji client_secret. Pozwala to atakującemu z ważnym refresh_token na generowanie nowych tokenów dostępu i odświeżonych tokenów przez /api/auth/oauth2/token lub /api/auth/mcp/token.

Biblioteka better-auth (npm) przed wersją 1.4.2 pozwala na zewnętrzne żądanie skonfigurowania baseURL, gdy nie jest on zdefiniowany (np. BETTER_AUTH_URL nie jest ustawione). Atakujący, który wykona pierwsze żądanie do serwera po uruchomieniu, może zatruć bazową ścieżkę routera, powodując zwracanie 404 dla wszystkich tras i użytkowników (odmowa usługi). Problem nie występuje, gdy baseURL jest jawnie skonfigurowane lub na typowych platformach hostingowych.

better-auth passkey przed wersją 1.4.0 zawiera podatność na niebezpieczne bezpośrednie odwołanie do obiektu w punkcie końcowym usuwania passkey. Uwierzytelnieni użytkownicy mogą usuwać dowolne passkey innych użytkowników.

Better Auth używa biblioteki rou3, która normalizuje ścieżki URL przez usuwanie pustych segmentów. W wersjach Better Auth przed 1.4.5 atakujący może ominąć konfigurację disabledPaths oraz ograniczenia szybkości oparte na ścieżce, wysyłając żądania z dodatkowymi ukośnikami w ścieżce URL. Problem nie występuje, gdy proxy lub platforma normalizuje adresy URL przez zwijanie wielu ukośników.

better-auth przed wersją 1.6.11 zawiera niebezpieczne domyślne ustawienia kryptograficzne w pluginach oidcProvider i mcp, które reklamują algorytm none i domyślnie akceptują zwykły PKCE. Atakujący mogą wykorzystać negocjację algorytmów do zaakceptowania niepodpisanych tokenów lub przechwycenia kodów autoryzacyjnych, gdy używany jest zwykły PKCE zamiast wymaganej metody S256.

Better-auth przed wersją 1.6.2 nie waliduje parametru stanu OAuth względem przechowywanego nonce, gdy używane jest przechowywanie stanu w ciasteczkach bez PKCE. Atakujący mogą sfałszować parametr stanu i dostarczyć kontrolowany przez atakującego kod autoryzacyjny, aby utworzyć uwierzytelnione sesje powiązane z zewnętrzną tożsamością atakującego lub trwale połączyć konta atakującego z profilami ofiary.

better-auth przed wersją 1.6.11 nie usuwa buforowanych sesji podczas usuwania użytkowników przez endpointy admin, anonymous lub SCIM, gdy skonfigurowano secondaryStorage i storeSessionInDatabase jest ustawione na false. Atakujący mogą ponownie użyć tokenów sesji usuniętych użytkowników, aby utrzymać uwierzytelnienie przez okres do siedmiu dni po usunięciu konta.

better-auth przed wersją 1.6.13 (oraz wersje pre-release 1.7.0-beta.0 do 1.7.0-beta.3) nie waliduje schematu redirect_uris zarejestrowanych przez przestarzały plugin oidc-provider oraz plugin mcp. Atakujący może zarejestrować klienta OAuth z redirect_uri o schemacie javascript:, który serwer autoryzacyjny zwraca bez zmian w odpowiedzi na zgodę. Jeśli strona zgody przekierowuje przeglądarkę do zwróconego redirectURI (np. przypisując go do window.location.href), JavaScript atakującego wykonuje się w kontekście serwera autoryzacyjnego, ujawniając sesję ofiary i umożliwiając przejęcie konta.

better-auth SCIM w wersjach od 1.5.0 do 1.7.0-beta.3 domyślnie nie wiąże dostawców SCIM spoza organizacji z ich twórcą, umożliwiając uwierzytelnionym użytkownikom zarządzanie dostawcami innych użytkowników. Atakujący mogą regenerować tokeny SCIM, unieważniać prawidłowe tokeny i uwierzytelniać się do interfejsów API SCIM przy użyciu kontrolowanego przez siebie tokena.