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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-11-06T21:17:09.970Z",
  "pubdate": "2026-11-06T21:17:09.970Z",
  "executiveSummary": "The 2FAuth application prior to version 8.0.0 is susceptible to an authentication bypass vulnerability when configured with AUTHENTICATION_GUARD=reverse-proxy-guard.\nThe vulnerability stems from the application's failure to verify the trust status of the request origin when processing identity headers.\nAn unauthenticated remote attacker capable of reaching the application directly can spoof the REMOTE_USER header or a custom header defined by AUTH_PROXY_HEADER_FOR_USER to impersonate any user, including administrators.\nSuccessful exploitation results in full account takeover, unauthorized access to sensitive 2FA secrets, and total application management control.\nThe vulnerability poses a critical risk to data confidentiality and integrity, as it completely negates the primary security function of the 2FAuth service.\nMitigation requires updating to version 8.0.0 or higher, where validation mechanisms for trusted proxy sources have been implemented.",
  "technicalDetails": "The root cause of this vulnerability lies in the ReverseProxyGuard::user() function implementation within the 2FAuth codebase. When the application is configured to operate behind a reverse proxy using the reverse-proxy-guard mechanism, it relies on HTTP headers (such as REMOTE_USER or a custom header configured via AUTH_PROXY_HEADER_FOR_USER) to determine the identity of the authenticated user.\nThe vulnerability occurs because the application performs a blind trust operation; it consumes the user identity provided in these headers without performing any verification to confirm that the request originated from a legitimate, pre-configured trusted proxy server. Consequently, if the 2FAuth instance is reachable directly by a client, the security controls can be entirely bypassed.\nThe attack flow proceeds as follows: An attacker identifies an instance of 2FAuth where the reverse-proxy-guard is enabled. The attacker then crafts an HTTP request to the application, manually injecting the chosen identity header (e.g., REMOTE_USER: admin). Because the application lacks a check to validate the network source or IP address against a whitelist of trusted proxies, it processes the request as coming from a pre-authenticated environment.\nThe application logic accepts the forged identity and initializes a session corresponding to the user specified in the header. If the attacker chooses the username of an administrator, the application grants administrative privileges to the attacker's session.\nOnce authenticated as an administrator, the attacker gains full access to the application's backend functions. This includes the ability to view, export, or modify stored 2FA secret keys, manage user accounts, and alter application-wide security settings. Given that 2FAuth stores sensitive TOTP seeds, the impact allows the attacker to generate valid one-time passwords for all managed accounts, effectively compromising the secondary layer of authentication for the victims' protected services.\nThe vulnerability is present in all versions of 2FAuth prior to 8.0.0. The requirement for exploitation is network reachability to the application server and the specific configuration of the reverse-proxy-guard authentication method. No specialized authentication credentials are required for the initial entry point, as the vulnerability itself serves as the authentication bypass mechanism."
}