# ID4me feature of OpenID connect app available even when disabled

Disabled ID4ME setting only hid the login button; the /apps/user_oidc/id4me controller stayed reachable, letting unauthenticated attackers self-register accounts via a rogue ID4Me provider.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: lukasreschke
- Disclosed: 2024-05-30
- CVE: CVE-2024-37312
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/2376929
- Library page: https://bugbountylibrary.com/r/h1%3A2376929
- Tags: area:web domain:web impact:ato impact:internal-access kind:bounty platform:hackerone sev:medium tech:oidc technique:source-review vuln:access-control vuln:auth-bypass vuln:misconfiguration

**Target:** Nextcloud user_oidc app ID4ME endpoint
**Root cause:** The enable/disable ID4ME setting only hides the login button; the ID4ME controller routes remain registered and accessible regardless of the setting.
**Steps:**
1. Install user_oidc app on Nextcloud
2. Open `http://localhost:8080/apps/user_oidc/id4me` unauthenticated
3. Enter domain `id4me.cloud.wtf` pointing to attacker-controlled ID4Me server
4. Attacker server serves `/.well-known/openid-configuration`, `/register`, `/auth` (redirects with code), `/token` (returns forged id_token with `sub: admin`)
5. Complete flow and land logged in as a new user on the instance
**How found:** Noticed the disable setting only hid the UI button, then tested the controller route directly as unauthenticated user with a self-built ID4Me dummy server.
**Exploitation:** Attacker hosts a fake ID4Me provider returning a self-signed id_token; victim instance accepts it and provisions a new account, granting access to instance-wide Talk rooms.
**Insight:** When a feature toggle only hides UI, always hit the underlying controller routes directly; self-hosted OIDC/ID4Me providers let you forge id_tokens if the instance trusts arbitrary issuer domains.