Description

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 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 therefore create an administrator on a fresh instance or impersonate and redirect email for a known account, exposing 2FA secrets and administrative functions. This issue is fixed in version 8.0.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-11-06T21:17:09.770Z",
  "pubdate": "2026-11-06T21:17:09.770Z",
  "executiveSummary": "2FAuth prior to version 8.0.0 contains a critical authentication bypass vulnerability within the 'reverse-proxy-guard' mechanism.\nThe vulnerability occurs because the application fails to verify if incoming requests have passed through a trusted proxy, allowing external actors to supply arbitrary authentication headers.\nThe application relies on the 'REMOTE_USER' header to identify users; by spoofing this value, an unauthenticated attacker can force the 'RemoteUserProvider::retrieveById()' function to treat them as an authorized user.\nOn fresh installations, this enables an attacker to assume administrative privileges, as the system promotes the first account created to an administrator. On existing instances, an attacker can perform account impersonation, potentially leading to unauthorized access to 2FA secrets and sensitive administrative functions.\nThe risk is severe as it allows for full account takeover and administrative control without legitimate credentials. Exposure to the public network permits unauthenticated exploitation by any remote client capable of crafting HTTP headers.",
  "technicalDetails": "The vulnerability resides within the authentication logic of the 'reverse-proxy-guard' implementation. The root cause is a lack of validation regarding the origin of HTTP requests; the application assumes that any header received is inherently trusted, rather than enforcing a strict allowlist of authorized proxy IP addresses or utilizing secure internal communication channels.\nWhen configured for 'reverse-proxy-guard', the application invokes 'RemoteUserProvider::retrieveById()' to identify the user session. This function blindly trusts the 'REMOTE_USER' header provided in the HTTP request. If the user associated with the provided identifier does not exist in the database, the system automatically triggers a user creation process.\nThe attack flow proceeds as follows: First, the attacker identifies a public-facing 2FAuth instance configured to accept reverse-proxy authentication headers. Second, the attacker crafts an HTTP request containing a chosen 'REMOTE_USER' header. Third, if the instance is a fresh deployment, the first account created is automatically elevated to an administrator, allowing the attacker to assume control over the entire application. Fourth, if the instance is already in use, the attacker can specify the username of an existing account in the 'REMOTE_USER' header. The application then synchronizes the account email address from the configured mail header, effectively allowing the attacker to redirect sensitive account-related communications and bypass existing 2FA protections.\nBecause the 'RemoteUserProvider' does not verify the network source of the request, it treats the attacker's supplied header as an authoritative assertion of identity. This bypasses all secondary authentication checkpoints. The ability to manipulate the account email address facilitates further malicious activities, including credential recovery or account locking mechanisms that consolidate the attacker's control.\nThe vulnerability specifically affects 2FAuth versions prior to 8.0.0. Exploitation requires no prior authentication and can be performed via standard web requests, making it a high-impact flaw for any instance exposed to untrusted networks."
}