2FAuth vulnerabilities

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.

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.

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.

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.

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.