CVE-2026-63439
KrytyczneCVSS 9.8Streszczenie
2FAuth przed wersją 8.0.0 przy włączonym AUTHENTICATION_GUARD=reverse-proxy-guard odczytuje domyślny nagłówek tożsamości REMOTE_USER lub niestandardowy nagłówek wskazany w AUTH_PROXY_HEADER_FOR_USER bez potwierdzenia, że żądanie pochodzi z zaufanego proxy. Zdalny klient mogący dotrzeć bezpośrednio do aplikacji może sfałszować nagłówek tożsamości i uwierzytelnić się jako istniejący użytkownik, w tym administrator.
Ocena ryzyka
Atakujący może uzyskać dostęp do przechowywanych sekretów 2FA oraz funkcji zarządzania kontami i aplikacją, podszywając się pod dowolnego użytkownika.
Rekomendacja
Zaktualizuj 2FAuth do wersji 8.0.0 lub nowszej oraz upewnij się, że aplikacja jest dostępna wyłącznie przez zaufane proxy.
Inne podatności w 2FAuth
Zobacz wszystkie- CVE-2026-63441Średnie
W aplikacji 2FAuth funkcja ValidatesUrls::isPublicIp() nie rozpoznaje prefiksów NAT64 64:ff9b::/96 oraz 64:ff9b:1::/48, co pozwala na obejście walidacji adresów prywatnych. Parametr obrazu w URI otpauth może zawierać adres IPv6 lub adres syntezowany przez DNS64, którego docelowy adres IPv4 jest prywatny, link-local, loopback lub należy do metadanych chmury. W wyniku tego IconService::buildFromRemoteImage() wykonuje żądanie HTTP GET do wewnętrznego celu, umożliwiając odczyt odpowiedzi obrazów lub sondowanie innych punktów końcowych.
- CVE-2026-63440Średnie
W 2FAuth ścieżka pobierania obrazów otpauth waliduje nazwę hosta przez ValidatesUrls::isExternalHost(), a następnie IconService::storeRemoteImage() ponownie rozwiązuje tę samą nazwę hosta dla żądania HTTP. Przy włączonym pobieraniu zewnętrznych obrazów otpauth uwierzytelniony użytkownik kontrolujący autorytatywny DNS o niskim TTL może zwrócić adres publiczny podczas walidacji i adres wewnętrzny podczas późniejszego połączenia, omijając listę blokowanych adresów prywatnych. Pozwala to na dostęp do loopback, sieci prywatnej, link-local lub punktów końcowych metadanych chmury.
- CVE-2026-63437Średnie
W 2FAuth metoda recipients() w app/Api/v1/Controllers/TwoFAccountShareController.php otrzymuje wybrany przez wywołującego TwoFAccount przez powiązanie modelu Laravel, ale nie wywołuje polityki autoryzacji manageShares przed wyświetleniem listy odbiorców. Gdy udostępnianie kont jest włączone, uwierzytelniony użytkownik może wywołać GET /api/v1/twofaccounts/{victimId}/recipients dla kont należących do innych użytkowników, wyliczyć identyfikatory i nazwy wyświetlane zarejestrowanych użytkowników, testować dokładne adresy e-mail za pomocą filter[nameOrEmail] oraz sprawdzać relacje udostępniania każdego konta.
- CVE-2026-63438Krytyczne
2FAuth przed wersją 8.0.0 przy AUTHENTICATION_GUARD=reverse-proxy-guard akceptuje nagłówki uwierzytelniania od klienta, który nie przeszedł przez zaufane proxy; RemoteUserProvider::retrieveById() tworzy konto dla nieznanego REMOTE_USER, awansuje pierwsze utworzone konto na administratora i synchronizuje e-mail z nagłówka poczty. Nieuwierzytelniony zdalny klient może utworzyć administratora na świeżej instancji lub podszyć się pod znane konto i przekierować jego e-mail.
Oryginalny opis (angielski, źródło NVD)
2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard is enabled, ReverseProxyGuard::user() reads the default REMOTE_USER identity header, or a custom identity header selected by the AUTH_PROXY_HEADER_FOR_USER configuration setting, without confirming that the request originated from a configured trusted proxy. A remote client that can reach the application directly can forge the selected identity header and authenticate as an existing user, including an administrator, gaining access to stored 2FA secrets and account or application management functions. This issue is fixed in version 8.0.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS