Authentication Bypass in the default configuration phpBB

What it is

CVE-2026-48611, a critical unauthenticated authentication bypass in phpBB (an old but still-used forum software), patched in version 3.3.17. Found by Aikido's AI pentest agents, reported on HackerOne (triaged in under 9 minutes), patched four days later. Announced June 10th; this post is the technical follow-up. Beyond the summary, it gives the exact request construction needed to reproduce or detect the exploit.

How it works

The flaw lives in phpBB's OAuth "login-link" feature (ucp_login_link.php), not the main login flow — the feature that links an external OAuth account to an existing phpBB account.

• The callback first requires non-empty login_link_* query parameters. This gate is trivially passed by supplying any dummy value, e.g. login_link_aikido=1, which makes $data non-empty.
• The code then reads the auth_provider query parameter and uses it directly ("even if different from configured"). It's normally oauth, but the attacker fully controls it.
• Setting auth_provider=apache invokes phpbb/auth/provider/apache.php. That provider's login() compares the submitted username to the PHP_AUTH_USER HTTP Basic header, looks the user up, and returns LOGIN_SUCCESS — with no password check at all.

The apache provider was never negligent by design: it assumes an Apache reverse proxy with .htpasswd has already authenticated the request, so it trusts the Basic-auth username. The bug is that this provider can be triggered without Apache being configured, from a single unauthenticated request.

flowchart TD
    A[Login-link callback] --> B{login_link_* param non-empty?}
    B -->|dummy value| C[auth_provider read from request]
    C --> D{provider value}
    D -->|oauth = intended| E[normal OAuth flow]
    D -->|apache = attacker choice| F[apache::login]
    F --> G[match username to PHP_AUTH_USER, no password] --> H[LOGIN_SUCCESS as any user]

Preconditions / Affected

phpBB in default configuration below 3.3.17 — no special setup, no Apache/.htpasswd required, and no valid credentials. A single unauthenticated request logs in as any account, including an administrator, granting full forum control.

What to do

Update to phpBB 3.3.17. The page states no command-line steps.

For detection, the exploit's fingerprint is a login-link request carrying auth_provider=apache together with login_link_* parameters and a Basic-auth PHP_AUTH_USER header — a combination that should not occur normally.

Caveats

The fetched text is truncated mid-sentence at the mechanism explanation, so the promised full "exploit scenarios and detection methods" sections were not captured here; the attacker still needs the target username, which for admin accounts is often public.