GitHub Security Advisory: GHSA-gv7r-3mr9-h5x8
Package: azuracast/azuracast (COMPOSER)
Severity: HIGH (CVSS 8.1)
CWE: CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: <= 0.23.5
Patched in: 0.23.6

Summary: AzuraCast has Password Reset Poisoning via Untrusted X-Forwarded-Host Header that Leads to Account Takeover and 2FA Bypass

Details:
## Summary

The `ApplyXForwarded` middleware unconditionally trusts the client-supplied `X-Forwarded-Host` HTTP header with no trusted proxy allowlist. An unauthenticated attacker can poison the password reset URL sent to any user by injecting this header when triggering the forgot-password flow. When the victim clicks the poisoned link, their reset token is exfiltrated to the attacker's server. The attacker then uses the token on the real instance to reset the victim's password and destroy their 2FA configuration, achieving full account takeover.

## Details

### Root Cause 1: Unconditional X-Forwarded-Host Trust

`backend/src/Middleware/ApplyXForwarded.php:35-40`:
```php
if ($request->hasHeader('X-Forwarded-Host')) {
    $hasXForwardedHeader = true;
    $xfHost = Types::stringOrNull($request->getHeaderLine('X-Forwarded-Host'), true);
    if (null !== $xfHost) {
        $uri = $uri->withHost($xfHost);
    }
}
```

There is no validation that the request originates from a trusted reverse proxy. Any direct client can set this header and it will be accepted.

In the default Docker deployment, nginx's PHP location block (`util/docker/web/nginx/azuracast.conf.tmpl:150-171`) uses `fastcgi_pass` with `include fastcgi_params`. Standard nginx behavior passes all client HTTP headers through to PHP-FPM as `HTTP_*` parameters. The `proxy_params.conf` file — which explicitly sets `X-Forwarded-For`, `X-Forwarded-Proto`, and `X-Forwarded-Port` — only applies to `proxy_pass` directives (websocket and vite dev server), NOT to the `fastcgi_pass` PHP handler. Therefore, client-supplied `X-Forwarded-Host` reaches PHP unmodified.

### Root Cause 2: Request Host Used for Security-Critical URLs

`backend/src/Http/Router.php:53-77` in `buildBaseUrl()`:
```php
$useRequest ??= $settings->prefer_browser_url; // default: true

// ...
if ($useRequest || $baseUrl->getHost() === '') {
    $ignoredHosts = ['web', 'nginx', 'localhost'];
    if (!in_array($currentUri->getHost(), $ignoredHosts, true)) {
        $baseUrl = (new Uri())
            ->withScheme($currentUri->getScheme())
            ->withHost($currentUri->getHost())
            ->withPort($currentUri->getPort());
    }
}
```

With `prefer_browser_url = true` (the default at `backend/src/Entity/Settings.php:109`), the request URI host — already poisoned by `ApplyXForwarded` — is used as the base URL for generating absolute URLs. Even if a `base_url` is configured in settings, it is overridden by the poisoned request host.

### Root Cause 3: Password Reset Generates Absolute URL

`backend/src/Controller/Frontend/Account/ForgotPasswordAction.php:72-77`:
```php
$router = $request->getRouter();
$url = $router->named(
    routeName: 'account:login-token',
    routeParams: ['token' => $token],
    absolute: true
);
```

This URL is embedded in the password reset email sent to the victim.

### Root Cause 4: Reset Token Wipes 2FA

`backend/src/Controller/Frontend/Account/LoginTokenAction.php:74-75`:
```php
$user->setNewPassw