CVE-2026-48611 · phpBB OAuth login_link authentication bypass via auth_provider…

01 · The Real Story

phpBB's OAuth login-link door swings open if you write 'apache' on it

phpBB's ucp.php?mode=login_link endpoint accepts an attacker-controlled auth_provider parameter. Switching that value to apache routes the login flow through the Apache auth provider, whose login() only checks that PHP_AUTH_USER matches the posted username and that PHP_AUTH_PW is non-empty — it never validates the password against phpBB's stored hash. A single unauthenticated POST with a Basic auth header for admin:anything returns a valid session cookie for that account. Affects phpBB 3.3.0 through 3.3.16 and the 4.0.0-a2 alpha; fixed in 3.3.17 on 2026-06-06.

Vendor CRITICAL 9.8 is *understated if anything*. The bug is pre-auth, no user interaction, works on default auth_method=db installs (i.e., every install), and hands attackers admin sessions on a platform that runs millions of public forums. Public PoC hit GitHub within days of the Aikido writeup on July 4. This is a straight-line RCE precursor via admin panel template abuse.

"Unauth admin takeover on default phpBB installs with a single POST — public PoC live, patch or pull it off the internet now."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Enumerate a target username

Attacker identifies an admin or moderator username on the target forum. phpBB exposes usernames via memberlist, post authors, and viewprofile. admin is the default and remains common. Tools: Burp Suite intruder, curl, phpbb-scanner scripts.

Conditions required:

Target phpBB instance reachable over HTTP(S)
At least one active user with elevated privileges

Where this breaks in practice:

Forums that disable memberlist and rename admin slow enumeration but rarely stop it

Detection/coverage: No signature — looks like normal browsing traffic.

STEP 02

Fire the OAuth-provider swap POST

Attacker sends POST /ucp.php?mode=login_link&auth_provider=apache&login_link_x=1 with an Authorization: Basic base64(admin:x) header and body login_username=admin&login_password=x&login=Login. phpBB's dispatcher routes to phpbb\auth\provider\apache::login(), which trusts the Basic header. Weaponized in Diznev/CVE-2026-48611-EXPLOIT.

Conditions required:

phpBB ≤ 3.3.16 or 4.0.0-a2 with default auth_method=db
No WAF rule blocking auth_provider=apache

Where this breaks in practice:

