# SSRF via User-Controlled Push proxyServer in Notifications Push Registration

Authenticated user registers push device with attacker-controlled proxyServer, causing backend to POST to arbitrary internal URLs when a notification fires.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: yoyomiski
- Disclosed: 2026-09-30
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/3623149
- Library page: https://bugbountylibrary.com/r/h1%3A3623149
- Tags: area:web domain:web impact:internal-access kind:bounty platform:hackerone sev:medium tech:php technique:source-review vuln:ssrf

**Target:** OCS push registration API / notifications backend
**Root cause:** PushController accepts a user-supplied proxyServer without validation, and Push::sendNotificationsToProxies() later POSTs to $proxyServer.'/notifications' server-side.
**Steps:**
1. Authenticate as low-priv user and create an app password via `occ user:auth-tokens:add`.
2. Ensure user not in DND mode (set status online).
3. POST to `/ocs/v2.php/apps/notifications/api/v2/push` with `pushTokenHash`, `devicePublicKey`, and `proxyServer=http://localhost/`; expect 201.
4. Trigger push via `occ notification:test-push yoyo --files`.
5. Observe backend log: `127.0.0.1 ... "POST /notifications HTTP/1.1" ... "Nextcloud Server Crawler"`.
**How found:** Code review of PushController (NoAdminRequired route accepting user proxyServer) and Push::sendNotificationsToProxies() building the outbound URL from that value.
**Exploitation:** Attacker registers a push device pointing proxyServer at an internal target, then waits for or triggers any notification to that user, causing the Nextcloud server to issue a POST to the chosen URL with the server's network position.
**Insight:** Push/notification registration endpoints that store a callback URL are prime SSRF sinks; check whether the stored proxyServer is validated at registration or only used later at send time, and whether DND/status gates can be bypassed to force the request.