CVE-2026-63437
MediumCVSS 6.5Summary
In 2FAuth, the recipients() method in app/Api/v1/Controllers/TwoFAccountShareController.php receives a caller-selected TwoFAccount through Laravel model binding but does not call the manageShares authorization policy before listing its recipients. When account sharing is enabled, an authenticated user can call GET /api/v1/twofaccounts/{victimId}/recipients for accounts owned by other users, enumerate registered user IDs and display names, test exact email addresses with filter[nameOrEmail], and inspect each account's sharing relationships.
Risk Assessment
This vulnerability enables unauthorized access to sharing information of other users' accounts, including enumeration of users and email addresses, which may facilitate phishing or social engineering attacks. The risk applies to deployments with account sharing enabled.
Recommendation
Update 2FAuth to version 8.0.0 or later, which fixes this vulnerability. Until then, consider disabling the account sharing feature.
Other vulnerabilities in 2FAuth
See all- CVE-2026-63441Medium
In 2FAuth, ValidatesUrls::isPublicIp() does not recognize the 64:ff9b::/96 and 64:ff9b:1::/48 NAT64 prefixes, allowing bypass of private address validation. An otpauth URI image parameter can contain an IPv6 literal or DNS64-synthesized address whose embedded IPv4 target is private, link-local, loopback, or cloud metadata. As a result, IconService::buildFromRemoteImage() issues an HTTP GET to the internal target, enabling recovery of image-shaped responses or blind probing of other endpoints.
- CVE-2026-63440Medium
In 2FAuth, the otpauth image-fetch path validates a hostname through ValidatesUrls::isExternalHost() and then lets IconService::storeRemoteImage() resolve the same hostname again for the HTTP request. When external otpauth image fetching is enabled, an authenticated user controlling low-TTL authoritative DNS can return a public address during validation and an internal address during the later connection, bypassing the private-address deny list to reach loopback, private-network, link-local, or cloud metadata endpoints.
- CVE-2026-63439Critical
2FAuth prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard is enabled, reads the default REMOTE_USER identity header or a custom header selected by AUTH_PROXY_HEADER_FOR_USER without confirming that the request originated from a configured trusted proxy. A remote client that can reach the application directly can forge the identity header and authenticate as an existing user, including an administrator.
- CVE-2026-63438Critical
2FAuth prior to 8.0.0, when AUTHENTICATION_GUARD=reverse-proxy-guard accepts authentication headers from a client that did not pass through a trusted proxy, RemoteUserProvider::retrieveById() creates an account for an unknown REMOTE_USER, promotes the first created account to administrator, and synchronizes the account email from the configured mail header. An unauthenticated remote client can create an administrator on a fresh instance or impersonate and redirect email for a known account.
Original NVD description (English source)
2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, the recipients() method in app/Api/v1/Controllers/TwoFAccountShareController.php receives a caller-selected TwoFAccount through Laravel model binding but does not call the manageShares authorization policy before listing its recipients. When account sharing is enabled, an authenticated user can call GET /api/v1/twofaccounts/{victimId}/recipients for accounts owned by other users, enumerate registered user IDs and display names, test exact email addresses with filter[nameOrEmail], and inspect each account's sharing relationships. This issue is fixed in version 8.0.0.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS