CVE-2026-109346

Better Auth to biblioteka uwierzytelniania i autoryzacji dla TypeScript. Od wersji 1.4.0-beta.18 do 1.7.7 wdrożenia, które włączają Magic Link z storeToken ustawionym na plain lub z storeToken ustawionym na hashed i globalnym ustawieniem verification.storeIdentifier również ustawionym na hashed, włączają wbudowanego dostawcę społecznościowego lub Generic OAuth oraz używają account.storeStateStrategy ustawionego na database, mogą przyjąć wartość stanu logowania OAuth jako token Magic Link. Te ustawienia mogą powodować, że rekordy weryfikacji Magic Link i stan OAuth rozwiązują się do tego samego przechowywanego identyfikatora, pozwalając nieuwierzytelnionemu atakującemu rozpocząć logowanie OAuth dla znanego adresu e-mail i wykorzystać zwrócony stan poprzez Magic Link bez kontroli skrzynki pocztowej lub ukończenia callbacku dostawcy. Atakujący może uzyskać normalną sesję dla istniejącego użytkownika lub utworzyć konto błędnie oznaczone jako zweryfikowane e-mailem, gdy rejestracja jest włączona. Problem naprawiono w wersji 1.7.7.

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.

W bibliotece Better Auth w wersjach przed 1.3.26 nieuwierzytelniony atakujący może tworzyć lub modyfikować klucze API dowolnego użytkownika, przekazując jego identyfikator w treści żądania do endpointu api/auth/api-key/create. Gdy nie ma sesji, ale w treści żądania występuje userId, flaga authRequired staje się fałszywa, a walidacja pól wykonywana tylko przy authRequired true zostaje pominięta, co pozwala ustawiać uprzywilejowane pola. Ten sam wzorzec występuje w endpoincie aktualizacji; luka stanowi krytyczne obejście uwierzytelniania i została naprawiona w wersji 1.3.26.

Better Auth w wersjach od 1.5.0-beta.12 do 1.7.7 zawiera podatność obejścia uwierzytelniania w pluginie OAuth Proxy pozwalającą nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez sfałszowanie zaszyfrowanych profili. Gdy proxy współdzieli globalny sekret, a stan przechowywany w cookie jest używany, atakujący może uzyskać zaszyfrowany stan dla fałszywego profilu ze zweryfikowanym adresem e-mail ofiary, aby przejąć konto poprzez niejawne powiązanie.

W Better Auth (@better-auth/drizzle-adapter i better-auth od 1.6.17 przed 1.7.7 oraz @better-auth/kysely-adapter od 1.6.17 przed 1.7.0) występuje warunek wyścigu w ograniczaniu liczby żądań opartym na bazie danych PostgreSQL — sprawdzenie limitu nie jest atomowe względem aktualizacji licznika. Zdalni atakujący mogą wysyłać serie równoczesnych żądań, które wspólnie przechodzą sprawdzenie, przekraczając skonfigurowane limity dla logowania hasłem, weryfikacji dwuskładnikowej, kodów jednorazowych, resetu hasła i innych chronionych punktów końcowych.

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.