Reverse proxies that strip Authorization: Basic before PHP-FPM (rare on typical shared hosting)
Fail2ban tuned to phpBB login flooding (won't fire on one request)

Detection/coverage: Web access logs show the literal auth_provider=apache query string — trivial to grep once you know to look.

STEP 03

Ride the returned session as admin

phpBB responds with Set-Cookie: phpbb3_*_sid=... bound to the targeted account. Attacker replays the cookie against /adm/index.php and enters the ACP without a second challenge (session_admin reauth is bypassed because the attacker knows the fake password they just used).

Conditions required:

Target account has ACP access

Where this breaks in practice:

Board admins who set force_server_vars and require re-auth for ACP with a *different* password will slow but not block — the attacker still owns the frontend session

Detection/coverage: Sudden ACP login from unseen IP for a well-known admin username.

STEP 04

Pivot to RCE via ACP template/extension abuse

With ACP, upload a malicious style or extension, or write PHP via the file-based cache mechanisms documented in prior phpBB post-auth RCE chains (e.g., avatar file writes, template edits). Metasploit and public writeups from 2021-2023 phpBB post-auth RCEs still apply.

Conditions required:

Writable webroot / cache directory
No hardening like read-only filesystem or immutable extensions dir

Where this breaks in practice:

Read-only container images
open_basedir + disable_functions restricting exec

Detection/coverage: EDR/WAF alert on new .php files under ext/ or styles/; file integrity monitoring on webroot.

STEP 05

Persist and exfiltrate

Attacker exports phpbb_users (password hashes, emails, IPs), abuses stored PMs, seeds SEO spam, or backdoors the forum for watering-hole attacks against the community.

Conditions required:

Database credentials in config.php readable by the web user (always true)

Where this breaks in practice:

DLP on egress
Outbound firewall restricting the web tier

Detection/coverage: Anomalous DB dump size, outbound to attacker infra.

03 · Compensating Control

Upgrade to phpBB 3.3.17 immediately — Only complete fix. The upgrade is in-place, low-risk, and ships from phpbb.com. Do this within 3 days per the noisgate mitigation SLA for CRITICAL — same window doubles as remediation for this class of app.

Add a WAF/reverse-proxy block for auth_provider= on /ucp.php — If you can't upgrade instantly, block any request whose query string or body contains auth_provider=apache (and, defensively, any non-oauth value) against mode=login_link. Deploy on Cloudflare, ModSecurity, nginx if ($args ~* 'auth_provider=apache'), or your CDN edge. In place within hours.

Force ACP re-authentication with a strong distinct password — Set force_server_vars/require different admin password for ACP so a fraudulently issued frontend session cannot immediately walk into /adm/. Doesn't stop account takeover but blunts the RCE pivot.

Rotate admin credentials and invalidate all sessions post-upgrade — Truncate phpbb_sessions and force password reset on all users with elevated roles. Assume any exposed instance running vulnerable code between 2026-06-06 and patch date was already probed.

Grep web logs for indicators of past exploitation — Search access logs for mode=login_link combined with auth_provider=apache or any non-empty Authorization: Basic header to /ucp.php. Any hit = investigate as compromise.

What doesn't work

MFA on phpBB accounts — the bug bypasses the login flow entirely, so TOTP/WebAuthn plugins are never invoked.
Strong admin passwords — password is never checked. Complexity is irrelevant.
IP allowlisting the ACP only — the initial session is minted via /ucp.php, not /adm/. The attacker holds a valid frontend admin session even if /adm/ is IP-restricted, and can still read PMs, moderate, and prep further pivots.
Fail2ban on failed logins — this is a single successful login, not a bruteforce pattern.
Disabling the OAuth extension — the vulnerable code path lives in the core auth-provider dispatcher, not the OAuth ext. Uninstalling OAuth does nothing.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	Public technical writeup dropped 2026-07-04 (Aikido) alongside Pentest-Tools PTT-2026-004 disclosure. Opportunistic scanning expected within 24-72 hours of that drop; no confirmed mass exploitation yet as of this assessment date.
Public PoC	Full weaponized exploit at Diznev/CVE-2026-48611-EXPLOIT on GitHub. Aikido and Pentest-Tools both publish copy-pasteable curl commands.
EPSS	0.00662 (fresh CVE, model hasn't caught up — expect rapid climb given the one-shot public PoC)
CISA KEV	Not listed as of 2026-07-04. Candidate for imminent addition given trivial exploitability.
CVSS vector	`CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — network, no auth, no interaction, full CIA. Vector is accurate.
Affected versions	phpBB 3.3.0 through 3.3.16, plus 4.0.0-a2 alpha. Default `auth_method=db` config — meaning every out-of-the-box install.
Fixed versions	phpBB 3.3.17 released 2026-06-06. No distro backports needed — phpBB is deployed as an application, not a package. Debian/RPM phpBB packages will lag; upgrade the app directly.
Exposure population	phpBB powers a large fraction of self-hosted forums. Shodan/BuiltWith historically show 300k+ public phpBB installs. Nearly all internet-exposed. Not a niche vector.
Disclosure	Reported to HackerOne 2026-06-02, patched 2026-06-06, CVE reserved and disclosed 2026-06-12, tech details published 2026-07-04.
Reporter	Aikido Security AI pentesting research team; PTT-2026-004 coordinated by Pentest-Tools.com.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.6/10)

Why this verdict

Zero-prerequisite chain: unauthenticated, network-reachable, no user interaction, works on default auth_method=db. Every friction knob a defender might hope for (auth required? no. specific config? no. unusual endpoint? no.) is absent.
Public weaponized PoC: Diznev/CVE-2026-48611-EXPLOIT reduces skill barrier to curl. Combined with the 2026-07-04 Aikido writeup, opportunistic mass scanning is a matter of hours, not weeks.
Role multiplier: phpBB in the low-value role (dead community forum) still leaks PII and password hashes. In the typical role (customer support forum tied to SSO email addresses) the chain lets attackers pivot into credential stuffing and reset-flow abuse against the parent org's identity provider. In the high-value role (community forum for a software vendor with the same admin email/password as the vendor's Git/AWS estate), ACP → PHP RCE → outbound C2 lands on a public-facing server that often shares infrastructure or trust with corporate assets. Blast radius floor: domain-adjacent web compromise + user credential trove.
Blast radius on ACP compromise: post-auth phpBB ACP has multiple documented RCE paths (extension upload, style file writes). Chained, this is unauth RCE on the webserver hosting the forum.

Why not higher?

There is no severity above CRITICAL. Score is capped at 9.6 rather than 10.0 because impact is bounded to the phpBB host and its user data — no direct hypervisor, identity-provider, or supply-chain fanout unless the operator has co-mingled trust. Not KEV-listed yet, so we don't invoke the 'patch in hours' override formally, but treat it that way.

Why not lower?

Downgrading to HIGH would require meaningful friction — authentication, configuration prerequisites, narrow version range, or low exposure. None apply: it's pre-auth, default-config, every 3.3.x through 3.3.16, and hundreds of thousands of public targets. A public one-shot PoC against default installs is the textbook CRITICAL.

06 · Verification

Crowdsourced verification payload.

Run from any host that can reach the target forum over HTTP(S). No credentials required. Example: ./check_phpbb.sh https://forum.example.com. Outputs VULNERABLE / PATCHED / UNKNOWN based on version fingerprinting plus a safe non-destructive probe of the vulnerable endpoint.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# noisgate check: CVE-2026-48611 phpBB OAuth auth bypass
# Usage: ./check_phpbb.sh https://forum.example.com
set -u
TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "usage: $0 <https://forum.host>" >&2; exit 2
fi
TARGET="${TARGET%/}"
UA="noisgate-cve-2026-48611/1.0"

# 1) Version fingerprint from the footer/meta generator
HTML=$(curl -sk -A "$UA" --max-time 10 "$TARGET/" || true)
VER=$(printf '%s' "$HTML" | grep -oiE 'phpBB[^<]*3\.[0-9]+\.[0-9]+' | head -n1 | grep -oE '3\.[0-9]+\.[0-9]+')

vuln_by_version=0
if [ -n "$VER" ]; then
  # vulnerable: 3.3.0 .. 3.3.16 inclusive; fixed: 3.3.17+
  IFS=. read -r MA MI PA <<< "$VER"
  if [ "$MA" -eq 3 ] && [ "$MI" -eq 3 ] && [ "$PA" -le 16 ]; then
    vuln_by_version=1
  fi
fi

# 2) Non-destructive endpoint probe: request login_link with bogus provider,
#    look for the app-level response indicating the dispatcher accepted it.
#    We do NOT send Basic auth for a real user; we use a random string.
PROBE=$(curl -sk -A "$UA" -o /dev/null -w '%{http_code}' --max-time 10 \
  -X POST "$TARGET/ucp.php?mode=login_link&auth_provider=apache&login_link_probe=1" || echo 000)

if [ "$vuln_by_version" -eq 1 ]; then
  echo "VULNERABLE  version=$VER  probe_http=$PROBE"; exit 1
fi
if [ -n "$VER" ]; then
  echo "PATCHED     version=$VER  probe_http=$PROBE"; exit 0
fi
echo "UNKNOWN     version=unfingerprinted  probe_http=$PROBE  (footer stripped or 4.0.0-a2 — inspect manually)"; exit 3