CVE-2026-110864

better-auth w wersjach od 1.3.8-beta.3 do 1.7.0-rc.3 zawiera podatność polegającą na błędnym przedstawieniu interfejsu w pluginie deviceAuthorization, ponieważ GET /device pomija identyfikator klienta i zakres. Atakujący może rozpocząć żądanie urządzenia przez /device/code, nakłonić zalogowanych użytkowników do zatwierdzenia kodu, a następnie wykorzystać go w /device/token do uzyskania aktywnego tokena sesji.

Better Auth od wersji 1.4.0-beta.18 przed 1.7.7 zawiera lukę obejścia uwierzytelniania, która pozwala nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez ponowne użycie wartości stanu OAuth jako tokenów Magic Link. Atakujący może rozpocząć logowanie OAuth z adresem e-mail ofiary i przesłać zwrócony stan do weryfikacji Magic Link, uzyskując sesje lub tworząc fałszywie zweryfikowane konta e-mail.

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.4.9 zawiera podatność na obejście uwierzytelniania dwuskładnikowego (2FA), gdy włączona jest opcja session.cookieCache. Atakujący posiadający prawidłowe podstawowe dane uwierzytelniające mogą uzyskać dostęp do uwierzytelnionych tras bez przechodzenia drugiego składnika weryfikacji, wykorzystując przedwczesne buforowanie sesji.

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.