# Bruteforce protection in password verification can be bypassed

Nextcloud's IP-based bruteforce throttling trusts X-Forwarded-For when a trusted proxy is configured, letting attackers spoof IPs to bypass login rate limiting.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: taise
- Disclosed: 2024-01-17
- CVE: CVE-2023-49792
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/2230915
- Library page: https://bugbountylibrary.com/r/h1%3A2230915
- Tags: area:web domain:web impact:ato kind:bounty platform:hackerone sev:medium tech:php technique:source-review vuln:auth-bypass vuln:misconfiguration

**Target:** Nextcloud server login / bruteforce throttler (getRemoteAddress)
**Root cause:** getRemoteAddress() returns the first valid IP from X-Forwarded-For when the request comes from a trusted proxy, so the throttler keys on an attacker-controlled value instead of the real client IP.
**Steps:**
1. Configure Nextcloud behind a trusted_proxy.
2. Send repeated failed logins; observe Throttler\sleepDelay response delay.
3. Add `X-Forwarded-For: <valid IP>` header to each request; delay disappears and throttling is bypassed.
**How found:** Code reading of getRemoteAddress() in lib/public/IRequest.php revealed that the client IP is taken from forwarded_for_headers when the peer is a trusted proxy, making the throttler key spoofable.
**Exploitation:** Attacker rotates arbitrary valid IPs in the X-Forwarded-For header on each login attempt, so each request appears to come from a fresh IP and the per-IP bruteforce delay never triggers, enabling unlimited password guessing.
**Insight:** When a rate limiter keys on client IP, check whether that IP is derived from a proxy header; if the app trusts any proxy in front, the header is attacker-controlled and the limiter is trivially evaded by rotating values.