# Authentication & Registration Bypass in Newspack Extended Access

Newspack Extended Access REST endpoint accepted unsigned JWTs, letting attackers log in as any known-email user or create arbitrary accounts.

- Payout: hidden
- Severity: medium
- Program: Automattic
- Found by: xurizaemon0
- Disclosed: 2024-05-20
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/2472798
- Library page: https://bugbountylibrary.com/r/h1%3A2472798
- Tags: area:web3 domain:web impact:ato impact:integrity kind:bounty platform:hackerone sev:medium tech:jwt tech:php tech:wordpress technique:source-review vuln:account-takeover vuln:auth-bypass

**Target:** WordPress REST endpoint /wp-json/newspack-extended-access/v1/google/register
**Root cause:** The REST controller decodes the JWT and trusts the email claim without verifying the JWT signature, so any forged token is accepted as identity.
**Steps:**
1. Craft an unsigned/arbitrary-signed JWT with payload `{email: "target@example.org"}` (e.g. via token.dev).
2. POST the raw token as `text/plain` body to `/wp-json/newspack-extended-access/v1/google/register`.
3. Server decodes email claim, matches user, and sets auth cookie for that user.
4. Repeat with new emails to create arbitrary Customer-role accounts.
**How found:** Source review of class-rest-controller.php lines 81-99 revealed the JWT email claim is used without signature verification, and role checks only block Editor/Administrator.
**Exploitation:** Attacker needs only the victim's email. They forge a JWT with that email claim and POST it to the register endpoint; the plugin authenticates the browser as the target user, exposing profile/billing data. Same endpoint also creates new accounts from untrusted input.
**Escalation:** Bypass limited to non-Admin/Editor roles, but other privileged roles like Shop Administrator remain reachable; arbitrary account creation enables DoS and stored injection into admin views.
**Insight:** When a plugin implements 'Sign in with Google' by decoding a JWT client-side or server-side, check whether signature verification is actually invoked; also check role blocklists for gaps (Shop Manager, Shop Administrator) rather than allowlists.