AzuraCast X-Forwarded-Host Injection Leads to Account Takeover and 2FA Bypass

Vulnerability Summary: Password Reset Poisoning via Untrusted X-Forwarded-Host Header Leads to Account Takeover and 2FA Bypass Vulnerability Overview This vulnerability stems from AzuraCast's middleware, which unconditionally trusts the HTTP header provided by the client and does not utilize a trusted proxy whitelist. An attacker can poison the password reset link sent to a user by injecting this header. When the victim clicks the link, the reset token is forwarded to the attacker's server, who then uses it to reset the victim's password and destroy their 2FA configuration on the real instance, achieving full account takeover. Root Causes: 1. Unconditional Trust: The code directly reads the header without verifying whether the request originated from a trusted reverse proxy. 2. Request Host Used for Security-Critical URLs: When is true, the generated absolute URL uses the poisoned request host. 3. Password Reset Generates Absolute URLs: The link in the reset email uses the poisoned host. 4. Reset Token Destroys 2FA: The user's 2FA secret is unconditionally destroyed during the password reset process. Impact Scope Affected Versions: (Composer) <= 0.23.5 Severity: High (8.1 / 10) CVSS Metrics: Attack Vector (Network), Attack Complexity (Low), Privileges Required (None), User Interaction (Required), Scope (Unchanged), Confidentiality (High), Integrity (High), Availability (None). Consequences: Full takeover of any user account (including administrators) without prior authentication. 2FA Bypass: The password reset process unconditionally destroys the 2FA configuration. If the target is an administrator, it leads to abuse of administrative privileges. Remediation 1. Fix 1 (Primary): Validate X-Forwarded-Host Against Trusted Proxy Whitelist In , only apply headers if the request originates from a trusted proxy (such as nginx within Docker). 2. Fix 2 (Defense in Depth): Use Configured Base URL for Security-Critical Emails In , use the configured setting to generate the reset URL instead of using the request-derived URL. Alternatively, modify to add an option to force the use of the configured base URL. 3. Fix 3 (Defense in Depth): Do Not Destroy 2FA During Password Reset On line 75 of , remove . If 2FA recovery is required, it should be handled as a separate, explicit flow, rather than as a side effect of the password reset. POC Code Prerequisites: An AzuraCast instance user account with 2FA enabled (e.g., ). The attacker controls and has a web server logging incoming requests. Step 1: Trigger Poisoned Password Reset Expected Result: The password reset email sent to contains a URL like this: Step 2: Capture the Token When the victim clicks the link in the email, the browser navigates to . The attacker's web server, , captures the full URL path and extracts the token . Step 3: Use the Token on the Real Instance Result:** The victim's password is changed to , and their 2FA is destroyed ( ). The attacker logs in with full access.

Goal Reached Thanks to every supporter — we hit 100%!

AzuraCast X-Forwarded-Host Injection Leads to Account Takeover and 2FA Bypass

More from this source