Severity Medium — CVSS 3.1: 5.0 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N) (per phpBB) Asset phpbb/phpbb — Web Push notification subsystem Affected phpBB 4.0.0-alpha1 (commit 4a57f1ff3c ) Fixed in phpBB 4.0.0-a2 (2026-04-27) CVE None assigned TL;DR (for the non-technical reader) phpBB is one of the longest-running open-source forum platforms. Its upcoming 4.0 line ships browser Web Push notifications so users can get pinged in real time when someone replies to them. The 4.0.0-alpha1 release stored the push endpoint — the URL the server is supposed to POST notifications to — exactly as the user’s browser sent it, without checking what URL it actually pointed to. A registered (non-admin) user could subscribe themselves with a push endpoint pointed at any URL: an attacker-controlled server, an internal host that the public internet can’t reach, anything. Once any event triggered a notification for that user (a reply, a quote, a private message), the phpBB server made the outbound POST to that URL. We reported it via HackerOne; phpBB fixed it in 4.0.0-a2 by adding an HTTPS-only allowlist of known push services. What’s vulnerable phpBB’s Web Push subsystem was introduced in 4.0 to replace the legacy Jabber notification method (which the 4.0 migration explicitly removes). The browser registers via the W3C Push API, posts the resulting subscription ( endpoint , p256dh , auth ) to /user/push/subscribe , and phpBB persists it in the phpbb_push_subscriptions table. On any notification event, phpBB looks up the user’s stored endpoint and ships an encrypted Web Push payload via the Minishlink/web-push PHP library, which uses Guzzle under the hood. The W3C Push API expects the endpoint to be a URL of a push service — fcm.googleapis.com , updates.push.services.mozilla.com , notify.windows.com , web.push.apple.com . phpBB 4.0.0-alpha1 never enforced that. The user-supplied string went straight into the database. Attack flow flowchart LR U["registered user (attacker)"]:::accent S["POST /user/push/subscribe endpoint = http://internal-host:8080"]:::n D["phpbb_push_subscriptions (no URL validation)"]:::n E["any notification event (reply, quote, PM)"]:::n W["Minishlink WebPush → Guzzle"]:::n T["attacker / internal host receives POST"]:::alert U --> S --> D E --> W -- "reads endpoint from DB" --> D W -- "POST + 3KB encrypted payload" --> T classDef n fill:#1A1A1C,stroke:#2A2A2D,color:#EDEAE3 classDef accent fill:#0A0A0B,stroke:#FF4A1C,color:#EDEAE3 classDef alert fill:#0A0A0B,stroke:#E8342B,color:#EDEAE3 Vulnerable code path Subscription persistence — phpBB/phpbb/ucp/controller/webpush.php inside subscribe() , around line 321: $sql = 'INSERT INTO ' . $this -> push_subscriptions_table . ' ' . $this -> db -> sql_build_array ( 'INSERT' , [ 'user_id' => $this -> user -> id (), 'endpoint' => $data [ 'endpoint' ], // ← user-supplied, no URL validation // ... ]); Outbound request — phpBB/phpbb/notification/method/webpush.php around line 248, in the notification dispatch: $push_subscription = Subscription :: create ([ 'endpoint' => $subscription [ 'endpoint' ], // from DB, unvalidated ]); $web_push -> queueNotification ( $push_subscription , $json_data ); The Subscription model is Minishlink\WebPush\Subscription ; queueNotification then drives Guzzle to issue the outbound POST with VAPID-signed headers and the encrypted payload to the URL that was stored at subscribe time. Why the prerequisites are weaker than they look webpush_enable defaults to false on fresh install, so an out-of-the-box phpBB 4.0.0-a1 isn’t vulnerable. But webpush_method_default_enable defaults to true — the moment an admin flips Web Push on (configures VAPID keys and enables the feature in ACP → Board settings), every existing user has the method active by default . There’s no per-user opt-in step gating this; the model is opt-out. The Jabber callback phpBB has seen this bug class before. In 2020, HackerOne #1018568 reported SSRF via the Jabber notification settings — jab_host and jab_port were admin-only fields that fed an outbound connection. The phpBB 4.0 migration removed Jabber outright, and Web Push was added as the modern replacement. The interesting structural point: the new feature inherits the same outbound-URL-from-config bug class but moves the privilege boundary down — from “admin must configure the server URL” to “any registered user configures their own”. Same root pattern, lower bar. Proof of concept — verified live Setup: phpBB 4.0.0-alpha1 in Docker (PHP 8.2 + MySQL 8.0). Enable Web Push: UPDATE phpbb_config SET config_value = '1' WHERE config_name = 'webpush_enable' ; -- VAPID keys generated via Minishlink\WebPush\VAPID::createVapidKeys() As a registered user, subscribe to Web Push in the browser, intercept the request to /user/push/subscribe , and replace the endpoint field with the URL you control. The P-256 ECDH p256dh and auth keys must be valid; they are trivially generated. Equivalent direct DB insertion for the lab: INSERT INTO phpbb_push_subs...